VPS Wi-Fi Calling / IKEv2 抓包排查：UDP 500、4500 只发不收怎么办？

Wi-Fi Calling（VoWiFi）通常通过运营商的 ePDG 网关建立 IKEv2/IPsec 隧道。遇到“VPS 能发包，却收不到响应”时，先用抓包确定问题发生在哪一段，而不是直接认定 VPS 服务商或手机卡运营商有故障。

本文命令在 Linux VPS 上执行。以下 IP 来自一次实际排查记录，仅作示例；使用时替换为自己的 VPS 公网 IP、运营商网关 IP 和网卡名称。抓包可能包含公网 IP、会话标识等信息，公开日志或 pcap 前应脱敏。

一、确定出口网卡和源地址

ip route get 31.94.76.9
ip -br addr show ens3

示例中使用文档专用保留地址 203.0.113.10（并非真实服务器地址）。路由显示目标 31.94.76.9 走 ens3，源地址是 203.0.113.10。如果实际网卡不是 ens3，后续命令需要替换。

二、抓取指定网关的 IKEv2/IPsec 数据包

tcpdump -ni ens3 -tttt -vv \
  'host 31.94.76.9 and (udp port 500 or udp port 4500)'

-n：不进行域名和端口名称解析。
-i ens3：监听指定网卡；-i any 可监听全部接口。
-tttt：输出可读日期与时间。
-vv：显示更详细的协议字段。

按 Ctrl+C 结束。若看到 0 packets captured，只说明在该过滤条件和抓包期间没有捕获到匹配的数据包，不代表整个 VPS 没有网络流量。

三、不限定网关 IP，检查 UDP 500/4500

tcpdump -ni any 'udp port 500 or udp port 4500'

这一步尤其重要：排查记录中，曾先观察到目的地址为 31.94.76.6 的 IKEv2 请求，后来又观察到 31.94.76.9。如果只过滤其中一个 IP，可能漏掉实际通信。

典型输出：

ens3 Out IP 203.0.113.10.51135 > 31.94.76.6.isakmp: isakmp: parent_sa ikev2_init[I]

Out 表示从 VPS 发出；ikev2_init[I] 表示 IKEv2 发起端发送初始协商请求。它不是隧道建立成功的证明。

四、同时抓 UDP 500、4500 和 ICMP

tcpdump -ni ens3 -vv \
  'udp port 500 or udp port 4500 or icmp'

如果只想查看与指定网关有关的流量，可进一步收窄：

tcpdump -ni ens3 -tttt -vv \
  'host 31.94.76.9 and (udp port 500 or udp port 4500 or icmp)'

实际抓包多次出现类似：

203.0.113.10.53620 > 31.94.76.9.isakmp:
isakmp 2.0 ... parent_sa ikev2_init[I]

请求在约 2 秒、6 秒、12 秒、24 秒的间隔后继续重传，却未观察到该网关发回的 IKEv2 响应。这说明 VPS 抓包点能看到出站 IKE_SA_INIT 请求，但尚未确认对端收到请求，也未确认返回流量在哪一跳丢失。

同一次抓包还能看到其他地址发来的 ICMP echo request，以及 VPS 发出的 echo reply，说明网卡具备一定的双向 IP 通信能力；但 ICMP 正常不等于 UDP 500/4500 正常。

关于 bad udp cksum

如果出站包出现：

[bad udp cksum ...]

不必立即认定 UDP 包损坏。虚拟机启用网卡校验和卸载（checksum offload）时，tcpdump 可能在硬件或虚拟网卡补全校验和之前看到数据包，因此显示校验和异常。可用以下命令查看卸载功能：

ethtool -k ens3 | grep -E 'tx-checksum|rx-checksum'

这只是常见解释，不能单凭提示判断实际链路中的校验和是否正确。

五、保存 pcap，方便对比或提交工单

tcpdump -ni ens3 -s 0 -w /root/ikev2-debug.pcap \
  'udp port 500 or udp port 4500 or icmp'

完成后按 Ctrl+C，再读取文件：

tcpdump -nn -tttt -r /root/ikev2-debug.pcap

如需只看指定网关的 UDP 流量：

tcpdump -nn -tttt -r /root/ikev2-debug.pcap \
  'host 31.94.76.9 and (udp port 500 or udp port 4500)'

pcap 可能包含敏感网络元数据，分享给服务商前请检查内容，避免将完整文件直接公开上传。

六、到底是 VPS 服务商还是手机卡运营商？

目前的抓包无法单独判定责任方。至少存在以下可能：

VPS 提供商或上游网络对 UDP 500/4500 的出入站流量进行过滤、限速或丢弃。
运营商 ePDG 网关未收到请求，或因源 IP、地域、策略、协议参数等原因不响应。
请求已经到达对端，但回程路由、链路过滤或中间设备导致响应未到达 VPS。
VPS 本地防火墙或网络配置影响了入站流量；需结合计数器和更靠近入口的抓包验证。

其他 VPS 服务商的服务器正常是很有价值的对照信息，说明问题可能与特定 VPS 的 IP、ASN 或网络路径有关，但并不能单独证明当前服务商故障。

建议在正常 VPS 与异常 VPS 上，尽量使用相同的客户端、运营商、目标 ePDG、测试时段和抓包条件，对比是否收到 IKE_SA_INIT 响应。同时查看 VPS 防火墙：

nft list ruleset
iptables -nvL

不同系统可能只使用其中一种防火墙机制。必要时向 VPS 服务商提交脱敏后的时间、源/目标 IP、UDP 端口、抓包结果，请其协助检查上游 ACL 和回程路径；也可以向运营商确认 ePDG 对该公网源地址的接入策略。

七、VLESS + Reality 与 Wi-Fi Calling 的关系

VLESS + Reality 与 IKEv2/IPsec 是不同的协议。即使 VLESS + Reality 代理正常，也不能证明运营商 Wi-Fi Calling 使用的 UDP 500/4500 可以正常收发。若实际测试涉及代理转发、TUN 或路由策略，还应确认 Wi-Fi Calling 流量是否真的经过该 VPS，以及出站源地址是否与预期一致。

总结

排障顺序建议是：确认网卡与路由 → 抓全部 UDP 500/4500 → 核对真实 ePDG 地址 → 同时观察 ICMP → 保存 pcap → 与正常 VPS 对比 → 联系相应网络方排查。

“看见 VPS 发出 IKEv2 请求、却没看见响应”只能定位到观察到的现象，不能直接把责任归给 VPS 提供商或手机卡运营商。