As one of the underlying infrastructures of the edge virtual machine, the importance of the network is self-evident. It is responsible for the north-south and east-west traffic connectivity functions of the virtual machine instance, and the tun/tap device is the qemu that connects the internal and external networks of the vm. important virtual devices.
This article will introduce the principle and application of tun/tap equipment in detail, and hope that readers can have a more comprehensive understanding of tun/tap network equipment through the introduction of this article.
The tun/tap device is a virtual network device in the operating system kernel. It is a network device simulated by software and provides exactly the same functions as a hardware network device. It is mainly used to transmit messages between user space and kernel space.
The difference between the tun/tap device and the physical network card is shown in the figure above:
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 the tun/tap device, one end is connected to the application program (via character device file /net/dev/tun), and the other end is connected to the network protocol stack.
1. Working principle
How it works
From the above figure, you can see the difference between tun/tap devices and physical devices more intuitively: although one end of them is connected to the network protocol stack, the other end of the physical network card is connected to the physical network, while the other end of the tun/tap device is connected to It is an application layer program, so that the data packet sent by the protocol stack to tun/tap can be read by this application program. At this time, the application program can make some custom modifications to the data packet (such as encapsulating it into UDP), Then send it out through the network protocol stack-in fact, this is how most “proxies” work today.
The virtual network card driver provided by the Tun/tap device is no different from the real network card driver from the perspective of the tcp/ip protocol stack.
Work Mode
There are two modes of tun/tap, tun mode and tap mode. The tun device works exactly like the tap device, with the following differences:
1. The Tun device is a layer-3 device. It reads IP data packets from the /dev/net/tun character device, and only writes IP data packets. Therefore, it cannot perform layer-2 operations, such as sending ARP requests. and Ethernet broadcasting.
2. The Tap device is a Layer 2 device, which processes Layer 2 MAC layer data frames. It reads MAC layer data frames from the /dev/net/tun character device, and only writes MAC layer data frames. From this point of view, the capabilities of the Tap virtual device and the real physical network card are closer, and it can be bridged with the physical network card.
Notes:
- Whether it is a tun or a tap device, a new tun or tap device is created in the kernel through the open/dev/net/tun character device file through the ioctl system call, and the created device will not appear in the form of a file in /dev /, you can see the corresponding network interface tunx or tapx under sys/class/net/.
- The device /dev/net/tun must be opened for read/write. Also known as the clone device, this device is the starting point for creating any tun/tap virtual interface.
- When the open system call is executed, VFS will allocate an independent kernel state file structure for this open. That is to say, each time the open is executed, the kernel allocates different file structure instances for this open, representing different character devices.
Application data sending and receiving process:
1. Data sending: Application process A opens/dev/net/tun character device, creates a virtual interface tunx or tapx through ioctl call, and the ioctl call returns the file descriptor fd representing the corresponding tunx or tapx device, Application A writes formatted data through this file descriptor fd, and the data reaches the protocol stack through the virtual network card driver. For the protocol stack, the data is the same as received from a real network card.
2. Data receiving: When the network protocol stack sends data to the virtual interface tunx or tapx, the application process A reads the data sent by the interface through the device file descriptor fd created above, and then processes it .
2. Device creation
In addition to creating virtual devices by cloning device /dev/net/tun and ioctl system calls in the application, they can also be created by the ip tuntap command.
# create tun/tap device ip tuntap add dev tap0 mod tap # create tap ip tuntap add dev tun0 mod tun # create tun # delete tun/tap device ip tuntap del dev tap0 mod tap # delete tap ip tuntap del dev tun0 mod tun # delete tun # Set ip address, up device ip address add dev tap0 10.0.1.5/24 ip link set dev tap0 up
Third, tun/tap driver
The Tun/tap driver contains two parts, one part is the character device driver, and the other part is the network card driver.
1. Use the network card driver to receive and send network packets from the TCP/IP protocol stack, or in turn pass the received network packets to the protocol stack for processing.
2. The character driver part transmits the network packet between the kernel and the user state, simulating the data reception and transmission of the physical link. User state program through ioctl read write system
Call for data interaction with the character device /dev/net/tun.
View tun/tap device drivers with modinfo tun and modinfo tap:
root@~:~# modinfo tun filename: /lib/modules/4.14.81.bm.15-amd64/kernel/drivers/net/tun.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: 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 modversions
Fourth, application scenarios
1. VPN
Receiving data process
The receiving mechanism is shown in the figure above, the black line is the public network IP, and the red line is the decrypted intranet IP packet. The VPN process listens to the public network IP + port. The data packet reaches the protocol stack through the network card and reaches the VPN process. After the VPN process decrypts and unpacks, the data is sent to the virtual device through the character device file, and the protocol stack is routed again, and finally the The data is sent to the user program.
Send data process
The sending mechanism is shown in the figure above, the red line is the internal network IP, and the black line is the encrypted public network IP packet. The application sends a data packet whose destination IP is the intranet IP, reaches the virtual network card, transfers to the character device file, and is read by the VPN process. After the packet is encrypted, it is routed to the network card through the protocol stack, and finally sent out through the public network card.
2. Virtual machine VM
Take qemu as an example, when qemu starts, specify the tap device through qemu -netdev tap:
As shown in the figure, the red arrow indicates the incoming direction of the data packet. Steps:
- Network data is received from the physical network card on the Host and reaches the bridge;
- Since both eth0 and tap1 are added to the bridge, according to the two-layer forwarding principle, br0 forwards the data from the tap1 port, that is, the data is received by the Tap device;
- The Tap device notifies that the corresponding fd data is readable;
- The read action of fd copies the data to the user space through the character device driver of the tap device, and completes the front-end reception of the data message.
Author: Volcano Engine Edge Cloud
Link: https://juejin.cn/post/7057833934947614750
Source: Rare Earth Nuggets
Copyright belongs to the author. For commercial reprint, please contact the author for authorization, for non-commercial reprint, please indicate the source.