【网络工程】VPN 技术工程对比：IPSec vs WireGuard vs OpenVPN

VPN（Virtual Private Network，虚拟专用网络）在公共网络上建立加密隧道，是企业分支互联、远程办公和站点间通信的基础设施。三大主流 VPN 技术——IPSec、WireGuard、OpenVPN——各有截然不同的设计哲学和工程特点。选对 VPN 影响的不仅是安全性，还有性能、运维成本和可扩展性。

一、VPN 核心概念

1.1 VPN 的分类

VPN 分类

按访问模型：
┌────────────────┐     ┌─────────────────┐
│ Site-to-Site   │     │ Remote Access   │
│ (站点间)       │     │ (远程接入)       │
├────────────────┤     ├─────────────────┤
│ 总部 ↔ 分支    │     │ 员工 → 企业网络  │
│ 固定隧道       │     │ 按需连接         │
│ 路由器/防火墙   │     │ 客户端软件       │
└────────────────┘     └─────────────────┘

按协议层：
┌─────────────────────────────────────────┐
│ L2 VPN: PPTP, L2TP, VPLS               │
│   → 传输以太网帧，透明桥接               │
│                                         │
│ L3 VPN: IPSec, WireGuard, GRE+IPSec    │
│   → 传输 IP 包，路由级互联               │
│                                         │
│ L4+ VPN: OpenVPN (TLS), SSL VPN        │
│   → 传输在 TLS/SSL 之上，穿透防火墙      │
└─────────────────────────────────────────┘

1.2 VPN 隧道封装

所有 VPN 的核心操作是封装——将原始数据包包裹在新的外层协议中：

原始 IP 包：
┌──────────┬──────────┬─────────────────────────┐
│ IP 头    │ TCP 头   │ Payload                  │
│ src→dst  │          │                          │
└──────────┴──────────┴─────────────────────────┘

VPN 封装后：
┌──────────┬───────┬──────────┬──────────┬──────────┬───────────┐
│ 外层     │ VPN   │ 加密的   │ 加密的   │ 加密的    │ 加密的    │
│ IP 头    │ 协议头 │ 内层     │ 内层     │ Payload  │ 完整性    │
│ GW→GW   │       │ IP 头    │ TCP 头   │          │ 校验      │
└──────────┴───────┴──────────┴──────────┴──────────┴───────────┘
                    ↑                                           ↑
                    └───────── 加密 + 认证保护 ──────────────────┘

封装带来的工程影响： - MTU 减小：外层协议头占据空间，内层有效 MTU 减小。IPSec ESP 约减少 50–70 字节，WireGuard 约减少 60 字节 - MSS 钳制：需要在隧道端点修改 TCP MSS，避免分片 - 性能开销：加密/解密消耗 CPU，封装/解封装增加延迟

二、IPSec 深度解析

2.1 IPSec 协议栈

IPSec 不是单个协议，而是一个协议框架。它由三个核心组件构成：

IPSec 协议栈

┌─────────────────────────────────────────┐
│            IKE (Internet Key Exchange)   │
│            密钥协商与 SA 建立             │
│            ┌───────────┬───────────┐    │
│            │  IKEv1    │  IKEv2    │    │
│            └───────────┴───────────┘    │
└──────────────────┬──────────────────────┘
                   │ 建立 SA（Security Association）
                   ↓
┌─────────────────────────────────────────┐
│            数据传输协议                   │
│     ┌──────────────┬──────────────┐     │
│     │     ESP      │     AH       │     │
│     │ (加密+认证)   │  (仅认证)    │     │
│     └──────────────┴──────────────┘     │
└─────────────────────────────────────────┘
                   │
            ┌──────┴──────┐
            │             │
     Transport Mode   Tunnel Mode
     (传输模式)        (隧道模式)

2.2 IKEv2 协商过程

IKEv2（RFC 7296）相比 IKEv1 大幅简化了协商过程。完整的 IKE SA + Child SA 建立只需 4 个消息（2 轮交换）：

发起方 (Initiator)                     响应方 (Responder)

=== IKE_SA_INIT 交换（明文，建立加密通道）===

IKE_SA_INIT Request ───────────────────→
  HDR, SAi1, KEi, Ni
  • SAi1: 提议的加密算法
  • KEi:  DH 公钥
  • Ni:   随机数 (Nonce)
                    ←─────────────────── IKE_SA_INIT Response
                                         HDR, SAr1, KEr, Nr
                                         • SAr1: 选定的加密算法
                                         • KEr:  DH 公钥
                                         • Nr:   随机数

    ← 此后所有消息加密 →

=== IKE_AUTH 交换（加密，身份认证 + 建立 Child SA）===

IKE_AUTH Request ──────────────────────→
  HDR, SK{IDi, AUTH, SAi2, TSi, TSr}
  • IDi:  身份标识
  • AUTH: 认证数据（PSK/证书）
  • SAi2: Child SA 参数
  • TSi/TSr: 流量选择器
                    ←─────────────────── IKE_AUTH Response
                                         HDR, SK{IDr, AUTH, SAr2, TSi, TSr}

    → IKE SA 和 Child SA 均已建立 ←
    → 可以开始传输 IPSec 保护的数据 ←

2.3 ESP 封装格式

ESP（Encapsulating Security Payload，RFC 4303）是 IPSec 最常用的数据传输协议，同时提供加密和认证：

ESP Tunnel Mode 封装：

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌───────────────────────────────────────────────────────────────┐
│ 外层 IP 头 (新增，src=本端GW, dst=对端GW)                       │
├───────────────────────────────────────────────────────────────┤
│                Security Parameters Index (SPI)                │ ┐
├───────────────────────────────────────────────────────────────┤ │
│                   Sequence Number                             │ │
├───────────────────────────────────────────────────────────────┤ │
│                                                               │ │
│                   IV (初始化向量)                               │ │ 认
│                                                               │ │ 证
├───────────────────────────────────────────────────────────────┤ │ 范
│                   原始 IP 头 (加密)                             │ │ 围
│                   原始 TCP/UDP 头 (加密)                        │ │
│                   Payload 数据 (加密)                           │ │
│                                                               │ │
├───────────────────────────────────────────────────────────────┤ │
│         Padding          │ Pad Length │ Next Header           │ │
├───────────────────────────────────────────────────────────────┤ ┘
│              Integrity Check Value (ICV)                      │
│              认证校验值（HMAC / GCM tag）                       │
└───────────────────────────────────────────────────────────────┘

2.4 IPSec Site-to-Site 配置（strongSwan）

# 安装 strongSwan
apt-get install -y strongswan strongswan-pki libcharon-extra-plugins

# 生成 CA 和证书
mkdir -p /etc/ipsec.d/{cacerts,certs,private}

# 生成 CA 私钥和证书
pki --gen --type ed25519 --outform pem > /etc/ipsec.d/private/ca-key.pem
pki --self --ca --lifetime 3650 \
    --in /etc/ipsec.d/private/ca-key.pem \
    --type ed25519 \
    --dn "CN=VPN CA" \
    --outform pem > /etc/ipsec.d/cacerts/ca-cert.pem

# 生成服务端证书
pki --gen --type ed25519 --outform pem > /etc/ipsec.d/private/server-key.pem
pki --req --type priv \
    --in /etc/ipsec.d/private/server-key.pem \
    --dn "CN=vpn.example.com" \
    --san vpn.example.com \
    --outform pem > /tmp/server-req.pem
pki --issue --lifetime 730 \
    --cacert /etc/ipsec.d/cacerts/ca-cert.pem \
    --cakey /etc/ipsec.d/private/ca-key.pem \
    --in /tmp/server-req.pem \
    --type pkcs10 \
    --flag serverAuth --flag ikeIntermediate \
    --outform pem > /etc/ipsec.d/certs/server-cert.pem

站点间 VPN 配置：

# /etc/swanctl/conf.d/site-to-site.conf

connections {
    site-a-to-site-b {
        version = 2                    # 使用 IKEv2
        
        local_addrs = 203.0.113.1      # 本端公网 IP
        remote_addrs = 198.51.100.1    # 对端公网 IP
        
        # IKE SA 参数
        proposals = aes256gcm16-x25519-sha256
        rekey_time = 4h
        
        local {
            auth = pubkey
            certs = server-cert.pem
            id = vpn-site-a.example.com
        }
        remote {
            auth = pubkey
            id = vpn-site-b.example.com
        }
        
        children {
            site-to-site {
                # Child SA（ESP）参数
                esp_proposals = aes256gcm16-x25519
                
                # 流量选择器：哪些流量走隧道
                local_ts = 10.1.0.0/16       # 本端内网
                remote_ts = 10.2.0.0/16      # 对端内网
                
                start_action = trap           # 按需建立隧道
                dpd_action = restart          # DPD 失败后重建
                rekey_time = 1h
            }
        }
    }
}

# 启动和验证
systemctl restart strongswan-starter

# 查看 SA 状态
swanctl --list-sas

# 输出示例：
# site-a-to-site-b: #1, ESTABLISHED
#   local  '203.0.113.1' @ 203.0.113.1[500]
#   remote '198.51.100.1' @ 198.51.100.1[500]
#   AES_GCM_16-256/PRF_HMAC_SHA2_256/CURVE_25519
#   established 120s ago, rekey in 14280s
#   site-to-site: #1, reqid 1, INSTALLED
#     AES_GCM_16-256/CURVE_25519
#     in  c123abcd, 45678 bytes, 123 packets
#     out d456efab, 34567 bytes, 98 packets
#     local  10.1.0.0/16
#     remote 10.2.0.0/16

# 测试连通性
ping -c 3 10.2.0.1

2.5 IPSec 的工程痛点

痛点	具体表现
配置复杂	IKE 参数、ESP 参数、流量选择器、身份认证——配置项多且相互依赖
NAT 穿越	需要 NAT-T（UDP 4500 封装），增加开销和复杂度
协商延迟	IKEv2 需要 2 轮交换（4 个消息），IKEv1 更需要 6–9 个消息
调试困难	协商失败时错误信息含糊，两端配置必须精确匹配
证书管理	PKI 基础设施的建立和维护成本高
代码量大	strongSwan 约 50 万行代码，攻击面大

三、WireGuard 深度解析

3.1 设计哲学

WireGuard 的设计目标是成为”VPN 中的 OpenSSH”——简单、高效、可审计。它的核心代码仅约 4,000 行（Linux 内核模块），与 IPSec 的数十万行形成鲜明对比。

WireGuard 的关键设计选择：

密码学不可协商：只使用一套固定的密码学原语，没有算法协商过程
Cryptokey Routing：公钥即身份，路由表基于公钥
无状态设计：不需要连接建立/拆除过程
沉默服务器：不响应未认证的包，对扫描不可见

3.2 密码学套件

WireGuard 使用的密码学原语（不可替换）：

用途	算法	说明
密钥交换	Curve25519	ECDH
对称加密	ChaCha20-Poly1305	AEAD
哈希	BLAKE2s	快速安全哈希
密钥派生	HKDF	基于 HMAC 的 KDF
MAC	Keyed BLAKE2s	消息认证

3.3 Cryptokey Routing

WireGuard 最核心的概念是 Cryptokey Routing——将公钥与允许的 IP 地址范围关联：

Peer A (公钥: PubA)                 Peer B (公钥: PubB)
  AllowedIPs: 10.0.0.2/32            AllowedIPs: 10.0.0.1/32
  
  发送方向：
  内核路由表 → 目标 10.0.0.2
    → 查找 WireGuard 接口的 AllowedIPs
    → 匹配 Peer B 的 AllowedIPs
    → 用 Peer B 的公钥加密
    → 发送到 Peer B 的 Endpoint
  
  接收方向：
  收到加密包 → 解密 → 获得内层源 IP
    → 验证源 IP 是否在发送方的 AllowedIPs 中
    → 通过 → 送入内核网络栈
    → 不通过 → 丢弃（防 IP 欺骗）

这个设计将路由、认证和加密统一在一个简洁的模型中。

3.4 WireGuard 握手（Noise IK）

WireGuard 使用 Noise Protocol Framework 的 IK 模式实现 1-RTT 密钥交换：

发起方 (I)                           响应方 (R)
  知道 R 的公钥                        不知道 I 是谁

Handshake Initiation ──────────────→
  sender_index: 随机
  unencrypted_ephemeral: I 的临时公钥
  encrypted_static: I 的静态公钥（用 R 的公钥加密）
  encrypted_timestamp: 当前时间戳（防重放）
  mac1: 防 DoS（cookie 机制）
  mac2: 可选 cookie

                    ←────────────── Handshake Response
                                    sender_index: 随机
                                    receiver_index: I 的 index
                                    unencrypted_ephemeral: R 的临时公钥
                                    encrypted_nothing: 确认
                                    mac1, mac2

→ 双方现在共享对称密钥 ←
→ 开始传输加密数据包   ←

Transport Data ────────────────────→
  receiver_index
  counter: 包序号（Nonce，防重放）
  encrypted_packet: ChaCha20-Poly1305 加密的 IP 包

整个握手只需要 1-RTT，而 IPSec IKEv2 需要 2-RTT。

3.5 配置与部署

# 安装 WireGuard
apt-get install -y wireguard

# 生成密钥对
wg genkey | tee /etc/wireguard/private.key | wg pubkey > /etc/wireguard/public.key
chmod 600 /etc/wireguard/private.key

服务端配置：

# /etc/wireguard/wg0.conf

[Interface]
# 隧道接口地址
Address = 10.0.0.1/24
# 服务端监听端口
ListenPort = 51820
# 私钥
PrivateKey = SERVER_PRIVATE_KEY
# 启动后自动设置路由和防火墙
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; \
         iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; \
           iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# 对端 1
[Peer]
PublicKey = CLIENT1_PUBLIC_KEY
AllowedIPs = 10.0.0.2/32

# 对端 2
[Peer]
PublicKey = CLIENT2_PUBLIC_KEY
AllowedIPs = 10.0.0.3/32, 192.168.10.0/24
# AllowedIPs 包含 192.168.10.0/24 表示该子网的流量也通过此对端路由

客户端配置：

# /etc/wireguard/wg0.conf

[Interface]
Address = 10.0.0.2/24
PrivateKey = CLIENT1_PRIVATE_KEY
# 可选：DNS 服务器
DNS = 1.1.1.1, 8.8.8.8

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = vpn.example.com:51820
# AllowedIPs = 0.0.0.0/0 表示全部流量走 VPN
AllowedIPs = 10.0.0.0/24, 192.168.0.0/16
# 每 25 秒发送一次 keepalive（穿越 NAT）
PersistentKeepalive = 25

# 启动 WireGuard
wg-quick up wg0

# 查看状态
wg show

# 输出示例：
# interface: wg0
#   public key: abc123...
#   private key: (hidden)
#   listening port: 51820
#
# peer: xyz789...
#   endpoint: 203.0.113.5:45678
#   allowed ips: 10.0.0.2/32
#   latest handshake: 12 seconds ago
#   transfer: 1.23 MiB received, 4.56 MiB sent

# 设置开机自启
systemctl enable wg-quick@wg0

3.6 WireGuard 的工程限制

限制	说明
无用户认证	只有公钥认证，不支持用户名/密码、RADIUS、LDAP
静态配置	增减 Peer 需要修改配置文件并重启（或用 wg set 动态修改）
无 DHCP	隧道 IP 必须手动分配
日志极少	设计上避免记录日志（安全考虑），调试困难
密码学固定	无法更换算法（量子计算威胁时需要升级 WireGuard 本身）
L3 only	只支持 L3 隧道（IP 层），不能桥接 L2

四、OpenVPN 深度解析

4.1 架构设计

OpenVPN 工作在用户态，使用 TLS 做控制通道加密、使用自定义协议做数据通道加密：

┌──────────────────────────────────────────────┐
│                 OpenVPN                      │
├────────────────────┬─────────────────────────┤
│   控制通道         │      数据通道            │
│   (Control Channel)│  (Data Channel)         │
├────────────────────┼─────────────────────────┤
│ • TLS 握手         │ • 对称加密传输           │
│ • 密钥协商         │ • AES-256-GCM          │
│ • 身份认证         │ • 或 ChaCha20-Poly1305  │
│ • 参数交换         │ • HMAC 认证             │
├────────────────────┼─────────────────────────┤
│ TCP/UDP 端口       │ 复用同一端口             │
└────────────────────┴─────────────────────────┘
         │                     │
    ┌────┴────┐          ┌─────┴─────┐
    │  TUN    │          │   TAP     │
    │ (L3)    │          │  (L2)     │
    └─────────┘          └───────────┘

4.2 配置实战

服务端：

# 安装
apt-get install -y openvpn easy-rsa

# 初始化 PKI
make-cadir /etc/openvpn/easy-rsa
cd /etc/openvpn/easy-rsa
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa gen-req server nopass
./easyrsa sign-req server server
./easyrsa gen-dh
openvpn --genkey secret /etc/openvpn/ta.key

# /etc/openvpn/server.conf

# 基础配置
port 1194
proto udp
dev tun

# 证书和密钥
ca /etc/openvpn/easy-rsa/pki/ca.crt
cert /etc/openvpn/easy-rsa/pki/issued/server.crt
key /etc/openvpn/easy-rsa/pki/private/server.key
dh /etc/openvpn/easy-rsa/pki/dh.pem
tls-auth /etc/openvpn/ta.key 0

# 网络配置
server 10.8.0.0 255.255.255.0
push "route 192.168.0.0 255.255.0.0"
push "dhcp-option DNS 1.1.1.1"

# 安全加固
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

# 性能优化
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"

# 保持连接
keepalive 10 120

# 权限降低
user nobody
group nogroup
persist-key
persist-tun

# 日志
verb 3
status /var/log/openvpn/status.log
log-append /var/log/openvpn/server.log

客户端：

# client.ovpn

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind

# 安全
cipher AES-256-GCM
auth SHA256
tls-version-min 1.2
remote-cert-tls server

# 证书（可内联）
<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>
<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-auth>
key-direction 1

# 性能
sndbuf 524288
rcvbuf 524288

verb 3

4.3 OpenVPN 的优劣势

优势	劣势
丰富的认证方式（证书/密码/LDAP/RADIUS）	用户态运行，性能不如内核态
支持 TCP 传输，穿透严格防火墙	TCP over TCP 的性能灾难
L2（TAP）和 L3（TUN）模式	单线程架构，无法利用多核
成熟稳定，生态丰富	代码量大（约 10 万行），审计难
跨平台支持好	握手延迟高（TLS 完整握手）
灵活的推送配置	配置选项过多，学习曲线陡

五、三者工程对比

5.1 性能对比

在相同硬件（4 核 CPU、AES-NI 支持）上的基准测试参考：

指标	IPSec (strongSwan)	WireGuard	OpenVPN
吞吐量（单流）	~900 Mbps	~950 Mbps	~400 Mbps
吞吐量（多流）	~2.5 Gbps	~3.2 Gbps	~500 Mbps
延迟（RTT 增加）	~0.5 ms	~0.3 ms	~1.5 ms
握手时间	~100 ms (IKEv2)	~5 ms (1-RTT)	~200 ms (TLS)
CPU 使用率（1Gbps）	~25%	~15%	~80%
内存使用	~50 MB	~2 MB	~30 MB
运行位置	内核	内核	用户态

WireGuard 性能领先的原因： 1. 内核态运行，避免内核-用户态切换 2. 密码学原语更高效（ChaCha20 对无 AES-NI 的设备尤其友好） 3. 无算法协商开销 4. 极简的数据包格式（头部仅 32 字节）

5.2 安全性对比

维度	IPSec	WireGuard	OpenVPN
代码量	~50 万行	~4,000 行	~10 万行
可审计性	困难	容易	中等
密码学敏捷性	高（可协商算法）	无（固定算法）	高（TLS 协商）
前向保密	DH/ECDH	强制（每次握手新密钥）	ECDHE
抗扫描	无（IKE 端口可发现）	好（不响应未认证包）	使用 tls-auth
CVE 历史	较多	极少	中等
身份管理	证书/PSK	公钥	证书/密码/多种
量子抗性	取决于配置	当前无（需升级）	取决于配置

5.3 运维复杂度对比

维度	IPSec	WireGuard	OpenVPN
初始配置	复杂	简单	中等
证书管理	需要 PKI	公钥分发	需要 PKI
NAT 穿越	NAT-T（自动）	原生支持	UDP 原生/TCP 备选
动态 IP	需要 DPD + 重协商	自动漫游	keepalive
多用户管理	配置繁琐	配置繁琐	支持 CCD
监控	复杂（多种工具）	wg show	management API
故障排查	困难	困难（日志少）	容易（详细日志）
热更新	支持（CHILD_SA 重协商）	wg set（不中断）	需要重启

5.4 选型决策

你的 VPN 使用场景？
│
├── Site-to-Site（站点间互联）
│   ├── 两端都是 Linux → WireGuard（最佳性能）
│   ├── 需要与商业防火墙互通 → IPSec（通用标准）
│   └── 需要 L2 桥接 → OpenVPN TAP 或 IPSec L2TP
│
├── Remote Access（远程接入）
│   ├── 技术团队、少量用户 → WireGuard（简单高效）
│   ├── 企业大量用户、需要 LDAP/RADIUS → OpenVPN
│   └── 需要零信任网络接入 → 考虑 Tailscale/Netbird
│
├── 穿透严格防火墙
│   ├── 只开放 443 端口 → OpenVPN TCP 443
│   └── UDP 被封锁 → OpenVPN TCP（IPSec/WG 无法使用）
│
└── 高吞吐量（>1 Gbps）
    ├── Linux 对 Linux → WireGuard
    └── 异构环境 → IPSec（硬件加速支持好）

六、WireGuard 上层方案

WireGuard 本身只提供点对点的加密隧道，缺乏用户管理、密钥分发和 NAT 穿越协调。一些上层方案弥补了这些不足：

6.1 方案对比

方案	开源	密钥管理	NAT 穿越	ACL	Web UI
原生 WireGuard	是	手动	PersistentKeepalive	手动 AllowedIPs	无
Tailscale	部分	自动 (DERP)	自动	ACL 策略	有
Netbird	是	自动 (STUN/TURN)	自动	策略引擎	有
Headscale	是	兼容 Tailscale	自动	ACL	有
wg-easy	是	Web UI	手动	无	有

6.2 Tailscale/Headscale 架构

                    ┌──────────────┐
                    │  控制平面     │
                    │ (Tailscale/  │
                    │  Headscale)  │
                    │              │
                    │ • 密钥分发    │
                    │ • ACL 策略    │
                    │ • 节点注册    │
                    └──────┬───────┘
                           │
              ┌────────────┼────────────┐
              │            │            │
         ┌────┴───┐   ┌────┴───┐   ┌───┴────┐
         │ 节点 A  │   │ 节点 B  │   │ 节点 C  │
         │        │   │        │   │        │
         │ WG     │   │ WG     │   │ WG     │
         │ 接口   │   │ 接口   │   │ 接口    │
         └───┬────┘   └───┬────┘   └───┬────┘
             │            │            │
             └────────────┼────────────┘
                     WireGuard 点对点隧道
                    （尽可能直连，否则 DERP 中继）

核心价值：把 WireGuard 从”手动配置的点对点工具”变成了”自动化的网格 VPN”。

七、VPN 故障排查

7.1 IPSec 故障排查

# 查看 IKE SA 协商状态
swanctl --list-sas

# 查看详细日志（调高日志级别）
# /etc/strongswan.d/charon-logging.conf
# charondebug = "ike 4, knl 3, cfg 2, net 2"

# 常见故障
# 1. "NO_PROPOSAL_CHOSEN" — 两端算法不匹配
#    检查 proposals 配置是否一致

# 2. "AUTHENTICATION_FAILED" — 认证失败
#    检查证书/PSK 是否匹配，ID 是否正确

# 3. "TS_UNACCEPTABLE" — 流量选择器不匹配
#    检查 local_ts/remote_ts 两端是否对称

# 4. DPD 超时导致隧道断开
#    检查 UDP 500/4500 是否被中间设备丢弃

# 抓取 IKE 协商包
tcpdump -i eth0 -nn 'udp port 500 or udp port 4500' -w /tmp/ike.pcap

7.2 WireGuard 故障排查

# 查看接口状态和对端信息
wg show wg0

# 关键排查点：
# 1. "latest handshake" 为空 → 握手未完成
#    检查：Endpoint 是否正确、UDP 端口是否开放、公钥是否匹配

# 2. 有握手但无流量 → AllowedIPs 配置错误
#    检查：AllowedIPs 是否包含目标 IP

# 3. 内核日志
dmesg | grep wireguard

# 4. 抓取 WireGuard 包
tcpdump -i eth0 -nn 'udp port 51820' -c 20

# 5. 路由检查
ip route show table all | grep wg0

7.3 OpenVPN 故障排查

# 查看服务端连接状态
cat /var/log/openvpn/status.log

# 调高日志级别临时诊断
# 在配置中设置 verb 5（范围 0-11）

# 常见故障
# 1. "TLS Error" — 证书问题
#    检查 CA 证书链、证书有效期、CRL 状态

# 2. "AUTH_FAILED" — 认证失败
#    检查用户名/密码或证书

# 3. 连接成功但无法访问内网 — 路由问题
#    检查 push route 配置、服务端 IP 转发和 NAT

# 测试控制通道连通性
# 在客户端用 telnet/nc 测试 TCP 模式
nc -zv vpn.example.com 1194

八、VPN 安全加固清单

检查项	IPSec	WireGuard	OpenVPN
使用强密码学	AES-256-GCM + ECDH P-384	默认即强	AES-256-GCM + ECDHE
前向保密	DH/ECDH	默认	ECDHE
证书/密钥轮换	定期轮换 IKE PSK/证书	定期轮换公钥对	定期轮换 CA 证书
限制访问	流量选择器	AllowedIPs	iptables + CCD
DPD 检测	启用 DPD	内置（passive）	keepalive
日志与审计	charon 日志	内核日志	openvpn 日志
防火墙规则	只开放 500/4500 UDP	只开放 51820 UDP	只开放 1194 UDP
避免 PSK	使用证书认证	不适用（公钥）	使用证书

参考文献

RFC 7296, “Internet Key Exchange Protocol Version 2 (IKEv2),” IETF, 2014.
Donenfeld, J.A., “WireGuard: Next Generation Kernel Network Tunnel,” NDSS, 2017.
OpenVPN Inc., “OpenVPN Community Documentation,” openvpn.net/community-resources.
strongSwan Project, “strongSwan User Documentation,” docs.strongswan.org.
Perrig, A., et al., “The Noise Protocol Framework,” noiseprotocol.org.
Tailscale Inc., “How Tailscale Works,” tailscale.com/blog/how-tailscale-works.
Dowling, B., and Paterson, K.G., “A Cryptographic Analysis of the WireGuard Protocol,” ACNS, 2018.
Ossmann, M., “WireGuard vs IPSec Performance Benchmarks,” wireguard.com/performance.

上一篇: 网络入侵检测与防御：Suricata、签名与异常检测 下一篇: 网络隔离与微分段：VLAN、SDN 策略与零信任

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2025-07-27 · network

文章导航

目录