WireGuard 是一套跑在 UDP 上的现代 VPN 隧道协议，由 Jason A. Donenfeld 等人推动主线实现并入主流内核。它的取向很鲜明：密码学套件固定、配置面收窄、内核里转发路径尽量短。对运维与个人用户来说，先弄清「虚拟接口与对端」「公钥路由」「握手轮换」三条主线，比背命令行参数更有效。
什么是 WireGuard
从使用者视角，WireGuard 在本机创建名为 wg0 之类的 TUN 接口，把选中的 IP 流量封装进 UDP 发向对端；对端解密后再注入其网络栈。它不替代应用层代理，也不像传统 SSL VPN 那样嵌在浏览器里，而是操作系统级的点对点隧道。官方站点把其实现为 Linux、Windows、macOS、iOS、Android 等多端，协议说明与论文可对照阅读。
与 VPN 的一般概念 相同：隧道改变的是路径与出口，主要改变隧道路径与出口表现，不自动消除身份关联；与 代理 相比，WireGuard 默认覆盖的是 IP 层路由所指向的前缀集合。
整体架构
逻辑上分为三类对象：Interface（本端接口）持有本机长期私钥与监听 UDP 端口；Peer（对端）用 Curve25519 公钥标识，并绑定允许通信的 IP 前缀与可达地址；数据平面在握手完成后用对称密钥加密内层 IP 包。控制面仅 UDP，无 TCP 状态机，因此「断线重连」依赖定时握手与 keepalive，而非应用层心跳协议。
Interface 与 Peer
配置文件中 [Interface] 段声明 PrivateKey、Address、DNS、ListenPort 等；每个 [Peer] 声明对端 PublicKey、Endpoint、AllowedIPs、PersistentKeepalive。一台接口可挂多个 Peer（典型星型：客户端指向服务器公钥；服务器为每个客户端各建一个 Peer）。私钥等同于通行证，应限制文件权限，避免与多台设备复用同一密钥对，否则会混淆 Cryptokey 路由所依赖的身份绑定。
公钥与私钥
长期身份基于 Curve25519：从 32 字节私钥导出公钥，对端预置公钥才能完成 Noise 握手。可选 PresharedKey 在握手时按协议混入，提供额外对称材料；未配置时协议按全零 32 字节处理。密钥轮换发生在会话层：临时密钥每次握手重新生成，长期密钥则仅在人为轮换时更换。
Noise Protocol Framework（Noise_IKpsk2）
WireGuard 握手机制取自 Noise 框架，构造标识符为 Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s：IK 表示发起方已知晓响应方静态公钥；psk2 表示可混合预共享密钥。握手分两报文完成，随后在双方派生发送与接收对称密钥。Noise 设计目标包含握手阶段的身份保密、前向保密与抵抗密钥泄露冒充等性质，WireGuard 论文与官网协议页给出了逐字段布局。
Curve25519、ChaCha20-Poly1305、BLAKE2s、SipHash24
- Curve25519：ECDH 交换共享秘密，用于握手阶段。
- ChaCha20-Poly1305：按 RFC 8439（更新并取代 RFC 7539）AEAD 保护数据包；nonce 由 32 位零与 64 位小端计数器组成。
- BLAKE2s：哈希与带密钥 MAC，配合 HKDF（RFC 5869）派生会话密钥。
- SipHash24：实现内部哈希表键，缓解哈希洪水类 DoS。
算法组合固定，避免 OpenVPN/IPsec 时代「选配弱 cipher」的配置坑，也方便第三方实现互操作审计。
Cryptokey Routing
这是 WireGuard 路由语义的核心：每个 Peer 公钥绑定一组 AllowedIPs。出站时按目的地址前缀挑选 Peer 加密；入站解密后，仅当源 IP 属于该 Peer 允许列表才接受，否则丢弃。因此配置错误常表现为「能握手却无流量」或「非对称路由黑洞」。Hub 型部署里，服务器给客户端的 AllowedIPs 往往是单主机 /32，而客户端把默认路由 0.0.0.0/0 指向服务器，实现全隧道。
握手与密钥轮换
官方描述为基于时间的周期性重握手，辅以报文计数阈值，在丢包网络仍保持前向保密。定时器族包括：未收到响应则带抖动的重试；长时间无下行则发空包 keepalive；会话密钥过龄或报文数超限则强制新握手；过期密钥与计数器超限的报文直接拒绝。响应方在新会话建立后，须收到发起方首个加密包（可为 padding 空包）才确认切换，避免半开状态乱序。
Persistent Keepalive
NAT 后的客户端若长时间无上行，映射会超时。对端设置 PersistentKeepalive = 25 一类数值时，内核按间隔发送空载荷包维持映射，也有助于触发定时握手。间隔过短徒增流量，过长则漫游后首包可能失败，需与网络运营商 NAT 行为折中。
Endpoint 漫游
移动端切 Wi-Fi 与蜂窝时，源 UDP 口与 IP 常变。WireGuard 在收到合法加密包时学习来源 IP/端口并更新 Peer 的当前 Endpoint，无需手工改配置。防火墙需持续允许入站 UDP 到监听端口；对称 NAT 场景下，keepalive 对学习地址尤为重要。
AllowedIPs
除 Cryptokey 过滤外，AllowedIPs 还驱动系统路由：安装配置时添加指向隧道接口的前缀。分流（split tunnel）即只把特定前缀写入 AllowedIPs，其余仍走本地默认网关。与策略路由、多表路由共存时，要留意 metric 与「排除局域网」条目，避免本地打印机或组播被误吸入隧道。
MTU
外层 UDP、WireGuard 头与 AEAD 扩张减少有效 MSS。若路径 MTU 发现失败，大包可能黑洞或频繁分片。常见做法把接口 MTU 设为 1280–1420 区间并实测，或在 TCP 侧依赖 MSS clamp。跨国链路、PPPoE 与移动网络对 MTU 格外敏感。
DNS 与路由注意点
接口级 DNS = ... 会提示解析器走隧道，但若系统或浏览器另启 DoH，仍可能出现查询路径与隧道不一致，参见 DNS 泄露。全隧道时默认路由与「不走隧道的内网前缀」要一并列出；Linux 下 Table = off 等进阶项避免劫持不该进隧道的表项。
协议边界与局限
WireGuard 不做用户账户体系、不做内容审计、不内置多级权限；认证仅是「持有对应私钥」。拒绝服务缓解依赖 cookie 回复与 MAC 校验，高负载下可能延迟握手。它也不解决隧道出口之后的日志、恶意软件与钓鱼问题。
典型部署场景
- 远程接入公司内网：AllowedIPs 只包含内网段，日常互联网仍本地出口。
- 公共 Wi-Fi 加固：全隧道至自建或可信 VPS，叠加 HTTPS，见 公共 Wi-Fi。
- 站点间专线替代：两端公钥互认，静态 Endpoint，配合防火墙仅放行 UDP 端口。
- 手机漫游：开启适度 PersistentKeepalive，接受 Endpoint 自动更新。
选型时把「协议现代」与「谁拿着服务器私钥、是否记录连接元数据」分开评估；WireGuard 解决的是隧道上的密码学目标，运营信任仍需你自行判断。
延伸阅读：VLESS。