- 问题场景：WireGuard 在对端 IP 变化后连接失败
- 关键概念快速回顾
- 为什么会“连不上”——三大常见原因
- 1. Endpoint 固化导致目标不可达
- 2. NAT 映射因闲置而失效
- 3. 路由或 conntrack 缓存未更新
- 真实案例：移动热点 + 家庭服务器的“断线”谜题
- 逐步排查流程（思路化、无配置示例）
- 常见误区与细节
- 工具与命令行观察（思路说明）
- 最佳实践与策略
- 小结（要点提醒）
问题场景：WireGuard 在对端 IP 变化后连接失败
一次常见的故障：你在家里或云端部署了 WireGuard，客户端或服务端的公网 IP 是动态的（例如移动热点、家庭宽带重拨或云 VM 重启后分配新地址）。当对端 IP 变化后，隧道无法建立或数据无法双向流通。表面上看起来是“连不上”，但根源往往与 Endpoint 设置、PersistentKeepalive 维护和路由表刷新有关。
关键概念快速回顾
Endpoint：WireGuard 配置中用于指向对端的地址（IP:端口）。如果 Endpoint 写死为某个动态 IP，IP 变更后就失效。
PersistentKeepalive：用于定期向对端发送单向封包，保持 NAT 映射和穿透状态；对有中间 NAT 的场景至关重要。
路由与连接跟踪（conntrack）：操作系统路由表和内核的连接跟踪会影响流量如何被发送到 WireGuard 接口，以及旧的状态是否阻止新连接建立。
为什么会“连不上”——三大常见原因
1. Endpoint 固化导致目标不可达
许多教程建议在客户端配置文件里写入服务端的静态 Endpoint。当服务端 IP 发生变化，客户端仍尝试发包到旧地址，直到手动更新配置或重启服务，才能恢复连接。
2. NAT 映射因闲置而失效
如果一侧处于 NAT 后（家庭路由器、移动网络），没有定时包维持映射，NAT 表项会过期。其他端发起连接时，映射已被清除，反馈包无法返回。
3. 路由或 conntrack 缓存未更新
内核可能保留旧的路由/连接状态，导致数据仍尝试走错误路径或被抛弃。尤其在一侧 IP 变化但接口不重启时，这种情况容易被忽视。
真实案例：移动热点 + 家庭服务器的“断线”谜题
场景：手机（客户端）通过移动热点访问家里运行 WireGuard 的 NAS（服务端）。手机切换基站或切换 Wi‑Fi，IP 发生变化，客户端日志显示握手发送成功，但服务端没有回包。
排查思路：
- 确认服务端的 Endpoint 是否仍是旧 IP：如果服务端配置里写死了客户端 IP（不常见，但可能用于对等节点固定），会失效。
- 检查 PersistentKeepalive：若客户端未设置或间隔过长（默认没有），当手机进入省电或短时间无流量，NAT 表被清掉。
- 在服务端观察内核的 conntrack：若对端 IP 改变，旧 conntrack 条目可能阻止新建立的映射生效。
逐步排查流程（思路化、无配置示例）
1) 确认哪一侧无法连通：从两端分别尝试 Ping 对方的公开地址及 WireGuard 虚拟 IP，记录差异。
2) 检查 Endpoint 配置：是否写成了静态 IP 或者使用了域名（域名能自动解析到新 IP 吗）？若使用域名，是否有及时的 DNS 更新和客户端解析缓存刷新问题？
3) 验证 PersistentKeepalive 策略：对于处在 NAT 后的节点，确保设置了合理的保持间隔（例如几十秒到几分钟，根据运营商 NAT 超时时间调整），以维持 NAT 映射。
4) 查看操作系统路由与连接跟踪：确认内核里没有遗留的旧连接条目。必要时重载 WireGuard 接口或刷新 conntrack 表，观察是否立即恢复。
5) 检查防火墙与中间设备：NAT、端口映射、ISP ACLs 及云安全组都可能阻止新的对端 IP 入站。
常见误区与细节
误区一：只要两端都在运行，握手就会自动成功。实际上，NAT 路由状态与 Endpoint 更新机制会影响握手触发。
误区二：PersistentKeepalive 频率越高越好。保持太短会增加流量与电量消耗，尤其对移动设备不友好；太长则无法维持 NAT 映射。
误区三：域名能解决一切。这取决于 DNS 缓存、TTL 与解析频率。有些 WireGuard 客户端不会在运行时频繁解析 Endpoint 的域名。
工具与命令行观察（思路说明）
网络故障排查常用几类工具：1) 抓包工具用于查看握手/keepalive 是否发出；2) 系统日志查看是否有 handshake 错误或拒绝；3) conntrack 查看 NAT 缓存；4) 路由表查看流量路径。结合这些观察可以定位是“包没到达对端”、“对端收到但不回包”还是“回包被丢弃”。
最佳实践与策略
- 对端是动态 IP 的节点优先使用域名并配合合适的 DNS TTL。若客户端不支持运行时解析，考虑通过脚本或管理工具在 IP 变化时自动更新配置并重启 WireGuard。
- 在 NAT/移动网络场景中启用 PersistentKeepalive，设置一个折中间隔（例如 25-60 秒），兼顾电量与映射保持。
- 遇到连接问题时，不要只看 WireGuard 日志，还要检查内核 conntrack、路由表和防火墙规则是否需要刷新。
- 如果环境允许，优先在服务端使用稳定的公网地址或使用反向隧道/中继（例如 VPS 作为中转），避免频繁依赖动态公网 IP。
小结（要点提醒）
当 WireGuard 在 IP 变动场景下失联，先从 Endpoint 是否过期、PersistentKeepalive 是否合理、以及路由/conntrack 是否被旧状态卡住三方面排查。理解这三者的交互（地址解析与发送目标、NAT 映射是否被维持、内核是否仍持有旧连接状态）能快速定位并修复大部分问题。
暂无评论内容