<aside> 💡
This is a follow-up to the previous article, 4. Understand Linux Routing System, presenting two interesting hands-on experiments. Through these experiments, we will attempt to interact with targets outside the Network Namespace, such as the eth0 interface on the local host, or external network services like Google DNS.
</aside>
For a better understanding, please refer to the previous articles on Namespaces, VETH, and ARP.
<aside> 💡
In Experiment 2, we will initiate a ping command from the eth0 interface inside the network namespace ns1 to the Host eth0 interface. Since these two interfaces belong to different subnets, they cannot communicate directly. Therefore, we will explore how, by interacting with the Routing Table and utilizing the bridge br0, we can eventually succeed in pinging the Host eth0.
During the experiment, we will observe two interesting issues, and we will leave one additional question for the reader to ponder.
In addition, this environment does not have any default routing rules and does not use a gateway. Instead, it adopts a Direct Routing approach.
The architectural diagram is shown below.
</aside>
<aside> 💡
This environment uses the Ubuntu 24.04 server provided by iximiuz Labs, which offers a fast and convenient online practice environment.
Reference: https://labs.iximiuz.com/
</aside>
Host eth0 from ns1
First, let’s check the routing table of ns1. At the moment, it contains only one entry:
10.22.33.0/24 dev eth0 proto kernel scope link src 10.22.33.4
Next, when we issue a ping command from ns1 to the Host, we can observe that it results in a “Network is unreachable” status.
ns1's routing table
Since that’s the case, let’s try adding the Host’s **eth0** to ns1’s routing table.
Step 1: Add the route with the command
ip route add 172.16.0.2/32 dev eth0
Step 2: Issue the ping command to the Host again
Result: We get a different outcome — it’s no longer “Network is unreachable”, but the ping command becomes stuck (hangs)…
Why is that? Let’s debug it step by step.