How to Build Isolated Single‑Host Container Networks Without Writing Code

Prerequisites

Any Linux distribution works; the examples run on a Vagrant CentOS 8 VM.

$ vagrant init centos/8
$ vagrant up
$ vagrant ssh
[vagrant@localhost ~]$ uname -a
Linux localhost.localdomain 4.18.0-147.3.1.el8_1.x86_64

Network namespace isolation

Linux network namespaces provide an independent network stack (routing table, firewall rules, devices). Create one with ip netns add netns0 and list it with ip netns.

$ sudo ip netns add netns0
$ ip netns
netns0

Enter the namespace using nsenter:

$ sudo nsenter --net=/var/run/netns/netns0 bash
# New bash runs inside netns0

Using virtual Ethernet devices (veth)

veth devices come in pairs and act as a tunnel between two namespaces. Create a pair and move one end into the namespace:

$ sudo ip link add veth0 type veth peer name ceth0
$ sudo ip link set ceth0 netns netns0

Bring the devices up and assign IPs:

$ sudo ip link set veth0 up
$ sudo ip addr add 172.18.0.11/16 dev veth0
$ sudo nsenter --net=/var/run/netns/netns0
$ ip link set lo up
$ ip link set ceth0 up
$ ip addr add 172.18.0.10/16 dev ceth0

Now the two ends can ping each other, proving the isolated network stack works.

Connecting containers with a virtual bridge

When multiple containers share the same IP subnet, simple veth pairs cause routing conflicts. A Linux bridge (L2 switch) solves this by connecting all veth devices to a common bridge.

$ sudo ip link add br0 type bridge
$ sudo ip link set br0 up
$ sudo ip link set veth0 master br0
$ sudo ip link set veth1 master br0

Assign IPs only to the container ends (ceth0, ceth1). The bridge itself gets an IP to act as the default gateway: $ sudo ip addr add 172.18.0.1/16 dev br0 Containers can now reach each other and the host:

# Inside netns0
$ ping -c 2 172.18.0.20
# Inside netns1
$ ping -c 2 172.18.0.10

Connecting to the external world (IP routing and NAT)

Enable IP forwarding on the host:

sudo bash -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'

Apply NAT so that packets leaving the private 172.18.0.0/16 network appear with the host's external IP:

sudo iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE

After this, containers can reach the Internet:

# Inside netns0
$ ping -c 2 8.8.8.8
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=36.8 ms

Port publishing

Expose a container service (e.g., a Python HTTP server on 172.18.0.10:5000) to the host’s external interface (10.0.2.15):

# DNAT for external traffic
sudo iptables -t nat -A PREROUTING -d 10.0.2.15 -p tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000
# DNAT for locally generated traffic
sudo iptables -t nat -A OUTPUT -d 10.0.2.15 -p tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000

Now curl 10.0.2.15:5000 returns the container’s HTTP response.

Understanding Docker network drivers

Docker’s default bridge mode implements exactly the bridge‑based setup described above. The host mode skips network namespaces entirely, sharing the host stack. The none mode creates an empty namespace with only a loopback interface.

Rootless containers and networking

Rootless tools like Podman use slirp4netns to provide user‑space networking without requiring root privileges. While functional, rootless containers lack raw socket capabilities (e.g., ping) and cannot directly manipulate veth devices.

Conclusion

The presented approach—network namespaces, veth pairs, a Linux bridge, IP routing, and NAT—covers the most common single‑host container networking scenario. It mirrors what Docker and other container runtimes do under the hood, illustrating that containers are essentially a form of lightweight Linux virtualization.

转自公众号：Docker中文社区