现代 VPN 不是“加密后转发”这一个动作，而是一条由操作系统路由、虚拟网卡、身份认证、密钥建立、数据封装、DNS 与故障恢复共同组成的链路。只讨论某个协议用了什么算法，会遗漏决定稳定性和安全性的半个系统。

第一步：客户端先建立控制连接

商业或企业 VPN 通常先访问控制平面，而不是立即建立数据隧道。控制平面完成：

  • 账号或设备身份认证；
  • 查询用户权限、套餐或企业策略；
  • 根据延迟、负载和地区选择接入节点；
  • 下发节点地址、公钥、内部 IP、DNS 和分流规则；
  • 吊销丢失设备或过期凭据。

WireGuard 本身只认识公钥，不定义“用户名”“节点列表”或“设备管理”。OpenVPN 和 IKEv2 虽有更多认证机制，也不负责完整产品逻辑。因此一个 VPN 产品的安全性不能只根据隧道协议判断：控制 API 泄露令牌、错误签发配置或节点调度失灵，同样会破坏整体安全。

工程上常把控制平面与数据平面分开。控制请求量不大，但逻辑复杂，需要数据库和权限检查；数据平面逻辑应尽量少，却要持续处理高吞吐、低延迟的包。

第二步：虚拟网卡接管待保护流量

VPN 客户端会创建 TUN 或 TAP 虚拟网络接口：

  • TUN 处理三层 IP 包，适合绝大多数远程接入和消费级 VPN；
  • TAP 处理二层以太网帧，可承载广播和非 IP 协议，但额外开销更大，也更难跨移动系统部署。

虚拟网卡看起来像普通网卡，但没有物理线缆。操作系统把数据包“发送”到它，实际是交给 VPN 程序读取。VPN 程序加密封装后，再通过真实 Wi-Fi、以太网或蜂窝网卡发送。

解密方向正好相反：客户端从真实网卡收到加密外层包，验证并解密出原始 IP 包，再写回 TUN；操作系统随后把它交给对应应用。

这解释了为什么 VPN 客户端通常需要系统级网络权限，也解释了为什么浏览器代理不能完全代替 VPN：代理只接管支持代理的应用请求，TUN 则能接管操作系统路由到它的任意 IP 流量。

第三步：路由决定哪些包进入隧道

创建虚拟网卡并不意味着所有流量自动进入 VPN。真正的决策者是路由表和策略规则。

全隧道

全隧道模式把 IPv4 的 0.0.0.0/0 和 IPv6 的 ::/0 指向虚拟网卡。实践中还需为 VPN 服务器自身保留一条经物理网关直达的路由，否则“连接 VPN 所需的包”也会被送进尚未可用的隧道，形成路由递归。

分流

分流可以按多个层级实现：

  • 网段分流：公司私网或特定 IP 段走隧道；
  • 域名分流：DNS 解析后动态维护目标 IP 集合；
  • 应用分流：按进程、用户或系统网络扩展选择路径；
  • 策略路由：结合源地址、接口、端口或数据包标记查不同路由表。

域名分流并不天然精确。一个域名可能使用 CDN 并快速改变 IP，同一 IP 也可能承载多个域名。成熟客户端要把 DNS 结果、缓存过期与连接跟踪结合起来，而不是把一份静态 IP 列表永久写进路由表。

第四步：握手把长期身份变成短期会话密钥

直接用长期密钥加密全部流量会放大泄露影响。现代 VPN 一般用长期凭据认证身份，再通过临时 Diffie-Hellman 类交换产生短期会话密钥。

以 WireGuard 为例，其握手基于 NoiseIK 模式：发起方预先知道响应方静态公钥，双方结合静态密钥与临时密钥完成相互认证，并派生用于数据传输的会话密钥。临时密钥定期更新，使攻击者即使日后获得长期私钥，也不能直接解密此前捕获的全部会话，这就是前向保密。

IKEv2/IPsec 的结构更可协商：IKEv2 负责认证、Diffie-Hellman 交换和建立 Security Association，ESP 使用协商出的密钥保护数据。OpenVPN 则通常借助 TLS 握手建立控制通道和会话密钥。

协议族握手/控制数据封装典型特征
IKEv2/IPsecIKEv2ESP标准化程度高、算法与策略选择多
OpenVPNTLS 控制通道自身数据通道，可承载 TUN/TAP用户态、跨平台、配置灵活
WireGuardNoiseIK 派生握手固定 UDP 消息格式精简、固定密码套件、公钥与路由绑定

“握手成功”只说明双方建立了安全上下文，不代表之后每个包都做昂贵的公钥运算。数据平面主要使用 AEAD 对称加密；公钥密码通常只出现在握手和重新协商阶段。

第五步：封装必须处理 MTU

原始 IP 包进入隧道后会增加外层 IP、UDP/TCP 和 VPN 协议头。假设物理路径 MTU 是 1500 字节，隧道内仍发送 1500 字节包，外层封装后就会超过路径上限。

结果可能是分片，也可能在中间设备丢弃后形成“能连接但部分网页打不开”的路径 MTU 黑洞。常见处理方式包括：

  • 把虚拟网卡 MTU 调低，为外层头部预留空间；
  • 对 TCP SYN 的 MSS 进行钳制；
  • 正确允许 ICMP Packet Too Big / Fragmentation Needed；
  • 协议层支持分片或避免产生过大的控制消息。

MTU 不是越小越稳定。过小会增加包数量、每包头部比例和 CPU 开销。合理值应根据 IPv4/IPv6、外层传输和协议头长度计算，再通过实际路径验证。

第六步：NAT 穿越与连接保活

多数客户端位于家庭路由器或运营商 CGNAT 后，没有公网地址。客户端主动发送 UDP 后，NAT 会暂时建立“内网地址:端口 ↔ 公网地址:端口”的映射，服务器才能沿该映射回包。

映射长时间无流量会过期，因此 VPN 可能发送低频保活包。频率过高会耗电和浪费无线资源，过低又可能在待机后失去映射。移动系统还会限制后台网络活动，这也是“锁屏后 VPN 断开”不一定是服务器故障的原因。

网络切换时，外层源地址会改变。IKEv2 可借助 MOBIKE 更新路径；WireGuard 不把外层 IP 固定写入身份，收到通过认证的新端点包后可以更新对端地址。这种“身份与物理地址解耦”是移动 VPN 的关键能力。

第七步：DNS 必须与路由策略一致

VPN 已连接但 DNS 请求仍发给本地运营商，称为 DNS 泄漏。风险不只在隐私：本地 DNS 可能返回污染或与 VPN 出口地区不一致的结果，导致连接失败。

完整方案需同时处理：

  1. 向系统下发可信 DNS；
  2. 确保到该 DNS 的路由进入隧道；
  3. 处理浏览器或应用自带的 DoH/DoT；
  4. 在分流时让不同域名使用匹配其出口的解析器；
  5. 同时覆盖 IPv4 和 IPv6，避免只接管一半流量。

因此 DNS 是 VPN 数据路径的一部分，而不是附属设置。尤其在按域名分流时，“先由谁解析、解析结果保存多久、后续连接走哪条路”必须作为一个整体设计。

第八步：Kill Switch 不是一个开关

Kill Switch 的目标是在隧道不可用时阻止受保护流量回落到普通网络。可靠实现通常依赖系统防火墙或网络过滤框架：

  • 默认禁止物理接口上的普通出站流量；
  • 只允许连接 VPN 控制服务和数据节点所需的例外；
  • 允许隧道接口发送；
  • 在断线、重连、系统休眠和网络切换时保持规则原子更新。

如果实现只是“断线后删除默认路由”，在规则切换的时间窗内仍可能泄漏。不同操作系统的防火墙、VPN API 和权限模型不同，所以同一品牌各平台的 Kill Switch 可靠性可能并不相同。

现代 VPN 的性能瓶颈在哪里

在有硬件加速或现代移动 CPU 的设备上，对称加密未必是最大瓶颈。实际性能还受以下因素影响：

  • 用户态与内核态之间的数据复制；
  • 单流还是多队列并行；
  • 节点到目标站点的实际路由；
  • UDP 被限速或丢弃后的回退策略；
  • MTU 不匹配导致的分片与重传；
  • 服务器 NAT、连接跟踪和限速实现；
  • TCP 拥塞控制是否适合高延迟、丢包链路。

所以“协议理论吞吐高”不能直接推导“某服务速度快”。协议决定上限和行为，节点容量与网络路径决定大多数日常体验。

用分层模型排查问题

遇到故障时，可以按链路逐层判断：

  1. 控制层：能否登录、获取配置和节点？
  2. 握手层：双方是否完成认证和密钥建立？
  3. 路由层：目标流量是否真的进入虚拟网卡？
  4. 数据层：加密包是否双向可达，有无 NAT/UDP 阻断？
  5. 名称层：DNS 是否从正确路径解析？
  6. 路径层：是否存在 MTU 黑洞、丢包或拥塞？
  7. 应用层：目标服务是否按出口 IP、账号地区或设备指纹限制访问？

这个模型比反复“换节点、重装客户端”更有效。想了解这些组件如何发展到今天，可阅读VPN 技术史；面向受限网络的额外对抗机制，则见VPN 抗封锁技术演进。

主要技术资料