We had a hardware unit that was Ethernet enabled. To configure and manage it, the vendor provided us with a Windows program that, given the unit’s IP, could establish a TCP connection to the unit’s port 3300 and do all of its fancy management things.
The only problem was, the hardware unit was a hundred miles away on a private subnet at a client’s building, and the only thing that could directly talk to it was Linux computer A that we installed alongside the unit. We had the foresight to install Hamachi on computer A, and my own Linux computer B here also had Hamachi. My clunker Windows laptop C that could actually run the software was hooked up directly to computer B via Ethernet.
So, computer C had the Windows program and could talk to computer B via direct Ethernet. Computer B could talk to computer A via the Internet using Hamachi. And computer A could talk to the hardware unit via its local VLAN.
C -> B -> A -> hardware unit
The transitive property of hooking-up-computers states that if C can talk to B and B can talk to A, then C can talk to A. But how?
Well, when you only have SSH, every problem looks like an SSH connection.
- Computer B connected to computer A and established an SSH tunnel. The SSH tunnel forwarded B’s localhost:5000 port to A’s hardwareunit.local:3300.
computer-b$ ssh -L5000:hardwareunit.local:3300 computer-a.local
- Computer C connected to computer B and established an SSH tunnel. The tunnel forwarded C’s localhost:3300 to B’s localhost:5000.
computer-c$ ssh -L 3300:localhost:5000 computer-b.local
- Windows program on C connected to C’s localhost:3300, which actually goes to B’s localhost:5000, which actually goes to the hardware unit’s port 3300 via A.
Yes, everything was passed along via two SSH connections in a row, but it worked quite well, and it will save us from driving down to the client in the rare case that we need to do this again.