Vpn Principle and Implementation-tunnel implementation

Vpn Principle and Implementation-tunnel implementation theoretically reasonable ip over ssl needs some additional technical support before it can be used, you must try to re-encapsulate an ip data packet by ssl. This action cannot be performed in the original standard protocol stack. The standard protocol stack does not support two-way data flow, one of the solutions is to modify the Protocol Stack and implement a lightweight ssl protocol layer under the ip layer, but then it returns to the old IPSec path, so this method is not available, the correct method is not to modify the protocol stack so that everything stays where it should be, so ssl must be implemented at the application layer or presentation layer, the problem now is how to re-introduce the lower-layer ip datagram to the above application layer, and the standard protocol stack cannot be modified, so it is necessary to let the ip datagram continue, then it finally flows out from a network card, so it goes out of the protocol stack, and then it can be used freely. The reason why the data flows out of the network card is that the protocol stack cannot be modified, but it cannot really let it flow out of the machine. If it leaves, it cannot be expected to encapsulate it with ssl. Where can it flow? The loopback device is a good choice. The data flowing from the loopback device actually flows into the loopback device. In user space, you only need to open the loopback device and then read it, note that the data cannot be read through general sockets. After all, the data is not sent to us. We need to use a packet capture method like this, and use the firewall to prevent the captured data from being forwarded, this is actually a clever way to intercept, get captured data, and then send it to a real IP address after the ssl encapsulation. What we need to configure is to send all the vpn data to the loopback device, in fact, it is to add a route. The virtual network has been established, and this seems to end. However, this is a slow issue. In the future, all vpn data will flow into the loopback through the standard protocol stack, and then enter the application layer as raw data, then, the original vpn data is encapsulated together with its original ip header as application data, which is encapsulated by the ssl protocol. Then, the data is sent to the other end of the vpn and enters from the real nic at the other end, then, because this is the end of the tunnel, the data goes directly to the application layer. At the application layer, the vpn Server waits there to get the raw vpn bare data and its ip header at the sending end, what is the purpose of the server to get this thing? What should it do next? It is just the end of the tunnel, and it is not the machine that really wants to receive data, therefore, it must re-send the data to the machine that actually needs it. Obviously, it must exist as an application-layer proxy and strip the original ip address header to obtain the original data, the data is then sent to a real destination, not to mention whether this method is possible. There are two unreasonable points that are enough to deny it. Because the vpn Server implements proxy, the data must be concentrated and removed from the ip address header, in addition, if you want to perform the same processing in the opposite direction, you must remember all ip addresses. Otherwise, data will be lost. Is the load on the vpn Server tolerable? What about performance? Second, the proxy method eliminates the transparency of the tunnel, and the destination will not know where the data comes from after receiving the data. It is regarded as sent by the vpn Server, in this way, strategic services cannot be implemented based on data source points. To sum up, the loopback device is available but not feasible, because it is closed on the local machine. That is to say, only the data that loopback goes out can enter the loopback, and it has only two exits, one read and one write are all at the application layer. You cannot write data as the stream of the physical layer to loopback. Instead, you can only use the data of the application layer to package it to loopback step by step through the protocol stack, and then unseal it back step by step, the vpn sending end faces the same problem, because only the route points the data egress to the loopback. If you do not need to capture packets (pcap), the data will not be available, and this method has a great impact on performance, in addition, complicated firewall rules should be configured to prohibit data from being forwarded into loopback, and the performance will be affected. Due to full-duplex communication between the two ends of the tunnel, as a result, one end faces the same problem on the peer end when the data is reversed. Aside from this, loopback cannot configure the IP address freely, and it cannot be selected to implement the tunnel, the vpn network needs to be managed, and sometimes the management itself is very complicated. The virtual network is not just one, but we need to prepare a subnet for each virtual network, that is, each Different virtual networks must have different ip addresses, so flexible ip configurations are required. Therefore, loopback cannot implement an elegant and transparent tunnel. In this case, we can return to the origin to achieve two things: first, data must be encapsulated and encapsulated step by step according to the protocol stack standards, and the protocol stack cannot be modified. Second, data cannot be removed when it reaches the bottom physical layer, but is returned to the user space, as a result, the virtual network card has become a good choice.