Networking – How and Why Connecting to IP 0.0.0.0 Succeeds

networkingstracetcp

We are serving a port on localhost and want to check in another process if the port is available. Due to a bug in our code, it is actually trying to connect to the IP 0.0.0.0:<port>, and for some reason it succeeds — as strace proves:

[...]
connect(3, {sa_family=AF_INET, sin_port=htons(10002), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
[...]

What does it mean? Why does it work?

Best Answer

0.0.0.0 as a target address refers variously to a non-routable host or to “this host”. In practice connecting to 0.0.0.0 is equivalent to connecting to localhost. (Strictly speaking it isn’t valid as a destination address, only as a source address, but practice doesn’t match theory.)

When binding, “this host” expands to “any address on this host” — so applications commonly accept connections by binding to 0.0.0.0, which means they’ll receive packets addressed to any IPv4 address on the system.

Related Solutions

SSH Configuration – How to Set Up a Reverse SSH Connection

In /etc/ssh/sshd for Computer B set:

AllowTcpForwarding yes
TCPKeepAlive yes

From Computer A:

$ ssh -R 2222:localhost:22 ip.of.computer.b

From Computer B:

$ ssh localhost -p 2222

Note that 2222 is an arbitrary high-port number I picked. That port on Computer B will then be tunneled back through the SSH connection initialized on Computer A to port 22. If you have multiple machines you should use a different port for each machine.

For your use case you will probably want to run this from a script so that you can make it a daemon and periodically try to re-connect if the link is dropped. You will probably want a special account with a shell of just /bin/true on Computer B to handle the incoming connections. You can then setup either a single key or multiple keys for each machine that are allowed to "call home".

On Computer A you might find the -n, -N and -T options useful to disconnect it from local input (so it can run in the background), not try to run any remote command, just open the tunnel, and not create a tty.

Most normal methods of spawning a daemon don't work very well with setting up a network tunnel like this. A problem in network connectivity would make it try to beat the wall down to get through. A simple loop with a sleep to wait should do the trick. Ten minutes is a nice number because it doesn't flood the network and log files with attemps if there is a problem (like Computer B being offline) but it still gets you back in reasonably quick if the connection is droped.

#/bin/sh
while true; do
    sleep $((60*10))
    ssh -nNT -R 2222:localhost:22 ip.of.computer.b
done

A script like that can be run launched on boot /etc/rc.local. Your first change to log into the machine will start about ten minutes after the Computer A boots.

Linux – nc both fails and succeeds

Shortly after posting, I found the problem:

[jadavis6@ditirlns01 ~]$ host ditirldv02.ncat.edu
ditirldv02.ncat.edu has address 152.8.143.20
ditirldv02.ncat.edu has address 152.8.143.5
[jadavis6@ditirlns01 ~]$

So it appears that nc will cycle through all A records for a given host and test each one individually. The first failure was for the incorrect IP address, the success was for the correct one.

Best Answer

Related Solutions

SSH Configuration – How to Set Up a Reverse SSH Connection

Linux – nc both fails and succeeds

Related Question