I've got a server with 2 network interfaces.
Due to a restrictive NAT firewall, it establishes an SSH tunnel to a server on the internet:
ssh -fNTMS "/tmp/tunnel.socket" host;
ssh -S "/tmp/tunnel.socket" -O forward -R "0:localhost:22" placeholder
Normally it connects via a wired 1GB ethernet connection (eth0); but it's unreliable, as it's in an office where people move stuff around, and the cable "falls out" (unfortunately I can't use glue).
It also has a mobile 4G internet connection (eth1), which is slower, and more expensive.
To ensure the tunnel is still working, I'm periodically using the -O check
command:
ssh -S "/tmp/tunnel.socket" -O check placeholder
Master running (pid=3430)
echo $?
0
If this -O check
fails, the socket will be closed (via -O exit
), and a new SSH connection will be established.
If the failure was due to the eth0 network cable "falling out", then Linux will automatically use eth1.
This works really well.
But, when eth0 is back up again, I'd like to switch back to it.
So I'm thinking, when running -O check
, I could see if the tunnel is currently using eth1 (the point of this question), and if eth0 is back, re-connect.
Routing information:
ip route
default via 192.168.1.1 dev eth0 proto dhcp src 192.168.1.225 metric 100
default via 192.168.2.1 dev eth1 proto dhcp src 192.168.2.241 metric 200
Note how eth1 has a metric of 200, so eth0 gets priority when it's working.
I can't find anything in /proc/3430/
I can list connections with lsof
:
lsof -ai -p 3430 -n -P
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ssh 3430 craig 3u IPv4 69362 0t0 TCP 192.168.1.225:43878->1.1.1.1:22 (ESTABLISHED)
And netstat -tpln
does not show interfaces when listing sockets.
check
command fails, so that connection is lost, then it a new connection is established (imagine these examples in awhile true
).-b' with
ssh` or assign metrics to the routes. But you will have to add more information. I suggest you add at least the fallback script, and the current routing table would not hurt. You might ask, how does this answer my question? Well, for example, depending on the situation, the source address might be enough to know the interface being used. But it's not clear (to me at least) whether NAT is between you and the interfaces or between the interfaces and the remote server.