Shulou(Shulou.com)06/01 Report--

Today, I will talk to you about how to analyze Linux IPsec. Many people may not know much about it. In order to let everyone know more, Xiaobian summarized the following contents for everyone. I hope everyone can gain something according to this article.

This paper mainly describes the whole process of troubleshooting IPSec faults through duplicate disk, reveals the method of analyzing faults, and learns relevant knowledge through this fault.

Due to business needs, we set up VPN on some overseas nodes to facilitate data exchange between overseas nodes. One day, we set up a new VPN between two new nodes. After going online, Ping and traceroute tests showed no abnormalities. We observed that there was traffic passing through, and everything was normal in monitoring indicators. However, half an hour later, the service reported that the network between the two new nodes was blocked, and after finding the problem, the configuration was rolled back. After that, the offline back-test found that by restarting the IPsec process, the phenomenon of time-to-time impassability could be reproduced.

Next, recreate the configuration and scenario and explain the root cause of the problem.

Brief description of environment

As shown above, the A/B nodes are connected through IPsec, the network segment on the A side is 10.0.0.0/24, and the network segment on the B side is 10.0.1.0/24 and 10.0.2.0/24. Side A drops packets destined for segments 10.0.1.0/24 and 10.0.2.0/24 to Node B's IPSec Server and vice versa.

The configuration of one side is as follows:

conn Tunnel1

authby=secret

auto=start

left=%defaultroute

leftid=1.1.1.1(public IP on this side)

right=2.2.2.2(opposite public IP)

type=tunnel

ikelifetime=8h

keylife=1h

phase2alg=aes128-sha1;modp1024

ike=aes128-sha1;modp1024

auth=esp

keyingtries=%forever

keyexchange=ike

leftsubnets={10.0.1.0/24,10.0.2.0/24}

rightsubnet=10.0.0.0/24

dpddelay=10

dpdtimeout=30

dpdaction=restart_by_peer

Abnormal manifestations and causes

The abnormality is manifested by the fact that the backend service cluster of node A cannot communicate normally with the backend service of node B, but when viewing the status of IPSec service, the IPSec status is normal, and even the packets can be captured to see that data is communicated in IPSec Tunnel. However, when the communication between node A and node B is abnormal, IPSec Server does not normally forward encrypted data packets to the backend. Then check the/proc/net/xfrm_stat file and find that there is an XfrmInTmplMismatch error count that has been rising. The reason for this error is that the No matching template for states does not match. A brief description is that the SA and SP of IPSec do not match, and then the SPI of communication between nodes A and B is inconsistent through ip xfrm monitor command.

Fig. 1

Fig. 2

First of all, see Figure 2. The SPI of the Tunnel going when the request is initiated is 0x198e7538, belonging to Tunnel No. reqid 16385, and the SPI of the Tunnel going when the packet is returned is 0x9ce4e77, belonging to Tunnel No. reqid 16389. Because the IKE of the two Tunnels is different, XfrmInTmplMismatch rises. The solution is simple. Change leftsubnets={10.0.1.0/24,10.0.2.0/24} in the configuration file to leftsubnet= 0.0.0.0/0, so as to avoid the problem of inconsistent paths (PS. Because there is only one path:))

root cause analyzing

The solution exists, but one has to understand why routing errors occur when there are two IPSec tunnels. Since the above is due to the different paths back and forth caused by the problem, so look at the source code to find SPI generation rules:

https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.h

https://github.com/xelerance/Openswan/blob/master/programs/pluto/kernel.c

There is a function called get_ipsec_spi , which generates a unique SPI number, and then we see how it generates SPI numbers:

From the above, we can see that SPI generation does not take into account the subnet mask of the peer.

All of these are the steps for troubleshooting IPSec.

After reading the above, do you know more about how to analyze Linux IPsec? If you still want to know more knowledge or related content, please pay attention to the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.