OpenVPN mobility transformation-identify clients with new sessioniD instead of IP/Port

Challenges of device mobility

1. the IP address of the device is often changed due to cell or mode switch.

This kind of address update is a normal behavior of mobile networks and should not be regarded as a fault or accident. Therefore, applications should be transparent and applications should not be disturbed by such incidents, so they are not responsible for handling the aftermath.

2. When a mobile device has multiple 3G/4G/2.75G NICs, you want these NICs to send and receive data at the same time.

Because these NICs generally belong to different carrier networks, their network architecture is different, generally, data packets must carry the IP address of the carrier's Nic as the source (this is generally used to perform NAT at the carrier's core network endpoint). Therefore, to support multi-carrier multi-nic load balancing, an application business flow data packet must support different IP addresses as the source. Unfortunately, even for UDP, most applications only support a single source (they call the bind for UDP socket) to reduce server complexity.

3. frequent disconnections

In the elevator, on the high-speed rail, blind spots in mountainous areas, the company's toilet... you will suddenly lose contact, and then suddenly appear! However, the application does not want to be so frustrated. For OpenVPN, after testing, a reconnection takes about five seconds, and the cost is high, push again ,... in fact, as long as your ping-restart time is small enough, the lack of signal will be quickly perceived by OpenVPN. The solution is to enlarge ping-restart, however, you do not know how long your connection has been lost.

4. RRC-related extra latency sometimes, even if you are in a good position, you will find that opening a webpage is very slow, and then it will quickly become faster. This is actually the essence of mobile networks, to reduce power consumption, the device is not always connected to the network, but runs the same mechanism as the Linux NOHZ algorithm. When the device does not send or receive data for a long time, close the connection. Different from the Linux NOHZ, the departure time of the NOHZ state is clear, which is determined by the expiration time of the next timer and the minimum value of any interruption beyond the clock, however, the RRC mechanism is different. when data is sent, it depends entirely on the same user. Therefore, when data is to be sent, you must re-access the mobile network and negotiate parameters, this will undoubtedly consume time. This jitter cannot be solved by the user application, because it depends on the implementation of the device manufacturer and the specifications of the mobile network. This is a pure network problem, so this article will not involve too much content in this regard.
The Session Layer is really important.
 
In view of the preemptive evolution of TCP/IP stack, its opponent will never lose the opportunity. Therefore, applications generally use direct interfaces over the transport layer protocol. This is a fact! For the application development interface, the data sending and receiving of an application is directly based on an INET socket, and the "connection" of a socket is identified by a quintuple. Therefore, any element of the quintuple changes, or any network event will affect the corresponding socket. The socket I/O interface manual clearly specifies the return value and error code, applications that directly call these interfaces must handle such errors. Therefore, network events directly affect applications! However, network events should not affect applications. For example, if the network is disconnected, the application may not have to take care of the problem and re-connect the application. This may be a temporary event, for example, the IP address has changed. What an application needs to do is to generate and send business data. It does not need to directly obtain and process error codes from the socket interface. The application only needs to know how much data is sent. Even if a serious event needs to be completely exited, it should not be a notification from TCP/IP. A new layer is required. For the sake of history, I would like to call it a Session Layer.
The story of OpenVPN
 
I hope that the processing layer of OpenVPN is completely isolated from the network status. Even if the IP address of the client changes, the new IP address can be used to continue communication with the server. Even if the signal is none, communication continues, that is, the network status does not disturb the processing of the OpenVPN process. To meet this requirement step by step, let's take a look at the current behavior of OpenVPN. After the two ends are connected, I tried to change the Client IP address and the server reported an error:
Wed Jan 1 00:58:46 2014 us = 822941 TLS State Error: No TLS state for client 192.168.1.199: 33512, opcode = 6

Steps to solve the problem
 
This article is not intended to express how the OpenVPN program is used on mobile devices. It can be written into a book. The main purpose of this article is to demonstrate a way to solve the problem, how can I verify the feasibility of the above ideas? I didn't get into the boiling code to implement the final solution, for example, directly modifying the OpenVPN protocol, but writing the code to death first, instantly draw a line or failure conclusion. This process requires the minimum modification of code! In order to locate the modification location, you must start with the above error. In ssl. the tls_pre_decrypt_lite function of c reports an error. This function does not have any information about multi_instance. Therefore, I know that the program has entered an abnormal stream before calling the tls_pre_decrypt_lite function, so I will find the call code of tls_pre_decrypt, in mudp. multi_get_create_instance_udp in c found:
Struct multi_instance * multi_get_create_instance_udp (struct multi_context * m ){... if (mroute_extract_openvpn_sockaddr (& real, & m-> top. c2.from. dest, true) {struct hash_element * he; const uint32_t hv = hash_value (hash, & real); struct hash_bucket * bucket = hash_bucket (hash, hv); hash_bucket_lock (bucket ); he = hash_lookup_fast (hash, bucket, & real, hv); if (he) {mi = (struct multi_instance *) He-> value;} else {// exception stream processing if (! M-> top. c2.tls _ auth_standalone | tls_pre_decrypt_lite (m-> top. c2.tls _ auth_standalone, & m-> top. c2.from, & m-> top. c2.buf) {// exception stream processing }}...}

Execution result, feasibility verification, testing, D department focuses on design, code quality, progress control, project management and various models (iterative waterfall ...). Therefore, we need to redefine hash_function and hash_compare so that they can return a value! The idea behind it is that after the hash key and hash compare results are fixed, if the client IP address is changed at this time, there is still no error, it indicates that the hash search process has nothing to do with the source IP address and port of the received data packet, the rest is to change the hash key from the fixed value to the protocol header of the received OpenVPN data. My new hash functions are as follows:
M-> hash = hash_init (t-> options. real_hash_size, fake_addr_hash_function, fake_addr_compare_function );

Uint32_t fake_addr_hash_function (const void * key, uint32_t iv) {return 0x10101010;} bool fake_addr_compare_function (const void * key1, const void * key2) {return true ;}

Wed Jan 1 00:02:11 2014 us = 389812 zhaoya/192.168.1.199: 38310 UDPv4 WRITE [77] to 192.168.1.199: 38310: P_DATA_V1 kid = 0 DATA len = 76
ASSERT (link_socket_actual_defined (c-> c2.to _ link_addr ));
It can be seen that this to_link_addr is the key. This value is generated when the OpenVPN client is connected and will not change in the future. I just need to change it to real-time update, that is, use the from address of the last packet unconditionally, which are in the context_2 struct:
Struct context_2 {... struct link_socket_actual * to_link_addr;/* IP address of remote */struct link_socket_actual from;/* address of incoming datatime */...}

Void process_outgoing_link (struct context * c) {struct gc_arena gc = gc_new (); perf_push (PERF_PROC_OUT_LINK); # if 1 // scolded me when I spoke, in fact, I often play {c-> c2.to _ link_addr = & c-> c2.from;} # endif ...}

Introduction to this article
 
If the problem cannot be prevented, ignore the problem so that it has no impact on itself. You can isolate the problem by adding one more layer! You can't keep tiangu from rain, but you can take an umbrella or put on rain boots, or change the activity to indoor, or cheer in the rain like me... if you study the atmospheric operating principles and shells that let the clouds scatter in order not to rain, you will be biased. Although you may eventually become a great scientist, at present, you may be affected by the rain.
About simulation without Simulation
 
I think it's just a joke! Some people especially do not like simulation. They especially like restoration of real scenes that are meaningless and time-consuming. In fact, this is absolutely impossible. You can only restore them as much as possible. In fact, you are also simulating them, you are also simulating. The Simulation for sublimation has removed the simulation content! If you have a layered model, you are lucky because it tells you what to simulate. A Web service fails. First, you will telnet instead of checking for any Web service faults! In order to implement the network port from which the HTTP request comes in and the HTTP response will respond to this requirement from the same network port on the server, you can use the ping with the source to test. There is no need to set up any HTTP server at all, this is the responsibility of IP routing and has nothing to do with HTTP. It is also because of this that the main problem can be grasped before this task can be handed over to network engineers who do not understand HTTP. When it comes to innovation, we need to simulate non-simulated environments, that is, simulate secondary environments to solve major problems. For the OpenVPN modification example mentioned in this article, if you want to implement a complete version at the beginning, it will be disgusting to understand the code, and then modify it. The debugging process will be time-consuming and painful, but it may not be necessary at last... be sure to control the variable variables that are easy to change. You can only manipulate one handle at a time! Sometimes, many people do not like to hear when I come up with a definite conclusion. They would rather say a conclusion with some room, because they all know that I can't simulate it. In fact, the scientific idea is not to simulate, just to simulate it! Of course, this is not suitable for software engineering, because software is more like social engineering than science! You will never be sure that this software has no vulnerabilities. You cannot smooth the plane or conduct ideological experiments in software engineering. The software that runs normally for 1000000 days may crash in the next second! Software people who have been brainwashed are all in a tense and worrying state. Of course, it is hard to understand the truth that cannot be simulated to draw a certain conclusion. But even so, when solving problems in the point rather than the engineering sense, the idea of simulating and not simulating can never be lost!