Networking User Space: Slirp4netns

Networking is usually the realm of the kernel. When you plug in an ethernet cable, the kernel handles the electrical signals and IP packets. In a container, I usually use “veth pairs” (Virtual Ethernet), which acts like a virtual cable. But creating veth pairs requires - you guessed it - root.

The Problem

A rootless user cannot modify the system routing table. I cannot assign an IP address to an interface. I cannot manipulate iptables.

The Solution: User-Space NAT (slirp4netns)

I use a tool called slirp4netns. It sounds weird (“SLIP” + “IRP” + “Network Namespace”), but think of it as a Router written in software.

How it works

1. The TAP Device: The container gets a generic network interface called a “TAP” device. To the container, this looks like a real ethernet card.

2. The Process: slirp4netns runs on the host as a normal process. It holds onto the other end of that TAP device.

3. The Translation (Packet -> Socket):

   • Outgoing: When the container sends a TCP packet to google.com (IP 1.2.3.4), slirp4netns reads it. It doesn’t put it on the wire. Instead, it effectively calls socket.connect('1.2.3.4') on the host machine, just like a Python script would.
   • Incoming: When the host receives data from Google, slirp4netns wraps it back up into a TCP packet and injects it into the TAP device for the container to see.

Why this is cool

This means the container’s traffic looks, to the host kernel, exactly like regular traffic from the user vagmi.

• It respects your host firewall.
• It works over VPNs.
• It doesn’t require any special permissions.

It is slower than raw kernel networking (because of the overhead of reconstructing packets), but it is completely secure and unprivileged.