OpenVPN construction and related configuration in CentOS6.3

OpenVPN construction and related configuration in CentOS6.3

I. background

Because the company does a lot of business, it is divided into network companies and other business companies, that is, several companies are separated, not in the same place, then some data of the network company needs to be accessed by other business companies, that is, shared data can also be accessed by everyone. Many of the data shared by the network company is stored on the Linux testing machine, therefore, there is a need to use VPN.

Ii. Principles and Practices of OpenVPN

Overview:

1. Thanks to the OpenVPN team for the open source software.

2. I found some articles about OpenVPN on the Internet and found that most of them are about configuration, and few people write principles.

3. You can find the related principles of OpenVPN on the Internet.

Iii. OpenVPN Principle and Implementation-General Theory

OpenVPN implements Security Based on OpenSSL, but it is not an sslvpn in the traditional sense. It is just a common vpn that works on the ip layer rather than the transport layer. Vpn has two meanings: v, virtual, p, and private.

Virtualization means that physical cabling is not required, and only one network is implemented logically. The reason why a virtual network can be implemented and established depends on the advantages of a layered model, the layered model directly divides the network into seven layers (or five layers of TCP/IP) according to the logic meaning. Each layer only carries data regardless of the data format and content, in theory, data at any level can be carried at any other level or its current level, as a result, many XX over YY network models emerged, such as ppp over ethernet.

The over model can be divided into three types based on data layers:

The first type is that the upper layer data is carried on the lower layer, which is actually the common TCP/IP model we use;

The second type is the same-layer bearer, such as pppoe mentioned above. This type of construction is mainly to add a non-transmission logic or implement a tunnel at a transport-dominated layer, for example, in pppoe, ethernet is mainly used for LAN transmission, and its cost effectiveness is very reasonable, but it lacks the authentication mechanism. However, although ppp authentication functions are good, it lacks multi-point communication and addressing capabilities, as a transmission protocol, it is of little significance, so we use ethernet for transmission and ppp for authentication. Another example of the same layer is the IPSec tunnel mode, it encapsulates an ip datagram in another ip datagram, which actually implements the "virtual local area network" (note that it is not a vlan) in the general sense, because before the datagram arrives at the final destination, the ip address header of the outer layer is always used for routing. The ip address header of the inner layer, together with the actual data, is treated as data by the outer layer ip address. Therefore, the ip address header is not used for routing, no matter what goes through the LAN, Wan or anything in the middle, the ip datagram in the inner layer always "thinks" that he is in the LAN of the departure router, Therefore, a virtual network is implemented to implement the v in the vpn, so p, IPSec achieves the v and p together, that is, security is achieved in the process of implementing ip over ip, this is the well-known ah protocol and esp protocol. Only when security is realized can we ensure the dedicated network. Otherwise, everyone else can access your virtual network. As a vpn, IPsec will end here, however, the use of IPSec is not only so. IPSec is mainly used to ensure the security of ip datagram (because the ip layer does not provide any security protection, ipv6 is different, and IPSec is not required at all ), vpn is only an application of its tunnel mode. In addition to the tunnel mode, IPSec also has the transmission mode. Without a tunnel, the authentication or encryption function is only placed in the ip datagram, of course, you do not need an ip over.

As we all know, there is a defect in the vpn implemented by the IPSec tunneling mode, that is, it is difficult to cross the nat, because the nat needs to modify the ip header, once the ip header is modified, the final ah or esp authentication and encryption verification results will be wrong, so you cannot use the IPSec vpn in the nat network environment at will, of course, the IPSec protocol that does not involve ip header authentication can still be used. Is vpn a straw of IPSec? The authentication and encryption logic is very complex and diverse. It is not suitable for the ip layer. It is sufficient for the ip layer to quickly route and connect to different subnets, if we look at each layer of the layered model as a means of transportation, the problem will be easily solved. Transport or transport means can transport each other, while large trucks can transport small trucks, it can also be removed and transported by small trucks, while large trucks can also transport other large trucks. They can all be placed in containers and transported by ships. This is the hierarchical model, we can enable the application layer, presentation layer, or transmission layer to carry ip datagram. This is the third type of the over model, that is, the upper layer carries the lower layer. In many cases, the logic of the upper layer is more complex and the implementation is more flexible, if you want to implement highly complex logic at a low level, try this model. In this sense, the vpn implemented by IPSec is definitely not as good as ip over ssl, because it is difficult to expand IPSec, after all, it is not suitable for making significant changes in the location of the protocol stack, but the ssl scalability is very good, it is at the top of the protocol stack, even if the impact affects the application layer, for example, force http to be converted to https.

If the design idea that the lower layer should not have complex, diverse, and variable logic is correct, IPsec should not appear. In addition to expanding the address space, IPv6, the new features increase the burden on the ip layer. The complex design of IPv6 is a trick made by commercial companies to push their own interfaces or devices. However, it is inaccurate. Leave it to the historical review.

Vpn does not have to implement a tunnel. As long as the network can access each other and ensure the uniqueness of the mutual access, it is theoretically a vpn. However, the tunnel method is more representative, and various implementations are richer and more fancy.

Iv. vpn Principle and Implementation-tunnel implementation

Theoretically, a reasonable ip over ssl protocol requires some additional technical support before it can be used. You must try to unseal an ip datagram so that it is reencapsulated 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 solution is to modify the protocol stack, A lightweight ssl protocol layer is implemented under the ip layer, but it returns to the old IPSec path. Therefore, this method is not desirable. The correct method is not to modify the protocol stack, let everything stay where it should be, so ssl must be implemented at the application layer or the presentation layer. The question now is how to re-introduce the underlying ip datagram to the application layer, in addition, the standard protocol stack cannot be modified, so it is necessary to let the ip datagram continue, and then eventually flow out of a nic, so the protocol stack is available, and then you can play it freely, the reason for the data to flow out of the NIC is that the protocol stack cannot be modified, but it cannot really let it flow out of the machine. If it goes away, 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. We need to prepare a subnet for each virtual network, that is, each virtual network must have a different ip address, therefore, flexible ip configuration is 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, when the data reaches the bottom physical layer, it cannot be removed, but is returned to the user space. Therefore, the virtual Nic is a good choice.

All of the above are some theoretical knowledge of OpenVPN, and these are also collected from the Internet from the blog of the experts.

Build OpenVPN server with CentOS6

OpenVPN client configuration tutorial in Ubuntu

Build OpenVPN in Ubuntu 10.04

Ubuntu 13.04 VPN (OpenVPN) configuration and connection cannot access the Intranet and Internet at the same time

How to build a secure remote network architecture using OpenVPN in Linux

Setting up an OpenVPN Server on Ubuntu Server 14.04 to protect your privacy

Deploy Remote VPN service using OpenVPN in CentOS 6.3

For more details, please continue to read the highlights on the next page:

1 2 Next Page