Think about the development direction of openvpn

Openvpn supports Server mode from 2.0, that is, it supports multiple client connections. Previously, it was P2P, just a one-to-one connection. One client corresponds to one server. Later, with server mode, multiple Clients can connect to one server. Then, it may be in the peer-to-peer mode. All the terminals entering the VPN can communicate with each other in a completely peer-to-peer manner, or establish tunnels for each other, this equal distributed model is the best fit for future development. Maybe, in openvpn 2.1, the topology option is added, with three optional modes: net30, P2P, and subnet, next, let's draw a hypothetical conclusion.
The net30 name is weird. What does net30 mean? In fact, it is a mask. Ipv4 has a total of 32 bits. The 30-bit mask contains the remaining positions of the two hosts, leaving the remaining positions of 00 and 11. For example, after the server is started, configure a P2P address for tun0: ifconfig tun0 10.0.0.1 pointopoint 10.0.0.2. What is 10.0.0.2? The answer is no. Without this address, the address is configured to be compatible with the previous network. Although it is difficult to understand this P2P configuration on the broadcast-based Ethernet under the IP network, imagine if it is not over Ethernet, P2P can understand that 10.0.0.2 is an IP address, which is not necessarily the Ethernet we are familiar with. If there is a P2P link layer, the host corresponding to the 10.0.0.2 address is available and must be directly connected to 10.0.0.1. Even if the host does not exist, there are not many configured addresses. After the server is started, two routes will be generated, the gateway of 10.0.0.0/24 is 10.0.0.2, And the egress of 10.0.0.0.2 is in tun0. With these two routes, 10.0.0.0.2 is completely transitioned and has no real meaning, what about the client? In the same way, the server assigns the customer an IP address segment with a mask of 30 and 1, and then an IP address segment is assigned to the host, another corresponding host does not exist (in broadcast networks, for example, in P2P networks, the host corresponding to this address exists, no matter how many hosts exist). It is the same as the server, in a broadcast network, this address is only used for Route transition. This design looks ugly, and there is no host IP address wasted, but it generally does not play any role, so openvpn2.1 provides another mode option, that is, P2P.
The P2P name is not strange. It is obviously point-to-point. What does it mean? If we use Zhuge Liang's Historical View to think about this problem afterwards, the P2P model has laid the groundwork for subnet. At least the client is liberated first because the server is connected by all clients, therefore, it is not easy to smoothly transition. Therefore, we should first liberate scattered clients. This historical view is also the historical view of Huang renyu, which is somewhat historical. Although lahuang was criticized by many people! In P2P mode, the client is no longer allocated with a 30-bit IP address segment, but a 32-bit Host IP Address Mask. This saves the client an IP address, obviously, the historical view must be cultivated, and the technical history must be the same. After the historical view has been established, all things come from the same origin! In order to seek the final relief, subnet became the final straw!
It is easy to understand the meaning of subnet, that is, to build a VPN into a complete and complete LAN, the server IP can be understood as a gateway, such as 10.0.0.1, only this IP address, there is no other P2P address, and the client address is the same. There is no additional IP address for compatibility, and there is only one address. In this way, the client and server become a real LAN, since the two constitute a LAN, it is easy to add new members. As vpn lan construction has become a trend, the difference between servers and clients on the virtual link layer is no longer important, servers and clients only make sense at the application layer. Next, we need to consider how to communicate once the multiple clients and a vpn lan composed of a server are formed.
Openvpn provides the client-to-client parameter option, which enables communication between clients. Client-to-client routing is not actually a three-tier routing concept, the VPN Server is not a vro in the client-to-client network, but a vswitch. After all, the LAN communication does not require a vro. Although this is a LAN built on the wide area network,
The best vpn lan is not the VPN lan that uses the server as the switch, but a LAN with all nodes completely equivalent. All nodes constitute a distributed mesh structure, the server only implements vpn lan access verification. The communication process does not require a VPN Server, and all nodes can establish a tunnel between each other. The problem is how to implement SSL connections between clients, to have an SSL connection, a server is required. As a result, the two will no longer be equal, so we need to modify our access network model. Once the node is accessible, then the communication between the two access nodes will not be authenticated but only encrypted. The remaining authentication process must be handed over to the upper-layer logic of each node, as a result, the problem is transformed into how to negotiate a shared key between the two communication personnel. This is very easy to do, And Kerberos can do it, or anything else? The next question is how to establish a tunnel between any two nodes. If so, they must know each other's real public IP addresses, add the learning function to all nodes. All the learning content is pushed by the server. The first communication between each two clients must go through the server, then, the server informs both parties of the actual public network address of the Peer end, so the next communication will not require the server, which will unload a lot of server load, if you think this solution is too troublesome or unreasonable on the LAN, try it on the WAN. The theory is, how does data actually communicate?
The tun0 IP address of a client is 10.0.0.3, the real public IP address is 23.12.34.56, The tun0 IP address of another client is 10.0.0.4, and the real public IP address is 32.21.43.65. They are connected to the tun0 IP address 10.0.0.1 at, on the VPN Server with the actual address 100.100.100.1, a hand-drawn image with ugly handwriting has explained how the client communicates with the server. Now let's look at how the client communicates. Ping is used as an example, for the first time, the ping0.4 machine of the 0.3 instance is encapsulated through a tunnel. The data reaches 0.1 and then reaches openvpn. At this time, the data that enters openvpn is a source IP address of 0.3, the destination IP address is 0.4 of the original data "stream", then openvpn writes it to tun0, after the route, the data is written to tun0, and then enters the application layer openvpn, at this time, openvpn analyzes that the destination address is 10.0.0.4, which belongs to the VPN network segment but is not its own, so it checks whether it has set the client-to-clien T. If it is set, It queries its connection table and finds that 32.21.43.65 is connected as a client, and its VPN address is 10.0.0.4. Therefore, the server views the route of 32.21.43.65, in addition, the source IP address is 0.3, and the packet for the purpose of 0.4 is added together with the IP header as the real IP address of the server, and the IP address for the purpose of 0.4 is sent to the client with the VPN address 0.4, next, the server sends the actual addresses of the 0.3 and 0.4 clients to 0.4 and 0.3 respectively, so that they can build their own tunnels ,..., after the data reaches 0.4, it is forwarded through openvpn, and the data enters tun0 for receiving. tun0 finds that it wants the data, so the transmission ends and the data arrives smoothly. In the second communication, 0.3 and 0.4 can use the IP address information learned from the 0.1 server to establish a self-built tunnel for communication. Of course, there will be some "price" to build a tunnel ", that is, negotiate the key, Kerberos, and SSL. Let's do it on your own.
Everything is reasonable. From the initial P2P VPN to the subnet VPN, the ultimate revolutionary enthusiasm for the distributed architecture is unmanageable. Everything is really reasonable. Finally, we have to use the IP over SSL protocol to attack IPSec. The tun/TAP driver can implement the IPSec of userspace, which must be consistent with the IPSec in the kernel, you need to use raw-IP to send the IP packet sent to the virtual network card after the user space is encapsulated by the IPSec protocol, the benefit of implementing the same semantics as the kernel IPSec is that it solves the NAT traversal problem. In fact, it can be consistent with the kernel VPN, but it is more flexible. Net30 is a completely P2P model, while P2P is a transitional model. subnet implements a VPN model suitable for broadcast networks such as Ethernet. From then on, if VPN is popular, it is estimated that many people no longer need to know what an Ethernet switch device is. They only need to be able to ride on the subnet of the VPN, as today's many senior development engineers are not very proficient in architecture and assembly, they do not even have to write C code or understand OS and DBS, but they are still very good and colorful in the world, with flexibility, the division of labor is more refined.