6.14. IPsec 配置故障排除

VPN 连接的问题通常是因为端点之间不匹配的配置而发生的。

要确认 IPsec 连接是否已建立，请输入：

ipsec trafficstatus

# ipsec trafficstatus
006 #8: "vpn.example.com"[1] 192.0.2.1, type=ESP, add_time=1595296930, inBytes=5999, outBytes=3231, id='@vpn.example.com', lease=198.51.100.1/32

对于成功的连接，命令会显示一个带有连接名称和详情的条目。如果输出为空，则隧道没有建立。

如果端点或中间路由上的防火墙丢弃了互联网密钥交换版本 2 (IKEv2)数据包，则 ipsec up 命令会超时，并显示重复的 retransmission 消息：

181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
...

181 "vpn.example.com"[1] 192.0.2.2 #15: initiating IKEv2 IKE SA
181 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: sent v2I1, expected v2R1
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
010 "vpn.example.com"[1] 192.0.2.2 #15: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
...

您可以使用 tcpdump 工具捕获流量，并验证 IKE 或 IPsec 数据包是否被防火墙丢弃了，例如：

tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

# tcpdump -i <interface> -n -n esp or udp port 500 or udp port 4500 or tcp port 4500

请注意，tcpdump 对于诊断其他类型的 IPsec 问题很有限，因为 IKE 协议是加密的。

如果端点不是使用匹配的互联网密钥交换(IKE)版本、算法、IP 地址范围或预共享密钥(PSK)配置的，则 VPN 连接会失败。如果发现不匹配，您必须使两个端点上的设置保持一致，以便解决这个问题。

加密和封装过程增加了数据包的大小。如果数据包超过网络的最大传输单元(MTU)（通常为 1500 字节），则数据包会被碎片化。这可能导致间歇性连接失败，其中分片会丢失，且原始数据包无法被重新组装。一个常见的症状是，小数据包（例如 ping）可以正常工作，但大型数据包（如 SSH 会话）在登录后冻结。

要解决这个问题，通过在配置文件中添加 mtu=1400 选项来降低隧道的 MTU。

如果 IPsec 主机也充当 NAT 路由，则可能会错误地将 NAT 应用到用于 IPsec 隧道的数据包。例如，如果在应用 IPsec 加密前，数据包的源 IP 地址被伪装规则转换，则数据包的源不再与 IPsec 策略匹配，并且 Libreswan 在网络上以不加密的方式发送它。

要解决这个问题，请添加一条防火墙规则，该规则将 IPsec 子网间的流量从 NAT 中排除。应在 POSTROUTING 链的开头插入此规则，以确保它在常规 NAT 规则之前被处理。

nft add table ip nat
nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

# nft add table ip nat
# nft add chain ip nat postrouting { type nat hook postrouting priority 100 \; }
# nft add rule ip nat postrouting ip saddr 192.0.2.0/24 ip daddr 198.51.100.0/24 return

一个常见问题是 VPN 隧道似乎成功建立，但没有流量通过它。在这种情况下，您可以检查内核的 IPsec 状态，以检查隧道策略和加密密钥是否被正确安装。

这个过程涉及检查两个组件：

首先，检查 SPD 中是否存在正确的策略：

ip xfrm policy

# ip xfrm policy
src 192.0.2.1/32 dst 10.0.0.0/8
	dir out priority 666 ptype main
	tmpl src 198.51.100.13 dst 203.0.113.22
		proto esp reqid 16417 mode tunnel

输出应包含与 in 和 out 方向匹配的 leftsubnet 和 rightsubnet 参数的策略。如果没有看到流量的策略，Libreswan 无法创建内核规则，并且流量未加密。

如果策略存在，检查它是否在 SAD 中有相应的密钥集合：

ip xfrm state

# ip xfrm state
src 203.0.113.22 dst 198.51.100.13
	proto esp spi 0xa78b3fdb reqid 16417 mode tunnel
	auth-trunc hmac(sha1) 0x3763cd3b... 96
	enc cbc(aes) 0xd9dba399...

如果策略存在，但没有看到具有相同 reqid 的对应状态，这通常意味着互联网密钥交换(IKE)协商失败。两个 VPN 端点无法就一组密钥达成一致。

如需更详细的诊断，请将 -s 选项与其中一个命令一起使用。这个选项添加流量计数器，这帮助识别内核是否通过特定规则处理数据包。

在个别情况下，内核的 IPsec 子系统中的漏洞可能导致它丢失与互联网密钥交换(IKE)用户空间守护进程的同步。这种不同步可能会导致在协商的安全关联与内核中 IPsec 策略的实际强制间出现差异，从而可能会中断安全网络通信。要检查内核级别的错误，请显示转换(XFRM)统计信息：

cat /proc/net/xfrm_stat

# cat /proc/net/xfrm_stat

如果输出中的任何计数器（如 XfrmInError ）显示一个非零值，则这表示内核子系统存在问题。在这种情况下，开一个 支持问题单，并附加上命令的输出以及相应的 IKE 日志。

Libreswan 将事件记录到日志中。要显示 ipsec 服务的日志，请输入：

journalctl -xeu ipsec

# journalctl -xeu ipsec

如果默认日志记录级别没有提供足够的详情，请通过在 /etc/ipsec.conf 文件中的 config setup 部分中添加以下设置来启用全面的调试日志记录：

plutodebug=all
logfile=/var/log/pluto.log

plutodebug=all
logfile=/var/log/pluto.log

由于调试日志记录可以产生许多条目，因此将消息重定向到专用的日志文件可防止 journald 和 systemd 服务对消息进行速率限制。