5.15. IPsec VPN 配置故障排除
与 IPsec VPN 配置相关的问题通常是由于几个主要原因造成的。如果您遇到此类问题，您可以检查问题的原因是否符合一下任何一种情况，并应用相应的解决方案。
基本连接故障排除
VPN 连接的大多数问题都发生在新部署中，管理员使用不匹配的配置选项配置了端点。此外，正常工作的配置可能会突然停止工作，通常是由于新引入的不兼容的值。这可能是管理员更改配置的结果。或者，管理员可能已安装了固件更新，或者使用某些选项的不同默认值（如加密算法）安装了软件包更新。
要确认已建立 IPsec VPN 连接：
# 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=100.64.13.5/32如果输出为空或者没有显示具有连接名称的条目，则隧道将断开。
检查连接中的问题：
重新载入 vpn.example.com 连接：
# ipsec auto --add vpn.example.com 002 added connection description "vpn.example.com"下一步，启动 VPN 连接：
# ipsec auto --up vpn.example.com
与防火墙相关的问题
最常见的问题是，其中一个 IPsec 端点或端点之间路由器上的防火墙将所有互联网密钥交换(IKE)数据包丢弃。
对于 IKEv2，类似以下示例的输出说明防火墙出现问题：
# ipsec auto --up vpn.example.com 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 ...对于 IKEv1，启动命令的输出如下：
# ipsec auto --up vpn.example.com 002 "vpn.example.com" #9: initiating Main Mode 102 "vpn.example.com" #9: STATE_MAIN_I1: sent MI1, expecting MR1 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 0.5 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 1 seconds for response 010 "vpn.example.com" #9: STATE_MAIN_I1: retransmission; will wait 2 seconds for response ...
由于用于设置 IPsec 的 IKE 协议已经加密，因此您只能使用 tcpdump 工具排除一小部分问题。如果防火墙丢弃了 IKE 或 IPsec 数据包，您可以尝试使用 tcpdump 工具来查找原因。但是，tcpdump 无法诊断 IPsec VPN 连接的其他问题。
捕获
eth0接口上的 VPN 协商以及所有加密数据：# tcpdump -i eth0 -n -n esp or udp port 500 or udp port 4500 or tcp port 4500
不匹配的算法、协议和策略
VPN 连接要求端点具有匹配的 IKE 算法、IPsec 算法和 IP 地址范围。如果发生不匹配，连接会失败。如果您使用以下方法之一发现不匹配，请通过匹配算法、协议或策略来修复它。
如果远程端点没有运行 IKE/IPsec，您可以看到一个 ICMP 数据包来指示它。例如：
# ipsec auto --up vpn.example.com ... 000 "vpn.example.com"[1] 192.0.2.2 #16: ERROR: asynchronous network error report on wlp2s0 (192.0.2.2:500), complainant 198.51.100.1: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)] ...不匹配 IKE 算法示例：
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com"[1] 193.110.157.148 #3: dropping unexpected IKE_SA_INIT message containing NO_PROPOSAL_CHOSEN notification; message payloads: N; missing payloads: SA,KE,Ni不匹配 IPsec 算法示例：
# ipsec auto --up vpn.example.com ... 182 "vpn.example.com"[1] 193.110.157.148 #5: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=MODP2048} 002 "vpn.example.com"[1] 193.110.157.148 #6: IKE_AUTH response contained the error notification NO_PROPOSAL_CHOSEN不匹配的 IKE 版本还可导致远程端点在没有响应的情况下丢弃请求。这与丢弃所有 IKE 数据包的防火墙相同。
IKEv2 不匹配的 IP 地址范围示例（称为流量选择器 - TS）:
# ipsec auto --up vpn.example.com ... 1v2 "vpn.example.com" #1: STATE_PARENT_I2: sent v2I2, expected v2R2 {auth=IKEv2 cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048} 002 "vpn.example.com" #2: IKE_AUTH response contained the error notification TS_UNACCEPTABLEIKEv1 的不匹配 IP 地址范围示例：
# ipsec auto --up vpn.example.com ... 031 "vpn.example.com" #2: STATE_QUICK_I1: 60 second timeout exceeded after 0 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal当在 IKEv1 中使用预共享密钥(PSK)时，如果双方没有放入相同的 PSK ，则整个 IKE 信息将无法读取：
# ipsec auto --up vpn.example.com ... 003 "vpn.example.com" #1: received Hash Payload does not match computed value 223 "vpn.example.com" #1: sending notification INVALID_HASH_INFORMATION to 192.0.2.23:500在 IKEv2 中，不匹配-PSK 错误会导致 AUTHENTICATION_FAILED 信息：
# ipsec auto --up vpn.example.com ... 002 "vpn.example.com" #1: IKE SA authentication request rejected by peer: AUTHENTICATION_FAILED
最大传输单元
除防火墙阻止 IKE 或 IPsec 数据包外，网络问题的最常见原因与加密数据包的数据包大小增加有关。网络硬件对于大于最大传输单元(MTU)的数据包进行分片处理，例如 1500 字节。通常，片会丢失，数据包无法重新组装。当使用小数据包的 ping 测试可以正常工作，但其他流量失败时，这会导致间歇性故障。在这种情况下，您可以建立一个 SSH 会话，但是一使用它，终端就会冻结，例如，在远程主机上输入 'ls -al /usr' 命令。
要临时解决这个问题，请通过将 mtu=1400 选项添加到隧道配置文件中来减小 MTU 大小。
另外，对于 TCP 连接，启用更改 MSS 值的 iptables 规则：
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
如果上一命令没有解决您场景中的问题，请在 set-mss 参数中直接指定较小的数值：
# iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1380网络地址转换(NAT)
当 IPsec 主机也充当 NAT 路由器时，可能会意外地重新映射数据包。以下示例配置演示了这个问题：
conn myvpn
left=172.16.0.1
leftsubnet=10.0.2.0/24
right=172.16.0.2
rightsubnet=192.168.0.0/16
…地址为 172.16.0.1 的系统有一个 NAT 规则：
iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE
如果地址为 10.0.2.33 的系统将数据包发送到 192.168.0.1，那么路由器会在应用 IPsec 加密前将源 10.0.2.33 转换为 172.16.0.1。
然后，源地址为 10.0.2.33 的数据包不再与 conn myvpn 配置匹配， IPsec 不会加密此数据包。
要解决这个问题，请在路由器上插入目标 IPsec 子网范围不包含 NAT 的规则，例如：
iptables -t nat -I POSTROUTING -s 10.0.2.0/24 -d 192.168.0.0/16 -j RETURN
内核 IPsec 子系统错误
例如，当 bug 导致 IKE 用户空间和 IPsec 内核不同步时，内核 IPsec 子系统可能会失败。检查此问题：
$ cat /proc/net/xfrm_stat
XfrmInError 0
XfrmInBufferError 0
...上一命令输出中的任何非零值都表示有问题。如果您遇到这个问题，请开一个新的 支持问题单，并附上上一命令的输出与对应的 IKE 日志。
libreswan 日志
默认情况下，Libreswan 使用 syslog 协议的日志。您可以使用 journalctl 命令来查找与 IPsec 有关的日志条目。因为日志中相应的条目是由 pluto IKE 守护进程发送的，因此请搜索 "pluto" 关键字，例如：
$ journalctl -b | grep pluto
显示 ipsec 服务的实时日志：
$ journalctl -f -u ipsec
如果默认日志记录级别没有显示您的配置问题，请将 plutodebug=all 选项添加到 /etc/ipsec.conf 文件的 config setup 部分来启用调试日志。
请注意，调试日志记录会生成大量的条目，journald 或 syslogd 服务的速率可能会抑制 syslog 消息。要确保您有完整的日志，请将日志记录重定向到文件中。编辑 /etc/ipsec.conf，并在 config setup 部分中添加 logfile=/var/log/pluto.log。
其他资源
- 使用日志文件对问题进行故障排除
-
tcpdump(8)和ipsec.conf(5)手册页。 - 使用和配置 firewalld
