The principle and implementation of VPN--tcp or UDP

With the IP over SSL key idea, OpenVPN is an inevitable result, so not much to say, OpenVPN and OpenSSL is not at a level, although all very open. OpenVPN configuration is very complex, mainly in order to establish a more reasonable tunnel, although IPSec-implemented VPN does not differentiate between the client and the server, when the SA is established by the DH symmetric encryption key and algorithm, but based on the OpenVPN of OpenSSL is differentiated between the two, Because OpenVPN security is implemented by SSL, SSL distinguishes between the client and the server.

Virtual network card has been said a lot of, now talk about some details of the tunnel, OpenVPN can establish a TCP tunnel and UDP tunnel, TCP tunnel as the name implies is TCP to encapsulate the VPN traffic, UDP is also, but although can use UDP encapsulation, In the OpenVPN you do not need to worry about data disorder, because there is SSL on UDP, and SSL does not allow data to be out of sequence, not to say SSL, UDP-based SSL is actually TLS,SSL data because it is not streaming, but based on records, Every time a record must be read, so SSL is the storage receive and storage sent, if the following UDP transmission, then there may be packet loss or out of order, so that the reading of the record will be incorrect, in the SSL decryption especially CBC mode decryption error, so SSL must be reliable and ordered, Even with UDP, both SSL and UDP must be reliable and ordered .

So how do TCP tunnels and UDP tunnels choose? We look at a combination, aside from the TCP/UDP protocol, there are four types of tunnels, TCP in TCP,UDP in Tcp,tcp and udp,udp in UDP, and the first and last problems are the largest.

First of all, because TCP is connected, if there is a packet loss, then whether it is the tunnel or the real transceiver to re-transmit the data , the two sides re-transmit the data is actually for a purpose of a data, VPN router only provide packaging services, do not need to be responsible for packet loss, So the transceiver is responsible, but the semantics of TCP can not control such a complex strategy, it only let the two re-transmit the packet, so that once the network drops, then there will be a lot of retransmission.

UDP in UDP is the case of the opposite, the UDP will be dropped packet and lost, UDP-type tunnel aggravated the problem, the network was not the average loss of the tunnel X, using the tunnel may be dropped packets n*x, nor desirable.

Then the rest of the UDP in Tcp,tcp in UDP, actually need to consider is not in front of the protocol, but behind, because the back of the lower, we have to choose a protocol to create a tunnel instead of forcing the user to use a certain protocol, then whether TCP is good or UDP good. This seems to be a need to weigh the issue, the individual thinks that UDP is better , if the user uses TCP, then users can handle the retransmission and disorder problem, do not work VPN do; If the user uses UDP, then he does not care about packet loss and disorder, VPN does not need to superfluous with TCP to ensure that the packet is not dropped and ordered, the superfluous instead of the user to cancel the choice of UDP reasons. If a tunnel is established with TCP, the user will be using TCP to cause a retransmission storm, and the user will be significantly less efficient when using UDP.

However, with UDP, there is a problem, that is, if one of the two ends of the VPN disconnect, because UDP is disconnected, whether the normal disconnection or abnormal crashes will not send a notification to the other end, then the connection between the two sides of the connection sense must be a heartbeat to complete , In the OpenVPN can be configured through--ping and--ping-restart, if the heartbeat time is too short, although the sense of power increased, but the heartbeat does not say, at the end of the physical distance is very long, sometimes network congestion is considered to be disconnected, resulting in false positives. This is another thing worth weighing.

http://blog.csdn.net/dog250/article/details/5593466