6.14. 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

如果输出为空或者没有显示具有连接名称的条目，则隧道将断开。

检查连接中的问题：

  1. 重新载入 vpn.example.com 连接： 

    # ipsec auto --add vpn.example.com
002 added connection description "vpn.example.com"

  2. 下一步，启动 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_UNACCEPTABLE

  • IKEv1 的不匹配 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。

其他资源