When people connect to their VPN, this could simply allow them to access shared files. But alternatively, this could also mean that they wish to create a virtual session, on the remote desktop of one of their servers. The latter exists under the terms VNC, RDP, XRDP, and several others.
On my main Linux server named ‘Phoenix’, I have the XRDP service installed, which is the Linux equivalent of RDP. But one main drawback of this method, of remotely accessing a desktop, is the fact that XRDP does not allow file-sharing, specifically in the version of this protocol that runs out-of-the-box from the package manager. I have read that certain custom-compiled versions support this, but do recall that this service is a mess to custom-compile, and to set up in such a way that it runs reliably. So I stick to the packaged version for now, and do not obtain file-sharing.
There exists a closed-source application named NoMachine NX, which we could use to bridge this gap. But while their paid software subscriptions are very expensive (from my perspective), their Free software version has some big disadvantages.
First of all, even their Free version can be run in client or in server mode. I think that this is terrific. But in server mode – which affords access to the local machine desktop from elsewhere – there is no built-in support for SSH protocol. There is only the unencrypted NX protocol, for which their service listens.
Secondly, not every computer is strong enough to run NoMachine NX in server mode. On the computer ‘Phoenix’ I have a fragile X-server, and this service has actually crashed my X-server. Not only that, but allowing this service to run on reboot, consistently prevents my X-server from starting. It gets its hooks into the session so early on boot, that the X-server crashes, before the user is even asked for a graphical log-in.
On the plus side, there are ways of solving both problems.
The lack of built-in SSH support has a workaround, in the form of ad-hoc SSH tunnels, assuming that the machine this service is to run on, already has a working SSH server. In fact, the company even has a knowledge-base article on how to do this, which will relieve me of the need to explain it here.
Secondly, such use of SSH Tunnels can be chained, so that a certain machine will be our VPN server, but will create a listening, local port that corresponds to a different port on a target machine, elsewhere in the VPN. Then, our VPN configuration can establish an unencrypted connection to the port that exists locally on the VPN server, via loop-back, but which is in fact an alias for the port listening on the NoMachine server – with the added bonus of being encrypted.
Because my laptop ‘Klystron’ seems to be strong enough to support NoMachine in server-mode, I wanted to give this concept a full try today, using VPN and everything. But as I just wrote,
simply establishing a VPN connection into my home network did not succeed, so that my test could go no further.
One reason I had for making a first connection to the NoMachine Server, was the fact that the way their client works, after we have first defined a connection-profile, the settings of that profile are not yet complete.
Only when giving the command to the client, to establish a connection using a defined profile, does the client show us a sequence of additional screens, each of which has a check-box in the lower-left corner telling the software not to display the screen again, in which we give additional parameters relevant to the way we want to connect.
Knowing that I will still have to answer these information screens in the future bothers me. Most of them will receive settings that should not be changed, and which need to be in a certain specific way, for which reason I was planning to fill them out at the public WiFi Hot-Spot today, and to mark the check-box, so that I cannot make future mistakes in filling them out again.
(Edit 01/31/2017 : ) As of this morning, I was able to reestablish both an OpenVPN connection to my LAN, as well as a remote desktop on the laptop I name ‘Klystron’, using the Free version of NoMachine.
The following is a screen-shot of the NoMachine NX Client running on the desktop named ‘Phoenix’, but offering secure access to ‘Klystron':