About Me ·
At GROSSWEBER we practice what we preach. We offer trainings for modern software technologies like Behavior Driven Development, Clean Code and Git. Our staff is fluent in a variety of languages, including English.
I'm doing quite a bit of computer support for a couple of friends. Some of them come over to my place when they need my help with some installation, driver or have a software problem. Recently, Silke, one of my bigger support "customers" moved to the United States and bought a new laptop because they're way cheaper there. We needed a whole day installing Windows XP, drivers and software. IM and Skype on a second machine were used for communication and obviously it's been quite onerous.
Unfortunately it's not possible to dial in to our home network over VPN because some router between Silke's and our server doesn't route GRE packets. I suspect it's the WLAN access point Silke has no control over. Because she's not allowed to administer it, creating a port mapping for Remote Desktop is also not an option. Windows' own Remote Assistance doesn't work over firewalled/NATed networks either.
I came up with a much simpler solution leveraging the power of SSH. SSH supports tunneling TCP connections and is very likely to be allowed by a corporate firewall. If a user logs on remotely via SSH and sets up port tunneling, he/she is either able to access a previously blocked remote port over a local connection (local → remote, my term) or the user's machine can be contacted from the SSH server over a remote → local tunnel (again, my term). The image below depicts both types of tunnels. There's a third tunnel type, namely dynamic SOCKS forwarding comparable to local → remote tunnels, but it's of no interest here.
As the "support engineer" all you need to do is set up a SSH server either on your local machine (and create a port mapping on your firewall/router) or on the firewall/router itself. There are couple of free SSH servers like freeSSHd. It has some limitations, but is perfectly suitable for the given task. After you've set up the server, created users and enabled tunneling, point your "support customer" to the PuTTY download page and let him download the Plink executable. Direct him to start Plink as follows (command line reference):
plink -ssh -C -R 50000:127.0.0.1:3389 <username>@<SSH server address>
This will establish an encrypted SSH connection to your SSH server and set up a remote → local tunnel. The server will listen on port 50000 and forward all traffic to port 3389 (Remote Desktop) on the user's machine. You can then create a new Remote Desktop session on the server connecting to 127.0.0.1:50000.
Unfortunately this cannot be used to work around the aforementioned problems with Remote Assistance, but in the end will provide a way of accessing otherwise protected machines over the internet. Of course, this will not only work with RDP connections but with all other types of servers.
a@href@title, blockquote@cite, em, strike, strong, sub, sup, u
Page rendered at Thursday, September 29, 2016 6:58:30 AM (W. Europe Daylight Time, UTC+02:00)
newtelligence dasBlog 2.3.257.0
© Copyright 2016, admin
The opinions expressed herein are my own personal opinions and do not represent
my employer's view in any way.