With the key idea of IP over SSL, openvpn is an inevitable result, so I will not talk much about it. openvpn and OpenSSL are not at the same level, although they are both open. The openvpn configuration is very complex, mainly to establish a more reasonable tunnel, although the VPN implemented by IPSec does not distinguish between the client and the server, the establishment of SA relies on DH symmetric negotiation encryption key and Algorithm But openvpn Based on OpenSSL is differentiated between the two, because the security of openvpn is implemented by SSL, while SSL distinguishes between the client and the server. There are already many virtual network interfaces, now let's talk about some details about the tunnel. openvpn can establish a TCP tunnel and a UDP tunnel. As the name suggests, a TCP tunnel uses TCP to encapsulate the VPN data stream and UDP is also the same, but although UDP encapsulation can be used, in openvpn, you do not need to worry about data out of order, because there is SSL over UDP, and SSL does not allow data out of order. Specifically, it should not be said that SSL, UDP-based SSL is actually TLS, because SSL data is not stream-based, but record-based, it must read a record at a time. Therefore, SSL is stored for receiving and storing the sent data. If UDP transmission is used below, in this case, packet loss or out-of-order situations may occur. As a result, the read records will be incorrect, and errors will occur during SSL decryption, especially CBC decryption, therefore, SSL must be reliable and ordered, that is, using UDP. Therefore, reliability and order must be achieved between SSL and UDP. So how to choose the TCP tunnel and UDP tunnel? Let's look at a combination. Aside from TCP/UDP, there are four kinds of tunnels: TCP in TCP, UDP in TCP, TCP in UDP, and UDP in UDP, the first and last types of problems are the biggest. First, because TCP is connected, if packet loss occurs, data will be re-transmitted either through the tunnel or by the real receiver, the data retransmitted by both parties is actually a copy of data for one purpose. The VPN Router only provides encapsulation services and does not need to be responsible for packet loss. Therefore, the receiving and receiving parties are responsible for this, however, the semantics of TCP cannot manage such a complicated strategy. It only allows both of them to re-transmit data packets. Once packet loss occurs in the network, a large number of re-transmissions will occur immediately, the opposite is true for UDP in UDP. UDP will have packet loss and will not be lost. The UDP tunnel will aggravate this problem. The average packet loss of the network without a tunnel will have X, if a tunnel is used, N * x packets may be lost, and N * x packets may not be retrieved. The remaining UDP in TCP and TCP in UDP are left. In fact, you need to consider whether the preceding in protocol is used, but later, because the lower layer We have to select a protocol to create a tunnel instead of forcing users to use a protocol. Is it good for TCP or UDP? This seems to be a matter of trade-offs. I personally think that UDP is better. If you use TCP, you can handle retransmission and out-of-order issues by yourself without using VPN, if the user uses UDP, it means that he does not care about packet loss and out-of-order. VPN does not need to use TCP to ensure no packet loss and order. The reason why the user chooses UDP is offset. If you use TCP to establish a tunnel, the user will cause a retransmission storm when using TCP, and the user's use of UDP will significantly reduce the aging rate. However, if UDP is used, a problem occurs, that is, if one of the two ends of the VPN is disconnected, no notification will be sent to the other end because UDP is disconnected normally or unexpectedly, therefore, the connection perception between the two parties must be completed through a heartbeat. In openvpn, you can configure the connection through -- ping and -- ping-Restart. If the heartbeat time is too short, although the perception is increased, however, heartbeat storms do not mean that when the physical distance between the endpoints is very long, network congestion may be considered as a disconnection, resulting in misjudgment. This is another thing worth balancing.