- 为什么握手会失败？先把常见坑位列出来
- 先理解握手发生了什么（简要原理）
- 原因一：密钥或peer配置错误（最常见）
- 真实案例
- 原因二：UDP 被阻断或端口不可达（网络层问题）
- 工具对比：抓包 vs netcat
- 原因三：NAT/防火墙状态失效或路由错误
- 场景分析
- 原因四：MTU 与分片问题
- 原因五：系统时间不同步或握手超时设定问题
- 排查流程：一步步定位问题（建议顺序）
- 常用诊断工具与它们的侧重点
- 小结：定位思路比盲修更重要
为什么握手会失败？先把常见坑位列出来
WireGuard 报错“handshake failed”并不总是配置文件写错那么简单。这个提示只是说明两端的加密握手没能成功完成，背后可能有密钥、路由、网络层或系统时间等多种因素。下面从原理出发，结合 5 个最常见的原因与快速排查方法，帮助你在出现握手失败时迅速定位并解决问题。
先理解握手发生了什么（简要原理）
WireGuard 使用基于公钥的静态端对端加密，通过 UDP 交换加密的封包来建立隧道。握手依赖以下要素：
- 本地/远端的公私钥对正确且互相匹配（对端使用对方的公钥作为 AllowedIPs、endpoint 等）。
- UDP 数据包能从一端到达另一端（中间没有被阻断或丢弃）。
- 路由与防火墙策略将 WireGuard 接口流量正确放行与转发。
- 系统时间要足够同步（部分加密协议依赖时间窗口）。
原因一：密钥或peer配置错误（最常见）
表现：本地和远端配置中使用了错误的公钥、私钥，或者将公钥放错位置（例如把私钥贴到对端公钥字段）。
快速排查：
- 确认本地 private key 对应的 public key 与对端配置一致（用 wg show 或生成工具核对）。
- 核对对端的 AllowedIPs 是否包含你应该路由的地址；如果 AllowedIPs 过窄或写错，可能导致流量不走隧道。
- 检查 endpoint 地址与端口是否正确（域名解析或端口写错也会导致无法发送到正确目标）。
真实案例
某用户在客户端配置中直接将服务器端的私钥误复制到了公钥字段，导致握手一直失败。解决后将正确公钥粘回，握手马上建立。
原因二：UDP 被阻断或端口不可达（网络层问题）
表现：两端配置一致但握手仍然没有任何包到达对端（可以用抓包验证）。很多 ISP、企业网络、或移动网络会过滤 UDP 或限制指定端口。
快速排查：
- 在两端用抓包工具（tcpdump/wireshark）观察 WireGuard 使用的 UDP 端口是否有入/出包。
- 尝试将 endpoint 端口改成常见非阻断端口（例如 443 UDP 或 51820 以外的端口），观察是否恢复。
- 如果在 NAT/CGNAT 后面，考虑使用端口映射或 nginx/trojan 等透传方案，但优先确认是否真是 UDP 被过滤。
工具对比：抓包 vs netcat
tcpdump/wireshark：精准、可看到真实包与payload，适合深入分析。netcat（nc）或简单 UDP client：快速验证端口是否可达，但不展示 WireGuard 特定的加密内容。
原因三：NAT/防火墙状态失效或路由错误
表现：有包到达服务器，但没有返回，或返回的包被防火墙丢弃。常见于服务器缺少允许 WireGuard 接口转发的 iptables/nft 规则，或客户端处在对称 NAT。
快速排查：
- 检查服务器的防火墙规则是否允许 UDP 入站到 WireGuard 端口，以及允许从 WireGuard 接口转发流量（FORWARD 链）。
- 服务器确认开启了内核转发（net.ipv4.ip_forward=1）。
- 在客户端抓包监测是否收到了服务器返回的数据包；如果客户端在对称 NAT 后，可能需要服务器发起连接或使用 persistent keepalive。
场景分析
在一个常见场景中，家用路由器的双重 NAT（ISP 提供的 CGNAT + 家中路由）会导致服务器返回包无法准确找到客户端的真实端口映射，导致握手失败。通过启用 persistent keepalive（周期性向服务器发送 UDP 包），可以保持 NAT 映射，从而解决一部分问题。
原因四：MTU 与分片问题
表现：握手包能到达但响应包因过大被路径中某个设备丢弃，或者需要分片但被防火墙阻断，导致连接时断时续。
快速排查：
- 观察是否在特定网络环境（比如 VPN 嵌套）下出现问题。减小 WireGuard 接口的 MTU 通常能缓解此类问题。
- 通过分段检测工具或 tracepath 检查路径 MTU，确认是否存在小 MTU 链路。
原因五：系统时间不同步或握手超时设定问题
表现：双方配置与网络看似正常，但握手仍旧因时间窗口或重放保护触发而被拒绝。
快速排查：
- 检查两端系统时间是否同步（ntpd/chrony/status）。明显不同步的时钟会影响某些密钥派生与重放保护的逻辑。
- 确认没有因为防火墙过严而过早丢弃握手包或过短的超时设置。
排查流程：一步步定位问题（建议顺序）
下面是一个高效又通用的排查顺序，按步骤逐项过滤排除：
- 本地检查：wg show 查看接口状态、latest handshake 字段、已发送/接收字节。
- 抓包验证：在客户端和服务端分别抓取 WireGuard UDP 端口的入/出包，确认包是否到达对端。
- 核对配置：确保公私钥、peer 的 public key、endpoint、AllowedIPs 无误。
- 网络连通性：使用简单 UDP 测试（非 WireGuard）验证端口是否被 ISP/网络阻断。
- 防火墙与路由：检查 iptables/nft、sysctl 的转发设置与 NAT 状态。
- NAT 保活：如果客户端处在 NAT 后，尝试开启 persistent keepalive 并观察效果。
- 时间与 MTU：同步系统时间并尝试降低 MTU 以排除分片相关问题。
常用诊断工具与它们的侧重点
- wg / wg-quick：查看状态与简易管理，快速判断 latest handshake 与传输字节。
- tcpdump / wireshark：精确抓包，定位握手包是否发出/收到与被哪一跳丢弃。
- iptables / nft：检查转发、NAT、INPUT 链策略。
- ping / traceroute / tracepath：测试基础连通与路径 MTU。
- 系统日志（journalctl / dmesg）：观察内核网桥/驱动或防火墙对包的处理信息。
小结：定位思路比盲修更重要
面对“handshake failed”，不要急于逐条改配置。按照“确认包是否到达 → 核对密钥与 peer 配置 → 检查防火墙与 NAT 映射 → 处理 MTU/时间”等步骤有助于迅速缩小范围。常见的致命问题通常集中在密钥错误、UDP 被阻断、NAT 映射失效和防火墙策略上。把握好抓包与 wg show 两个诊断点，绝大多数故障都能被迅速排除。
如果你在现场遇到具体日志或抓包结果，也可以按上面的步骤逐项比对，通常 30 分钟内就能定位到问题所在。
暂无评论内容