Proxy Setup & Ports

[Michael Saunders]

Hi,

Ok, first let me describe my setup.

I've got approximately 150 machines deployed running UltraVNC, listening on port 80. These are not reachable directly by the computers loading the noVNC web page.

I've got WebSockify installed on the web server: the web server CAN reach the remote machines.

Am I correct in understanding that the WebSockify proxy will act as a gateway in this context? so that a user can browse to the noVNC on teh web server, use WebSockify (also on the web server) to relay the connect out to the remote machines? Is that correct, or do I still need a repeater invovled to make this work?

If I can do this, what ports do I need in the following configurations:

WebSockify: What ports do I need to listen on and output on? Can I listed on 5900 and do I need to then output on Port 80?

What port do I put into NoVNC when making the connection to get the client to connect to WebSockify on my server and outbound to the machine on port 80?

If this isn't clear enough about the requirements, please let me know!

Thanks.

[Joel Martin]

On Wednesday, July 22, 2015 at 8:27:46 PM UTC-5, Michael Saunders wrote:

Am I correct in understanding that the WebSockify proxy will act as a gateway in this context? so that a user can browse to the noVNC on teh web server, use WebSockify (also on the web server) to relay the connect out to the remote machines? Is that correct, or do I still need a repeater invovled to make this work?

Yes, websockify is designed for exactly this sort of scenario.

 

If I can do this, what ports do I need in the following configurations:

WebSockify: What ports do I need to listen on and output on? Can I listed on 5900 and do I need to then output on Port 80?

What port do I put into NoVNC when making the connection to get the client to connect to WebSockify on my server and outbound to the machine on port 80?

The listen and target port for websockify is specified when you start it up. By using the --token-plugin/--token-source command line option you can specify a file (or folder of files) that map opaque tokens to target host:port. The token is then specified as a query param for the websocket connection path (not the query params for the noVNC page itself).

Alternately you can also extend websockify to add your own auth/targeting logic. For example, OpenStack wraps websockify and coordinates the websockify setup with a specific auth token provide as part of the page that present noVNC. So that might be useful for reference.

Regards,

Joel Martin (kanaka)

[Michael Saunders]

I'll be honest I haven't had a huge chance to really delve into this yet, but from what I'm seeing, am I on the right track that, without modification/integration, the webSockify is more of a static proxy/path mapping? As in, a given incoming port goes to a pre-defined output port/IP? So if I needed to map 10 devices behind a single host, I'd either need 10 instances of webSockify running, or to customise/integrate it as you describe that OpenStack does? Or does NoVNC actually specify to the proxy the end-point IP and Port (similar to how UltraVNC's repeater works)?

[Joel Martin]

On Friday, July 24, 2015 at 11:48:40 PM UTC-5, Michael Saunders wrote:

I'll be honest I haven't had a huge chance to really delve into this yet, but from what I'm seeing, am I on the right track that, without modification/integration, the webSockify is more of a static proxy/path mapping? As in, a given incoming port goes to a pre-defined output port/IP? So if I needed to map 10 devices behind a single host, I'd either need 10 instances of webSockify running, or to customise/integrate it as you describe that OpenStack does? Or does NoVNC actually specify to the proxy the end-point IP and Port (similar to how UltraVNC's repeater works)?

The --token-plugin/--token-source mechanism is actually fairly dynamic and allows easy integration with external tools without having to modify or extend websockify. In particular, you can use that mechanism with a directory of files that each contain a single mapping and update these files dynamically (websockify reads the file/directory mappings every time a new connection is made).

For example:

    ./run --web ../novnc --token-plugin=TokenFile --token-source=`pwd`/target.cfg.d 6080

Inside target.cfg.d/ is one file t1 containing:

    # My first target

    target1: host1:5900

If noVNC connects and passes: "?token=target1" as the websocket connection path, then websockify will attempt to connect to host1:5900 as the target.

While websockify is running, you can add a new file t2 to that directory containing:

    target2: host2:5901

As soon as you add that file, new connections with token "target2" will cause websockify to connect to host2:5901. Also important to note is that if you delete t1, new connections with token "target1" will be denied.

This setup allows external tools to easy modify the connection files and update them on the fly without restarting websockify.

Also, if websockify is not run in a fully trusted environment (and maybe even if it is), I suggest using short lived random UUIDs for the connection tokens. Note that already existing VNC connection will not be dropped if the token file goes away after connecting. This enables a secured web framework to generate a temporary UUID for a token, create the connection file, forward the cilent to the correct URL including the token and then delete it after 30 seconds.

Anyways, hope that helps,

Joel Martin (kanaka)