In Linux, the implementation of the tunnel is based primarily based on two files new_tunnel.c and ipip.c
At the same time, Linux defines a new protocol type - iPip (ipproto_ipip), similar to the package type mentioned above.
The basic idea
Implementation of IP Tunnel in Linux is also divided into two components: packaging components and universal components, respectively, respectively, send and receive. But both parts are achieved in different ways in different levels. The package component is implemented in a virtual device in the data link layer. All source code
/usr/src/linux/drivers/net/new_tunnel.c
In order to achieve a package, Linux implements a network device called Tunl (similar to loopback device), this device has the characteristics of other network devices. For the upper application of this device, these network devices are not distinguished, call And treatment methods are of course exactly the same.
Tunnel_init () and tunnel_xmit () are two main processes in New_Tunnel.c.
Tunnel_init () initializes the DEVICE structure associated with the device TUNL.
And tunnel_xmit () is called when transmitting data from the TUNL device, and the TUNL device acts as a package portion that implements IP tunneling technology, and completes all the operations required to encapsulate the corresponding datagram in the process, forming IPIP type IP Package and re-forwarding this packet (IP_Forward ()).
The decoder is implemented on the upper layer of IP, the system uses it as a virtual transport layer (actually has no relationship with the transport layer), and the specific processing
/usr/src/linux/net/IPv4/ipip.c.
We know, each IP data plug is handled by IP_RCV function, after performing some necessary judgments, IP_RCV will be given to the upper handler for packets sent to this unit. For the IPIP package, its processing function is IPIP_RCV (like TCP packets, like TCP_RCV, the IP layer does not distinguish). That is to say, when a destination address is from the packet of this unit, IP_RCV functions make some basic check and remove IP headers, and then subjected to IPIP_RCV. The work made by IPIP_RCV is to remove the header, restore the packet, and then put the restored packet into the corresponding reception queue (Netif_Rx ()).
From the idea of the above IP Tunnel, the idea is very clear, but due to the particularity of IP Tunnel, the level of its implementation is not simple. In fact, its packaging and universal components cannot be simply hierarchically. Although the TUNL device should be in the link layer, more work is made in the sender, such as making IPIP headers and new IP headers (these generally think is the work of the transport layer or network layer), call ip_forward forwarding new packages Nor is a network device should do. It can be said that tunl borrows the name of the network device, and a lot of work is grown, it is really 'high efficiency'. The universal part is macro looks on the network layer, solves the IPIP header, restoring the original packet is what it is divided, but after it solves the packet (XI original protocol packet), it put this Pack the corresponding protocol receiving queue. This kind of thing is not a top-level agreement, which is the obligation to interrupt the receiving program in the network device. I saw it, at this point, it seems to have to the data link layer.
Third, to achieve VPN expansion
In fact, Linux only provides a framework for achieving tunnel mechanism, and the packet protocol head in Figure II is ignored in Linux, that is, blocking head contains only packet IP heads, followed by the original IP packet. Such structures are used to transmit public data, but for a VPN, security confidentiality is an indispensable important function. We hope that the data is reliable through the tunnel and cannot be stolen and posted, then encryption and certification is essential. To achieve this idea, design the following package protocol head: 0 4 8 16 24 31
--- ----- ------------------------------------
| VER | TYPE | HLEN | OLDPACKETLEN |
------------------------------------
| DeviceID | Encapid |
------------------------------------
| Flags | Checksum |
--------------------------------------------------
| IPip Options (if any) |
--------------------------------------------------
Padding |
.
--------------------------------------------------
Figure 3, IPIP head envision
Ver: version number, facilitated
TYPE: Tunnel used to establish different purposes (possibly related to differential processing)
OldPacketlen: The length of the original packet of the tunnel
DeviceID: Apparatus ID for packet packaging
ENCAPID: Id number of this package
Flags: Sign, a total of 16 bits, preliminary definitions are as follows:
Whether signatures
4 retained
6 message key is encrypted
8-15 reserved
Checksum: head check
IPIP OPTIONS: Used to transmit some necessary data, such as message key, signature, etc.
format:
-----------------------------------
| Type | Length | Data ... |
-----------------------------------
Ok, I have this thing, we can extend Linux ip tunnel to serve our VPN. First, write two files for new_tunnel.c and iPip.c, join the processing of the IPIP header.
Next, we have to implement a key management and transfer mechanism.
Of course, the symmetric key is required, and the sequence password is used to encrypt the IP packet. From all the considerations,
We can propose logical steps for establishing VPN;
1. Preparation: Building a network installation system complete configuration, etc.
2, both ends of the tunnel send their own public passwords and device numbers, respectively
3, if necessary, generate a sequence password, then encrypt the signature to the other party
4, normal communication, ---- rest assured, your data is already safe.
In a VPN tunnel, a packet is shown in Figure 4.
/ -----------------
| | Packing IP head |
Sealing head | -----------------
| | Package Protocol head |
---------------
/ | | |
| | Original protocol head |
| | | And |
Packet data | | Original protocol data |
|. (Ciphertext).
.
| | | | |
---------------
Figure 4. VPN package structure
Several use methods
things often do not have two full beauty, you must make choices on safety intensity and communication speed, (or you need to make a choice in security intensity and Money.) Use this protocol, depending on your needs, you can have Different methods, below:
Communication between multiple internal networks across the Internet, confidentiality is not important to directly use the original framework mechanism, no encryption measures are fast, high efficiency, and the company does not need to apply for multiple IP addresses, convenient and feasible
General commercial applications, have confidential requirements to utilize sequence passwords produced in advance, and each time the security degree of encryption of the original data packet is improved, it is a very practical method. As long as the intensity is enough, it is generally difficult to decide speed.
The password is unchanged. You think is not safe enough You can implement a password transfer method yourself, replace a password every other time. Some of these handshake relationships need to be improved, interested in discussion. This method is very promising if it is developed.
Highly confidential field: Please use once and make each signature. Each time a new key and the signature are very expensive, it is almost impossible to current my country's Internet network. However, it is believed that the department in which this needs can also be managed to improve its network bandwidth, allowing network conditions to suit this application. In addition, of course, it is also possible to choose from the encryption strength itself, such as 128 bits, or 512 bits, 1024 bits.
Four, stay
mainly involved in the management of the tunnel, if the error occurs during the transmission of the package, it is very normal. When a router detects an error, it will send an ICMP package to the sender of the tunnel, but unfortunately ICMP returns In addition to the IP header, only 8 bytes of upper protocol information. It is necessary to react with this difficult ICMP information, so it is necessary to keep some status information in the tunnel end. These information mainly include:
The reaches of the other end of the tunnel
Tunnel congestion
MTU of the tunnel
At the same time, the package information sent is also needed.
