WireGuard 与现代 VPN

WireGuard 与前辈的对比：
  IPsec/IKEv2 : 协议栈庞大，策略与提案组合爆炸，互操作性差
  OpenVPN     : 用户态，TLS 控制通道，配置项繁多，吞吐受限于实现
  WireGuard   : 内核态，固定密码学，约 4000 行，无算法协商

Noise_IK 握手（两报文）：
  发起方 Initiator                        响应方 Responder
  ------------------                      -----------------
  Handshake Initiation
    + 加密的静态公钥 (I 的身份)
    + 时间戳（抗重放）
    + 临时公钥 ephemeral
                       -------------->

                                            Handshake Response
                                              + 响应方临时公钥
                                              + 加密的空载荷
                       <--------------

  握手完成 → 双方派生：
    - 一对传输密钥（发送/接收各一）
    - 用于 Cookie 抗 DoS 的密钥

Cookie 抗 DoS 流程：
  1. 攻击者伪造源 IP 发送握手请求
  2. 响应方不回真实响应，而是回 Cookie Reply
     （MAC = keyed-BLAKE2s(源 IP, 服务端密钥)）
  3. 攻击者必须用正确源 IP 收到 Cookie 才能继续
  4. 伪造源 IP 收不到 → 攻击失效

AllowedIPs 双重语义：
  出方向（路由）：本机发出的包，目标 IP 匹配某 Peer 的 AllowedIPs
                 → 加密后发给该 Peer
  入方向（过滤）：从某 Peer 收到的包，源 IP 必须落在其 AllowedIPs
                 → 否则丢弃（防源地址伪造）

  例：AllowedIPs = 10.0.0.2/32, fd00::2/128
     - 发往 10.0.0.2 的包走这个 Peer
     - 只接受来自 10.0.0.2 的包

# 生成密钥对
wg genkey | tee privatekey | wg pubkey > publickey
chmod 600 privatekey

# 从已有私钥推导公钥
wg pubkey < privatekey

# 生成预共享密钥（可选，叠加后量子对称加固）
wg genpsk > preshared.key

漫游机制：
  - Peer 端点不是固定的，而是「最近一次成功解密报文的来源」
  - IP 变化后，只要对端能再次发来合法报文，端点自动更新
  - NAT 后的节点需 PersistentKeepalive = 25 秒保持映射

注意：只有一端主动发包，NAT 映射才会刷新
      → 位于 NAT 后的 Peer 设 keepalive，公网侧可不设

# /etc/wireguard/wg0.conf  —— 节点 A（10.0.0.1）
[Interface]
PrivateKey = <A 的私钥>
Address = 10.0.0.1/24
ListenPort = 51820

[Peer]
# 节点 B
PublicKey = <B 的公钥>
AllowedIPs = 10.0.0.2/32
Endpoint = 203.0.113.2:51820
PersistentKeepalive = 25

# 启停隧道
wg-quick up wg0
wg-quick down wg0

# 查看当前状态（握手时间、收发字节）
wg show

# 动态添加 Peer（无需重启）
wg set wg0 peer <公钥> allowed-ips 10.0.0.3/32 endpoint 203.0.113.3:51820

# 客户端：全流量走 VPN
[Peer]
PublicKey = <服务端公钥>
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.com:51820
PersistentKeepalive = 25
DNS = 10.0.0.1

# 服务端开启转发与 NAT
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -A FORWARD -o wg0 -j ACCEPT

Hub-and-Spoke：
  Hub AllowedIPs 含所有 Spoke 网段 → 负责路由转发
  优点：配置集中、易管控；缺点：Hub 是瓶颈与单点

Full Mesh：
  每个节点为其他所有节点配 [Peer]
  优点：无中心、延迟最低；缺点：配置 O(N²)、密钥分发复杂

# 探测隧道 MTU（外层 UDP 隧道需预留开销）
ping -M do -s 1400 -c 1 10.0.0.2

# 建议：WireGuard 默认 MTU 1420，IPv6 或额外封装时下调

# 用 wg 动态增删 Peer，无需重启接口
wg set wg0 peer <公钥> allowed-ips 10.0.0.9/32
wg set wg0 peer <公钥> remove

# 导出当前运行配置（含运行时端点），用于备份或迁移
wg showconf wg0

# 用 systemd 管理持久化
systemctl enable wg-quick@wg0

密钥轮换策略：
  - 每个节点独立密钥对，绝不共享私钥
  - 私钥权限 600，仅 root 可读
  - 定期轮换（如 90 天），先加新公钥再删旧公钥
  - PSK 可选，逐 Peer 配置，作为后量子加固

# 采集隧道健康指标（握手时间、收发字节、丢包）
wg show all dump | awk '{print $1, $5, $6, $7, $8}'

# 若 latest-handshake 长期不更新，说明隧道已断

MTU 计算（IPv4 外层）：
  1500 - 20(IP) - 8(UDP) - 32(WG) = 1440
  wg-quick 默认取 1420（留安全余量）

叠加隧道（如 WG over WG）：
  1420 - 60 = 1360，需逐层下调

# 逐字节探测隧道真实 MTU（-M do 禁止分片）
for s in 1400 1380 1360 1340; do
  ping -M do -s $s -c 1 -W 1 10.0.0.2 >/dev/null 2>&1 \
    && echo "MTU ok: $((s+28))" && break
done