You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 53 Next »

1) What is EdgeView

EdgeView is a tool to allow user to interact with the remote edge devices and applications. EdgeView is implemented as a Docker container. The EdgeView container on the remote device serves as a 'server' function for EdgeView, and the same container on the user laptop serves as a 'client' function. The EdgeView client and server hops through the Dispatcher to communicate to each other. For more detail description of the EdgeView, see the EdgeView Architecture document. EVE has EdgeView support since release 8.5.0.

2) Where to get EdgeView

EdgeView is built as a Docker container, it can be pulled from docker registry with 'lfedge/eve-edgeview'. The source code is at EVE repository in pkg/edgeviw.

3) How do I start EdgeView

4) What is EdgeView Security Mechanism

First of all, to enable EdgeView on an EVE device to allow users remote access into it, the session needs to be allowed and enabled on the controller side. EdgeView configuration is part of the EVE device configuration. The configuration also defines access policies for this particular session. See EdgeView Policies for details.

A JWT token is generated when the EdgeView session is enabled for the EVE device. The token is signed by the controller and verified by the EVE device when it receives the EdgeView configuration from the controller. The token has an expiration time which is defined by the controller for this session. When the token expires, the EdgeView session, which connects to the dispatcher, will be torn down.

The remote user needs to acquire the same JWT token in order to establish an EdgeView session into the device or applications for troubleshooting or management.

Both the device and the user's laptop connect to the dispatcher, defined in the JWT token, through HTTPs session with TLS encryption. All the messages inside the EdgeView session is either authenticated or encrypted bidirectionally with a random 'nonce' which is created when the JWT token is generated by the controller. Thus even if the dispatcher server is compromised, the EdgeView messages can not be modified or viewed.

5) Why not just use SSH

SSH works fine if the user laptop and the edge device are in the same network, either they are all on the Internet or all in a private VPN network. If the edge device is behind NAT, firewall, LTE or proxy server, and the user's laptop is not, then SSH will not work. Also in the case of the user's laptop and the device belong to the same network, if multiple users want to access the device, they all need to share the private SSH key (or add multiple public keys onto the device) which sometimes is not desirable.

6) Why not just use SD-WAN

First, yes, when an edge device is behind the firewall, NAT or private LTE router, SD-WAN can be used to access that. The EVE device can be part of the SD-WAN just like any host or servers inside a company's VPN. This is in the IT domain of an enterprise. This assumes the enterprise already has the SD-WAN network and also the IT department allows the edge devices to be part of the VPN in the company.

There are many different SD-WAN solutions, different enterprises use different solutions and they have different IT policies and rules on the SD-WAN network. How to use the SD-WAN software to access the edge device and applications for troubleshooting will have to be achieved in case by case manner. The user can create a virtualized instance of the SD-WAN client as an App on the EVE device, the user's laptop has also to be part of the VPN. The correct routing needs to be setup in the SD-WAN App, the user can then access the other applications on the EVE device or the network connected to the EVE device.

Then, another solution can be to use the SD-WAN for EVE devices by the EVE controller provider independent of enterprises. The EVE controller provider manages the SD-WAN controllers and systems. The SD-WAN client runs as part of the EVE software. First of all, this needs to get enterprises IT permission to have a non-native SD-WAN into their remote locations; then to manage the SD-WAN controller itself, and make them scalable and HA is not a trivial task. There is also the challenge of security measures needed for managing multiple enterprises and synchronize the devices SD-WAN status to the EVE controllers.

While EdgeView solution is light weight, it does not need a controller for the operation. The user on EVE device controller needs to authorize and start the session, the rest of the operation is between the user and the EVE device sharing a private token which only has a limited time to live. The EdgeView does not have all the capabilities of a normal SD-WAN, it has a set of commands to be used for EVE device troubleshooting, and it allows TCP access for applications and other servers on the remote network. Users do not need to configure and run routing protocols for EdgeView which normally is required by the SD-WAN clients.

7) Why not just use WireGuard or OpenVPN

The WireGuard and OpenVPN allows clients to communicate through their servers which resides in the cloud side. Normally all the endpoints share the same IP subnet in the VPN. All the endpoints of this VPN can talk to each other (if the server does not set limitations). The procedure to setup something for a user laptop to access the edge-node and it's applications is like this:

  • run wireguard, and generate private/public keys on device behind firewall
  • run wireguard, and generate private/public keys on the user's laptop
  • add entry on the wireguard server configuration file for the peers of the new device and the laptop, which include the public keys, internal VPN IP addresses, etc.
  • setup routing on the device, the laptop and also on the wireguard server (if the traffic endpoints is not part of the VPN subnet)
  • may need to open up a new firewall rule for this wireguard server (UDP packets) on the device side
  • make sure the security, address allocation and routing among multiple sessions and multiple enterprises do not have issues
  • make sure the server redundancy works

If one is going to automate the above list, it actually is an implementation of a SD-WAN.

OpenVPN is similar to WireGuard in terms of the scheme of client/server, different cryptographic mechanisms are used. Similar steps as above is needed.

While for EdgeView, from device controller just need to click one button to start the EdgeView on the device, it also creates a EdgeView client script to be ready to run on the user's laptop. There is no need to program another server configuration for the IP addresses and public keys. There is no routing needs to be setup, and also there is no VPN IP address allocation issues. Yes, EdgeView does not have the N-to-N communication capability as in a normal SD-WAN or a VPN, but it allows multiple users to access the device which is behind a firewall or a proxy server to do the troubleshooting of the device and the management of applications associated with the device in a secure way.

8) Does EdgeView use IP overlay

No. Unlike a normal VPN going through multiple domains (with Internet in the middle) using routing scheme, EdgeView has multiple intermediate nodes stitching the traffic bidirectionally. It does not need to use IP over IP scheme. The EdgeView message is carried in normal TCP packets without IP overlay.

9) If controller has 'Remote Console' for EVE App, is that equivalent to EdgeView

Yes or not. EdgeView TCP channel does offer the capability of allowing the users to use VNC client to connect to the EVE application's console port, but it also offers other access methods such as SSH, and it allows user to get to other TCP services provided by the applications. EdgeView allows the users to do debugging and troubleshooting on the targeted EVE device.

In EdgeView scheme, the controller's role is to setup and start the EdgeView session, the controller does not get involved into the packet/data message switching part.

The decoupling of controller from operation of EdgeView offers several benefits. First it allows simplification of controller's workflow; when debugging EdgeView operation itself, the only item needs to be checked is the EdgeView container which runs on the device side and on the user's laptop; when adding a new feature into EdgeView, normally only the EdgeView code needs to be touched, thus it is easy and fast to add features into EdgeView.

10) Why Dispatcher is needed, who controls it

If making an analogy between EdgeView and SD-WAN, EdgeView is a Hub and Spoke topology with the Dispatcher as the 'Hub' and the user's laptop and the EVE device are two 'Spokes'. This is true for any VPN with different remote sites have to across the domains or Internet. The Dispatcher will connect to two different sites for the same EdgeView session to allow the user to access the EVE device and applications. The Dispatcher will stitch the messages from one side to the other based on a predetermined hash value generated by the EVE device controller.

Dispatcher can be placed anywhere, in the public cloud or private data center, as long as it can be reached from both ends of the EdgeView containers (the EVE device and the user laptop). It can be controlled by the same cloud management of the EVE device's controller or by the enterprises themselves. Since all the EdgeView messages through the Dispatcher are either authenticated or encrypted, it can not insert message into the session or read from the session.

11) What is EdgeView TCP channel

12) Does EdgeView work for devices behind NAT or Firewall

Yes. For firewall, make sure the dispatcher IP address and port number is not blocked by the firewall rules.

13) Can Edgeview work if the device is behind a proxy server

Yes or no. EdgeView uses WebSocket (The Websocket Protocol) for bidirectional communication between the client and server. The HTTP protocol needs to be upgraded between the websocket client and server. If the proxy server is a 'pass-through' type for the HTTPs traffic from the device, in other words if the proxy server does not intercept the TLS, then the EdgeView will work through the proxy server. But if the proxy server is a 'MiTM' type or 'SSL-Bump' type, the proxy server needs to make a separate HTTPs connection to the DIspatcher and it may not request the 'Upgrade' service towards the Dispatcher, then the EdgeView will break since it can not establish the connection to the Dispatcher. This is mainly an proxy server software implementation issue.

14) How to log into remote application

15) Can I use VNC or RDP

16) Can web browser be used over EdgeView

17) Will EdgeView work for HTTPs or TLS services with remote applications

18) Does remote application need to be on EVE devices for EdgeView access

19) Why log-search if device log is already uploaded to the controller

20) Is application port mapping still needed

21) How to get 'Show TechSupport' while the device fails to onboard

Yes, it is possible to get a compressed 'techsupport' file while the device has not onboarded yet. For the detailed steps, see Show TechSupport before Device Onboarding.

22) Does the EdgeView Client script run on MacOS and Window

Yes. the generated EdgeView client script will run on MacOS, assume the docker client has been installed on the MacOS. It will run also on Window OS if the Docker Desktop for Window and WSL 2 is installed (e.g. with Ubuntu distro).

If the user laptop only runs WSL 1, then the EdgeView Client script needs to be simply converted into Window style script.


  • No labels