​

On December 2, 2021, Volcano Engine Edge Computing Node was officially released to provide stable, high-performance and features-rich one-stop edge computing cloud platform services. As one of the underlying infrastructures of edge virtual machines, network is self-evident in its importance. It undertakes the function of traffic connectivity of virtual machine instances from north to south and from east to west. Tun/TAP device is an important virtual device for QEMU to connect vm and external networks.

This document describes the principles and applications of tun/ TAP devices in detail. It is hoped that readers can have a more comprehensive understanding of tun/ TAP network devices.

Those of you who are familiar with cloud native have already known about Flannel. Among flannel overlay network model, one is UDP mode. Although it was abandoned due to poor performance, it is also the most typical cross-host container network solution.

​

Flannel’s UDP mode is shown in the figure above, which is taken from the chapter on network parsing in Kubernetes by Lei Zhang. It can be seen that Flannel performs UDP packet sealing and packet unpacking in user mode through tun device (Flannel0). This flannel0 is one of the protagonists of today’s talk, tun device.

The TUN/TAP device is a virtual network device in the kernel of the operating system. It is a network device simulated by software and provides the same functions as the hardware network device. It is used to transmit packets in user space and kernel space.

​

The differences between tun/ TAP devices and physical nics are shown in the following figure:

  1. For hardware network devices, one end is connected to the physical network, and the other end is connected to the network protocol stack.
  2. For tun/tap devices, one end is connected to the application (through the character device file /net/dev/tun) and the other end is connected to the network protocol stack.

01 Working Principle

​

The working principle of

The figure shows the differences between tun/ TAP devices and physical devices. Although one end is connected to the network protocol stack, the other end of the physical nic is connected to the physical network, and the other end of the Tun/TAP device is connected to an application layer program. In this way, the data packets sent by the protocol stack to the Tun/TAP device can be read by the application program. The application can then make some custom changes to the packets (such as encapsulating them as UDP) and then send them over the network protocol stack — in fact, this is how most “proxies” work today.

The virtual NIC driver provided by the Tun/ TAP device is the same as the real NIC driver in terms of TCP/IP protocol stack.

Working mode

Tun /tap has two modes: Tun and TAP. The TUN device and TAP device work in the same way. The differences are as follows:

  1. The Tun device is a Layer 3 device. It reads and writes ONLY IP packets from the /dev/net/tun device. Therefore, layer 2 operations, such as sending ARP requests and Ethernet broadcasts, cannot be performed.
  2. The Tap device is a Layer 2 device and processes Layer 2 MAC data frames. The Tap device reads and writes only MAC data frames from the /dev/net/tun device. From this point of view, the Tap virtual device is more similar to the capabilities of the real physical network card and can bridge with the physical network card.

Matters needing attention:

  • Tun and tap devices are created in the kernel through the ioctl system call. The created devices do not appear as files in /dev/net/tun. You can see the tunx or tapx network interface under sys/class/net/.
  • The /dev/net/tun device must be opened in read/write mode. This device, also known as a clone device, is the starting point for creating any Tun/TAP virtual interface.
  • When an open system call is executed, VFS allocates a separate kernel-mode file structure for that open; that is, each time an open is executed, the kernel allocates a different instance of file structure for that open, representing a different character device.

Application data sending and receiving process:

  1. Data sending: Application process A open/dev/net/tun character device, through the ioctl call to create A virtual interface tunx or tapx, ioctl call returns the corresponding tunx or tapx file descriptor fd, Application A writes formatted data to the file descriptor fd. The data is sent to the protocol stack through the virtual nic driver. To the protocol stack, the data is received as if from the real NIC.
  2. Data receiving: When the network protocol stack sends data to the virtual interface TUNx or Tapx, application process A reads the data sent by the interface through the device file descriptor FD created above, and then processes it.

02 Device Creation

In addition to creating virtual devices by cloning devices /dev/net/tun and ioctl system calls in the application, you can also create virtual devices by using the IP tuntap command.

Add dev tap0 mod tap # Create tap IP tuntap add dev tun0 mod tun # Create tun/tap IP tuntap Tuntap del dev tun0 mod tun Up Device IP address add dev tap0 10.0.0.5/24 IP link set dev tap0 upCopy the code

03 top/tap drivers

The Tun/ TAP driver contains two parts, one is the character device driver and the other is the network adapter driver.

  1. Use the nic driver part to receive the network subcontract from TCP/IP protocol stack and send or vice versa received network subcontract to the protocol stack processing.
  2. Character – driven part of the network subcontracting between the kernel and user mode transmission, simulation of physical link data receiving and sending. The user program interacts with the character device /dev/net/tun through the IOCtl Read Write system call.

View tun/ TAP device drivers using Modinfo Tun and Modinfo tap:

Root @ ~ : ~ # modinfo top filename: / lib/modules / 4.14.81 bm. 15 - amd64 / kernel/drivers/net/top ko alias: devname:net/tun alias: char-major-10-200 license: GPL author: (C) 1999-2004 Max Krasnyansky <[email protected]> description: Universal TUN/TAP device driver depends: intree: Y name: Tun Vermagic: 4.14.81.BM. 15- AMD64 SMP mod_unload modversions root@~:~# modinfo tap filename: / lib/modules / 4.14.81. Bm. 15 - amd64 / kernel/drivers/net/tap ko license, the GPL author: Sainath Grandhi <[email protected]> author: Arnd Bergmann <[email protected]> depends: intree: Y name: Tap VerMAGIC: 4.14.81.BM.15 - AMD64 SMP Mod_UNLOAD ModversionsCopy the code

04 Application Scenarios

VPN

Data receiving process

​

The receiving mechanism is shown in the preceding figure. The black line is the public IP address, and the red line is the decrypted Intranet IP packet. The VPN process monitors the public IP address and port, and the data packet reaches the protocol stack through the network adapter. The VPN process decrypts and decompresses the packet, sends the data to the virtual device through the character device file, and then sends the data to the user program through the route of the protocol stack.

Data sending process

​

The sending mechanism is shown in the figure above. The red line is an Intranet IP address, and the black line is an encrypted public IP address packet. The application program sends a data packet whose destination IP address is the Intranet IP address. The data packet reaches the virtual nic and is forwarded to the character device file, which is read by the VPN process. After packet encryption, routes are routed to the NETWORK adapter through the protocol stack, and finally sent out through the network adapter on the public network.

Virtual machine (VM

Take qEMu as an example. Qemu uses qemu-netdev tap to specify tap devices.

​

As shown in the figure, the red arrow indicates the incoming direction of data packets. The steps are as follows:

  1. The network data is received from the physical nic on the Host and arrives at the bridge.
  2. Because eth0 and TAP1 are added to the bridge, BR0 forwards data from TAP1 port according to the layer-2 forwarding principle, that is, data is received by the Tap device.
  3. The Tap device notifies the corresponding FD data readable;
  4. The read action of fd copies data to user space through the character device driver of tap device to complete front-end receiving of data packets.

References:

  • Opengers. Making. IO/it/o…

  • Blog.csdn.net/zhou307/art…

  • Blog.csdn.net/xiakewudi/a…