Checking what route our box will take

It's also possible that connectivity might be failing because your box is trying to talk out of the wrong interface. We can check this with ip again.

First, let's look at which route we're going to take when communicating with the wider world.

In the following code, we're checking how our box would attempt to talk to the device with the IP 1.1.1.1. It shows us that we would go to this IP via the gateway address, 10.0.2.2, and our eth0 interface:

$ ip route get 1.1.1.1
1.1.1.1 via 10.0.2.2 dev eth0 src 10.0.2.15 
    cache 

Now, let's see what route we'll take if we're communicating with our gateway. Here, we can see a direct connection (no via) also going out of eth0:

$ ip route get 10.0.2.2
10.0.2.2 dev eth0 src 10.0.2.15 
    cache 

So far, so good, but what about if we want to talk to the other VM on our private network?

$ ip route get 192.168.33.11
192.168.33.11 dev eth1 src 192.168.33.10 
    cache 

eth1 would be used, which makes perfect sense given it's on the same network.

Hang on a moment—our own IP is in this subnet too, so what happens if we try to communicate with ourselves?

$ ip route get 192.168.33.10
local 192.168.33.10 dev lo src 192.168.33.10 
 cache <local> 

Ah! Clever! We're still using the loopback address (dev lo) to talk to our local IP address, because Linux knows that this IP is ours.