Details of the Linux neighbor subsystem: confirm-OpenVPN server mode MAC address learning, confirm-openvpnmac
In the article parsing the aging time principle of ARP cache implemented by Linux, I analyzed the conversion of the neighbor subsystem of IPv4 on the Linux protocol stack and again pasted the state machine Conversion Diagram, but this figure is more detailed, because it has an external input, that is, confirm:
Note that if the socket or routing subsystem has a neighbor in the upper-layer confirm, the arp will remain in the reachable State instead of being switched to the stale state. This feature makes sense. Observe the following phenomenon:
1. the IP address of the local machine is 192.168.1.10/24, and the IP address of the directly connected machine is 192.168.1.20/24. ping the peer end of the local machine;
2. Set/proc/sys/net/ipv4/neigh/eth0/base_reachable_time of the Local Machine to 4 seconds, and set the corresponding value of the Peer end to 8 seconds;
3. Packet Capture: an arp request is sent from the peer every eight seconds;
4. No Local-to-Peer arp request is found during packet capture. It should be issued every 4 seconds;
5. Change the IP address of the Peer device to 192.168.1.30/24. The local device immediately sends an arp request after 4 seconds;
The above two problems exist:
Why does the local end still fail to switch when the reachable status expires and the peer IP address is not resolved again? Why does the local end immediately find this fact after the IP address of the Peer end is modified or deleted, and an arp request is sent after the reachable expiration time?
To clarify the two problems above, we need to gradually locate them from the bottom up. When I set iptables rules to prohibit ping reply reception on INPUT, the effect is the same as modifying and deleting the peer IP address, ping immediately finds this and sends an arp request every about 4 seconds. Therefore, the problem lies in ping itself, strace ping, and find that the last parameter of sendmsg is MSG_CONFIRM. Refer to man manual and find:
MSG_CONFIRM (Since Linux 2.3.15)
Tell the link layer that forward happss happened: you got a successful reply from the other side. If the link
Layer doesn't get this it will regularly reprobe the neighbor (e.g., via a unicast ARP). Only valid on SOCK_DGRAM
And SOCK_RAW sockets and currently only implemented for IPv4 and IPv6. See arp (7) for details.
Because the peer only receives the ping request and directly responds to the ping reply request in the protocol stack, the socket is not involved, and the related confirm such as redirect in the routing subsystem is not involved, therefore, the peer end strictly follows the status chart of the IPv4 neighbor sub-system, and the local end maintains the arp table entry in the reachable state every time ping reply is received. Once ping reply is not received, no more confirm, wait until the reachable status expires, it will enter a short stale, delay status, and then enter probe to send arp request.
After talking about so many details about arp, we aim to explain the problem of a tap-mode OpenVPN running in multi mode, that is, the MAC address learning in server mode.
We know that OpenVPN can be viewed as a virtual switch in the tap mode and is a learning type. The learning content is: associate a MAC address linked list for each multi_instance, any source MAC address from the ethereum frame of the multi_instance will enter this linked list. This linked list is used to associate a multi_instance with the data packet returned from the OpenVPN server to the client. For a packet sent from the OpenVPN server to the client, the destination MAC address must be behind an OpenVPN client or the tap Nic of the OpenVPN client. The OpenVPN server uses this MAC address as the key value to check the MAC/instance table, and finally finds a multi_instance and sends it out.
Now we want to consider a data packet sent from the OpenVPN server. When it arrives at the OpenVPN process, the data packet must be discarded because no data packet has been sent from the OpenVPN client for the OpenVPN server to learn, because it cannot correspond to any multi_instance. Is that true? NO! Because you didn't consider arp. Before sending any data packet over Ethernet, the IP address of the Peer must be resolved through arp. arp requests are broadcast and will be sent to all multi_instances. Only arp responses from an OpenVPN client are available, the OpenVPN server learns a MAC/instance table item. Therefore, there is no possibility of data packets being dropped.
However, if the IP/MAC address ing already exists when the machine behind the OpenVPN server sends data packets, then no arp request will be sent, there is no chance for the OpenVPN server to learn from the arp response, and the packets will be discarded. Is that true? Yes, but if you understand the status transition diagram of the IPv4 neighbor subsystem, you will wait for the reachable expiration time to retry again. Since data cannot be sent from the OpenVPN client, there is no chance of being confirm. The longest wait time is the reachable + stale + delay timer time and. However, if a permanent arp table item is set on the server side, it will be finished.
When OpenVPN runs in the tap mode, it can use arp to automatically learn MAC/instance ing. What about running in the tun mode? In addition to DHCP, IPv4 does not have any automatic configuration mechanism and DHCP is not required. Therefore, it can only be configured manually. In OpenVPN, This Is The iroute option, that is, Internal route.
Automatic learning is not easy. If you only want to connect two remote networks using OpenVPN, you should not use server mode. It is better to use p2p, that is, pointopoint mode, it only performs simple tun-link-tun forwarding.
