basic concept

A gateway to userspace。

TUN and TAP devices are Linux kernel virtual network devices, implemented purely in software.
The OS sends messages to the user space program connected to the TUN/TAP device; the user space program can send messages to the TUN/TAP port like a physical port. In this case, the TUN/TAP device sends (or injects) packets to the OS protocol stack as if the packets were received from a physical port.
link:

TUN/TAP: The user-space application/VM can read or write an ethernet frame to the tap interface and it would reach the host kernel, where it would be handled like any other ethernet frame that reached the kernel via physical (e.g. eth0) ports. You can potentially add it to a software-bridge (e.g. linux-bridge)

how to work

TUN/TAP is a simple point-to-point or Ethernet device that does not receive data packets from physical media, but from user space programs; instead of sending data packets through physical media, they send them to user space programs.
Suppose you configure IPX on tap0, then whenever the kernel sends an IPX packet to tap0, it will be passed to the application (for example, VTun). The application program encrypts, compresses the data packet, and sends it to the opposite end via TCP/UDP. The remote application decompresses, decrypts the received data packet, and writes the data packet to the TAP device, and then the kernel processes the data packet as if the data packet came from a real physical device.
Added a TUN/TAP virtual network device driver and a related character device /dev/net/tun in the Linux kernel,The character device tun serves as an interface for exchanging data between user space and kernel space.
User space applications can interact with the drivers in the kernel through this device file, and other operations are the same as ordinary file operations. When the kernel sends a data packet to a virtual network device, the data packet is stored in a queue related to the device. It will not be copied to the user space until the user space program reads it through the open character device tun descriptor In the buffer, the effect is equivalent to that the data packet is sent directly to the user space. The principle is similar when sending data packets through the system call write.
The tun/tap driver contains two parts:Character device driver and network card driver. Use the network card driver part to accept the network sub-packet from the tcp/ip protocol stack and send or conversely pass the received network sub-packet to the protocol stack for processing. The character device driver department transfers the network between the kernel and the user mode to simulate the data reception and transmission of the physical link. The tun/tap driver achieves a good combination of the two drivers.

use

Used for encryption, VPN, tunneling, virtual machines, etc. (encryption, VPN, tunneling, virtual machines).
The purpose of the tun/tap device is to forward some data packets in the protocol stack to the user space application program, giving the user space program an opportunity to process the data packet. So the more commonly used data compression, encryption and other functions can be implemented in the application. The most commonly used scenario for tun/tap devices is VPN, including tunnel and application layer IPSec.

Application of tap/tun in libvirt

VPN

other

Common commands

root@ubuntu:~# ip tuntap help
Usage: ip tuntap { add | del } [ dev PHYS_DEV ] 
          [ mode { tun | tap } ] [ user USER ] [ group GROUP ]
          [ one_queue ] [ pi ] [ vnet_hdr ] [ multi_queue ]

Where: USER  := { STRING | NUMBER }
       GROUP := { STRING | NUMBER }

veth, tun, tap comparison

Tun is a point-to-point device, and tap is a normal Ethernet card device. In other words, the tun device does not need to have a physical address at all. The packet it receives and sends does not need arp, nor does it need to have a data link layer header. The tap device has a complete physical address and a complete Ethernet frame.

TAP (network tap) operates much like TUN however instead of only being able to write and receive layer 3 packets to/from the file descriptor it can do so with raw ethernet packets. You will typically see tap devices used by KVM/Qemu virtualization, where a TAP device is assigned to a virtual guests interface during creation.

TUN (Tunel) equipment simulates network layer equipment and processes Layer 3 packets, such as IP packets. The TAP device model is a link layer device that processes Layer 2 messages, such as Ethernet frames. TUN is used for routing, and TAP is used to create bridges.

Example (from the Internet)

Sample program

After receiving the data packet from the tun device, only print out how many bytes of the data packet have been received, and do nothing else

#include <net/if.h>
#include <sys/ioctl.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <sys/types.h>
#include <linux/if_tun.h>
#include <stdlib.h>
#include <stdio.h>

int tun_alloc(int flags)
{

    struct ifreq ifr;
    int fd, err;
    char *clonedev = "/dev/net/tun";

    if ((fd = open(clonedev, O_RDWR)) < 0) {
        return fd;
    }

    memset(&ifr, 0, sizeof(ifr));
    ifr.ifr_flags = flags;

    if ((err = ioctl(fd, TUNSETIFF, (void *) &ifr)) < 0) {
        close(fd);
        return err;
    }

    printf("Open tun/tap device: %s for reading...\n", ifr.ifr_name);

    return fd;
}

int main()
{

    int tun_fd, nread;
    char buffer[1500];

    /* Flags: IFF_TUN   - TUN device (no Ethernet headers)
     *        IFF_TAP   - TAP device
     *        IFF_NO_PI - Do not provide packet information
     */
    tun_fd = tun_alloc(IFF_TUN | IFF_NO_PI);

    if (tun_fd < 0) {
        perror("Allocating interface");
        exit(1);
    }

    while (1) {
        nread = read(tun_fd, buffer, sizeof(buffer));
        if (nread < 0) {
            perror("Reading from interface");
            close(tun_fd);
            exit(1);
        }

        printf("Read %d bytes from tun/tap device\n", nread);
    }
    return 0;
}

Demo

#--------------------------The first shell window------------------ ----
#Save the above program as tun.c, and then compile
root@ubuntu:~# gcc tun.c -o tun

#Start the tun program, the program will create a new tun device,
#The program will block here, waiting for the packet to come
root@ubuntu:~# ./tun 
Open tun/tap device: tun0 for reading...
Read 84 bytes from tun/tap device
Read 84 bytes from tun/tap device
Read 84 bytes from tun/tap device
Read 84 bytes from tun/tap device



#--------------------------The second shell window------------------ ----
#Start the packet capture program to capture the packets passing through tun0
root@ubuntu:/home/sunld# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
02:53:08.840817 IP 192.168.209.138 > 192.168.209.139: ICMP echo request, id 9828, seq 1, length 64
02:53:09.839871 IP 192.168.209.138 > 192.168.209.139: ICMP echo request, id 9828, seq 2, length 64
02:53:10.850205 IP 192.168.209.138 > 192.168.209.139: ICMP echo request, id 9828, seq 3, length 64
02:53:11.851285 IP 192.168.209.138 > 192.168.209.139: ICMP echo request, id 9828, seq 4, length 64


#--------------------------The third shell window------------------ ----
After #./tun is started, you will find that the system has an additional tun device through the ip link command.
27: tun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500
    link/none 
#The new device does not have an ip, we first match tun0 with an IP address
root@ubuntu:/home/sunld# ip addr add 192.168.209.138/24 dev tun0
#By default, tun0 is not up, use the following command to start tun0
root@ubuntu:/home/sunld# ip link set dev tun0 up

#Try to ping the IP of the 192.168.209.0/24 network segment,
#Because after receiving the data packet in our program, nothing is done, which is equivalent to discarding the data packet.
#So the ping here does not receive the return package at all,
#But in the first two windows, you can see the four icmp echo request packets sent here,
#Indicates that the data packet is correctly sent to the application, but the application did not process the packet
root@ubuntu:/home/sunld# ping -c 4 192.168.209.139 -I tun0
PING 192.168.209.139 (192.168.209.139) from 192.168.209.138 tun0: 56(84) bytes of data.

Reference

kernel doc tuntap
virtual networking devices in linux
Linux Networking Explained
Tun/Tap interface tutorial
TUN, TAP and Veth - Virtual Networking Devices Explained
The relationship between the virtual machine network card and the tap device on the linux bridge
Tun/tap of Linux virtual network device