How to create a VPN tunnel to ssh into one server from another server via a local VPN/proxy?
I have a problem that for 4 days no one has been able to solve. The problem might be on the datacenter side.
The problem is that one server can’t talk to the other server. I even got technical support from two software providers involved to look at my server, and they can’t find any misconfiguration either.
But both servers can be accessed via SSH from my home network. So how could I create a VPN tunnel from my home network (easily) so that it does this:
Server2 --> Home PC IP --> Server1
Or vice versa, so that my home IP from which SSH works find acts as a sort of proxy, to bypass any kind of NAT block or whatever could be blocking the connection?
The thing is that this second server is only temporary anyway, so doing something like this could solve my issue, even if the core issue isn’t solved. I just need to get a huge amount of data directly from one server to the other.
How can I set up such a tunnel to bypass the problem?
You would need to open a SSH session from home to Server1, telling it to forward remote port 2222 to local port 2222:
ssh -Nt -g -4 -R *:2222:localhost:2222 server1.public.net # 1
This opens a listening port on Server1’s port 2222. So, if you were to run "ssh 127.0.0.5 -p 2222" while on Server1, you would actually connect to whatever is running on your home machine on port 2222.
For now, nothing is running on that port.
You leave the first tunnel running, and run a different command against Server2:
ssh -Nt -g -4 -L 2222:localhost:22 server2.public.net # 2
This means that whoever connects to port 2222 on your home machine will now really be connected to local port 22 on server2.
Once these two processes are running, if you connect to Server1 you’ll find a listening port 2222. Connect to that port while on Server1, and it will be Server2 that will answer.
So, to copy a file from "/tmp" in server1 to "/var/tmp" in server2 while on server1, you’d go
scp -P 2222 /tmp/myfile user@127.0.0.5:/var/tmp
The connection will be pretty slow and could be optimized, but this way things are kept simpler.
The reason I’m using 127.0.0.5 instead of 127.0.0.5 is that your server is likely to already have a key for itself, under the heading "127.0.0.1", and SSH will complain if it detects a key mismatch (because on port 2222 the server answering is server2, not server1).
Upon the first connection, you’ll receive a warning that server 127.0.0.5 on port 2222 is unknown and if you want to store its key in known hosts. Accept. That is the key of server2.
To be on the safe side, once you need it no longer, in your user’s home directory you’ll find a file ~/.ssh/known_hosts and, inside, several lines, the last of which will probably be
server2.whatever,127.0.0.5 ssh-rsa AAAAB3...
(the "127.0.0.5" is the important part that identifies the line you want). Delete that line. My systems never got confused between 127.0.0.1 and 127.0.0.5, but why risk.
However
…next time, one server can’t talk to the other server is not a very helpful description. You know what it’s going on, but you aren’t communicating it clearly. Any of these might be happening:
- server1 cannot ping server2 (firewall, routing, IP conflict)
- server1 cannot connect w/ server2 (firewall, DNS problems)
- server1 connects but hangs (cipher mismatch? use ssh -vvvv)
- server1 connects but gets refused (bad key, user prohibited from logging in using plaintext password, sshrc misconfiguration…)
- server1 connects but connection freezes very soon (MTU mismatch?)
- and surely others I haven’t experienced yet