Networking / Linux
从握手到隧道：WireGuard 如何保持简单
用一个精简模型理解 WireGuard 的密钥、握手、路由与 NAT 穿透边界。
WireGuard 的目标不是把所有网络问题都藏进 VPN，而是把加密隧道压缩成一个容易推理的接口。它负责在两个对等端之间安全地传送 IP 数据包；地址发现、名称解析和复杂的访问控制仍应由隧道外的系统处理。
一个很小的心智模型
每个对等端都有一对长期密钥。配置把对方的公钥与允许通过该对等端的地址范围关联起来。发送数据时，这个地址范围像路由表；接收数据时，它又像访问控制列表。
[Peer]
PublicKey = PEER_PUBLIC_KEY
AllowedIPs = 10.20.0.2/32
Endpoint = 203.0.113.8:51820
PersistentKeepalive = 25这种做法减少了协商状态，但没有消除现实网络的复杂性。位于 NAT 后的设备仍可能需要借助 STUNSTUNSession Traversal Utilities for NAT帮助 NAT 后设备发现自身公网地址和端口映射的协议。查看详细解释 → 理解公网映射。在更严格的网络里，还可能需要 TURNTURNTraversal Using Relays around NAT在端到端直连失败时，通过中继服务器转发媒体或数据流量的协议。查看详细解释 → 中继流量。
握手与数据传输
握手使用长期公钥确认身份，再派生短期会话密钥。会话密钥会定期轮换，所以长期运行的隧道并不是永久复用同一把加密密钥。
| 层次 | WireGuard 负责 | WireGuard 不负责 |
|---|---|---|
| 身份 | 以公钥识别对等端 | 用户账号与登录 |
| 传输 | 加密封装 IP 数据包 | 自动选择中继服务器 |
| 路由 | 根据 AllowedIPs 选择对等端 | 全局网络策略编排 |
NAT 穿透不是隧道本身
如果两个对等端都在家庭路由器后面，仅有 WireGuard 配置往往不足以让它们互相找到。实际产品会在控制平面上使用 STUNSTUNSession Traversal Utilities for NAT帮助 NAT 后设备发现自身公网地址和端口映射的协议。查看详细解释 → 探测地址，必要时退回 TURNTURNTraversal Using Relays around NAT在端到端直连失败时，通过中继服务器转发媒体或数据流量的协议。查看详细解释 → 或自有中继。浏览器实时通信中的 WebRTCWebRTCWeb Real-Time Communication让浏览器和原生应用进行实时音视频及数据通信的一组开放标准。查看详细解释 → 也面对相似问题，但协议栈和信令方式不同。
这条边界很重要：WireGuard 提供可审计的加密数据平面，周围的协调系统则负责发现、密钥分发和策略。