Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

As mentioned above, the TCP channel sets up a virtual port mapping across the Internet with frontend on user's laptop and backend being the remote endpoints from EVE device. For many TCP services, that work just fine. But HTTPs is different, it has the certificates which defines the domain name or service IP addresses. When a local web browser points to "https://localhost:9001", that application service will have issues of this 'localhost' or any IP address it does not have. The browser will also have the problem of verifying the certificates the server passes over. See FAQ on proxy for detail.

EdgeView TCP channel has the 'proxy' option for this usage. It requires the EdgeView TCP channel as a 'Virtual Proxy' service. This BTY is a 'pass-through' proxy, not a MiTM proxy. As in any proxy server, your application or host points to the laptop's proxy service port, and the proxy action is mainly on the EdgeView of the remote EVE device.

For example, the application with interface IP address of 10.1.0.2 is listening on TCP port 6443 as a HTTPs service for kubenetes API service.

  • setup TCP proxy command: edgeview.sh tcp/proxy

tcp mapping locally listening 1 ports to remote:

0.0.0.0:9001 -> proxy

  • assume the user has downloaded the 'kubeConfig' file on local laptop, a 'kubenetes' management software can be used to point to the proxy server of 'localhost:9001'. The kubeConfig remote API server address in this case is the real remote IP address: 10.1.0.2, and that is inside the certificate the API server uses.

The reason this proxy is part of the TCP command is that, the 'proxy' service is only for one port 9001 here, the others can still be used for regular TCP channel for SSH service and others.

HTTPs with Domain Name

The above example is for HTTPs working with the IP address in the URL, but normally the URL contains the domain name instead of IP address. If the server's domain name can be acquired though normal DNS lookup EVE uses, then this is not a problem. In the case where the server's domain name is private, only being served by internal DNS record, then the user needs to know about the internal DNS server IP address from some outband mechanism. EdgeView supports the proxy service with explicit specifying the DNS server IP address (e.g. it is 192.168.1.100) by:

edgeview.sh tcp/proxy@192.168.1.100

The usage is the same as normal EdgeView proxy, with browser points to an URL which has the server's domain name, and direct the proxy service to 'localhost:9001' in this case.

Copy Files Command

Tech-Support Command

...