【WireGuard】使用与运维：netns 实测、AllowedIPs 与故障模式
内容提要
本文介绍WireGuard配置与故障排查。通过双netns实验验证握手与传输，强调cryptokey routing与主机路由表需一致。常见错误包括AllowedIPs过窄或过宽、FIB脱节、NAT后Endpoint问题。建议用wg show、ip route get等工具排障，并注意MTU与静默丢弃特性。不适合L2延伸、X.509合规等场景。
延伸解读
两张表一致性是排障核心
文章强调，WireGuard 生产事故多源于 cryptokey routing 表与主机路由表不一致。配置时需同时考虑 AllowedIPs 与 ip route，否则会出现加密选不中 peer、包从其他接口出去或静默丢弃等问题。排障时应先检查 wg show 确认握手与传输，再用 ip route get 验证路由走向，确保两张表匹配。
AllowedIPs 的过窄与过宽陷阱
AllowedIPs 设置过窄会导致对端内网无法访问，过宽且冲突时则可能走错隧道。文章指出，解密后源 IP 必须落在对端 AllowedIPs 内，否则静默丢弃。配置时应精确规划前缀，避免重叠，并理解 trie 最长匹配规则，防止偶发路由错误。
NAT 场景下的 Endpoint 与漫游
NAT 后双方若都未主动发起连接，可能长期学不到 Endpoint。PersistentKeepalive 用于维持 NAT 映射，但内网静态端点通常不必。漫游时对端外层地址变化，本端会更新 Endpoint，排障时需确认 wg show 中的 Endpoint 是否为最新地址。
MTU 与静默丢弃的运维要点
WireGuard 默认 MTU 约 1420，外层开销数十字节，TCP 建议配合 MSS clamp 避免分片黑洞。静默丢弃是特性，抓包只能看到 UDP，需结合 wg show 与对端日志判断。生产环境应实测延迟与吞吐，本机 netns 的亚毫秒 RTT 不能外推。
Q&A
WireGuard中AllowedIPs配置过窄会导致什么问题？
如果AllowedIPs配置过窄，例如只包含隧道地址/32，而对端内网需要访问10.0.0.0/8，那么加密路由无法选中对端peer，导致通信失败，表现为类似-ENOKEY的错误。
如何验证WireGuard隧道是否正常工作？
可以使用wg show命令查看是否有latest handshake以及transfer字节数是否增长。如果latest handshake存在且transfer非零，说明会话活跃。另外，可以用ping测试隧道IP，但注意第一次ping会包含握手开销。
WireGuard中cryptokey routing和主机路由表不一致会导致什么故障？
如果cryptokey routing（wg配置）与主机路由表（ip route）不一致，可能导致数据包从其他接口发出而不进入wg0，或者加密路由选择错误，造成通信失败或流量走错隧道。
WireGuard在NAT后如何维持连接？
对于NAT后的场景，可以设置PersistentKeepalive（例如25秒）来定期发送保活包，维持NAT映射。同时，确保监听端口与源端口一致，有利于NAT穿透。
WireGuard的MTU设置有什么注意事项？
WireGuard默认MTU通常为1420字节，外层封装会额外增加开销。建议配合TCP MSS clamping，避免因内层包过大导致分片或静默丢弃。
WireGuard适合用于L2延伸或需要X.509证书合规的场景吗？
不适合。WireGuard是L3隧道，不适合L2延伸或广播域，应使用VXLAN/GRE等。对于强制X.509合规的隧道，应使用IKEv2或企业SSL VPN。
WireGuard排障时应该按什么顺序检查？
建议顺序：1. 使用wg show查看peer状态、handshake和transfer；2. 使用ip route get <目标IP>确认流量是否走wg0；3. 检查对端AllowedIPs是否包含你的内层源IP；4. 检查UDP端口（默认51820）是否被防火墙丢弃；5. 注意MTU设置。
