Mastering Linux Tunnel Communication: A Deep Dive into IPIP Tunnels and Tun Devices

In previous articles, we’ve learned that a tun device is a network layer device, also known as a point-to-point device. It is called this because the tun device is often used for Linux tunnel communication.

IP Tunneling

Linux natively supports various Layer 3 tunnels. The underlying implementation of these is based on the tun device. We can use the command ip tunnel help to view related operations of IP tunnels.

You can see that Linux natively supports a total of 5 types of IP tunnels.

• ipip: Known as IPv4 in IPv4, encapsulates an additional IPv4 packet on an IPv4 packet.
• gre: Known as Generic Routing Encapsulation, defines a mechanism for encapsulating any network layer protocol over any other network layer protocol; applicable to both IPv4 and IPv6.
• sit: Similar to ipip, but sit encapsulates IPv6 packets over IPv4 packets, or IPv6 over IPv4.
• isatap: Known as Intra-Site Automatic Tunnel Addressing Protocol, similar to sit, it’s also used for IPv6 tunnel encapsulation.
• vti: Known as Virtual Tunnel Interface, is an IPsec tunnel technology proposed by Cisco.

Practicing IPIP Tunnel

We will use ipip as an example to practice Linux tunnel communication. This article is based on the Linux routing mechanism explained previously. If you’re not familiar with Linux routing, you may want to review that article first.

Before practicing, it is important to know that ipip requires the kernel module ipip.ko for support. Check if it is loaded with lsmod | grep ipip; if not, load it first using modprobe ipip. A normal load should display:

代码语言：javascript代码

Once the ipip module is loaded, tunnels can be created by first creating a tun device and then binding that tun device as an ipip tunnel.

Our experimental topology is as follows:

First, refer to the routing article to ensure that v1 and v2 can communicate; this will not be repeated here.

Subsequently, create a tun device and set it as an ipip tunnel.

代码语言：javascript代码

The command above creates a tun device tun1 within NS1 and sets the tunnel mode to ipip. The tunnel endpoints need to be set using remote and local, representing the outer layer IP of the tunnel. The inner layer IP is configured using ip addr xx peer xx. A general schematic is shown below.

Likewise, we also configure the same settings on NS2.

代码语言：javascript代码

After completing the configuration above, the two tun device endpoints can communicate as follows:

代码语言：javascript代码

Let’s attempt to analyze this process.

1. First, the ping command constructs an ICMP request packet. The ICMP packet is encapsulated within an IP packet, and the source and destination IP addresses are those of tun1(10.10.100.10) and tun2(10.10.200.10), respectively.

2. Since tun1 and tun2 are not on the same subnet, the routing table will be consulted. When an ipip tunnel is established using the ip tunnel command, a routing entry will be automatically generated, indicating that routes to destination 10.10.200.10 will exit via tun1.

代码语言：javascript代码

3. Since the tunnel endpoints are configured, the data packet exits tun1 and reaches v1. It will be encapsulated with a new IP header, with source and destination IPs being v1(10.10.10.2) and v2(10.10.20.2).

4. Since v1 and v2 are not on the same subnet, the routing table will again be checked, revealing that packets destined for the 10.10.20.0 subnet can be sent through the 10.10.10.1 gateway.

5. With ip_forward enabled on Linux, similar to a router, the 10.10.10.0 and 10.10.20.0 networks are two directly connected routes, so the packet is forwarded based on the routing table from NS1 to NS2.

6. Upon reaching v2 of NS2, the packet is decapsulated and recognizes that the destination IP address within the inner packet is 10.10.200.10, which matches the tun2 address configured for the ipip tunnel, hence the packet is handed over to the tun2 device. At this point, the ping request from tun1 successfully reaches tun2.

7. Since ICMP packets are characteristic of a request and response model, NS2 constructs an ICMP response packet, following similar encapsulation and decapsulation steps until it reaches tun1, completing the entire ping process.

This sums up the general ipip tunnel communication process. Next, we can further validate with packet capturing.

The following is a capture of the packets at the v1 port using Wireshark:

>

You can see two layers of IP headers, with the outer layer using the ipip protocol forming the tunnel endpoints, while the inner layer carries the usual communication packets encapsulating ICMP packets as payload.

Summary

The current Linux kernel natively supports 5 types of tunnel protocols, implemented using tun virtual devices.

The various VPN software we’re familiar with can’t do without these 5 tunnel protocols at their core.

We can replace ipip with other tunnel modes above without making any other changes, and achieve experiments with different tunnels.