VPN Wiki
搜索 K

Appearance

VPN 工作原理详解：从数据加密到隧道传输全流程 ​

核心结论（直接答案）
VPN 的工作原理可以概括为三步闭环：首先，客户端与服务端通过非对称加密算法（如 ECDH）完成身份鉴权并协商出高强度对称会话密钥；其次，操作系统内核的虚拟网络适配器（TUN 网卡）拦截系统出站流量，将原始 IP 数据报文全量加密并作为有效载荷重新封装进新的外部网络数据包中；最后，外部加密数据包穿过公共互联网到达 VPN 节点解密还原，由出口服务器代理发起真实的互联网访问。

理解了 VPN 是什么之后，很多对计算机网络感兴趣的技术爱好者都会好奇：操作系统是如何在不改变物理网卡硬件的情况下，无感截获所有应用程序的网络请求并神不知鬼不觉地将其打包送往地球另一端的？本文将从密码学原理、数据包封装结构到操作系统内核网络栈，带您逐层拆解 VPN 的真实运转机制。

一、隧道技术（Tunneling）与数据包封装机制 ​

VPN 的核心魔法在于隧道技术（Tunneling）。所谓隧道，本质上就是**“数据包套数据包”（Packet Encapsulation）**的套娃过程。

1. 原始数据包的结构 ​

在常规网络通信中，一个发往 104.21.44.201 的 HTTP 请求数据包具有标准的结构：

  • 外部 IP 首部：源 IP（192.168.1.108），目的 IP（104.21.44.201）；
  • 传输层首部：源端口（52100），目的端口（80 或 443）；
  • 有效载荷（Payload）：实际的 HTTP 请求数据。

2. VPN 封装后的双层结构 ​

当数据进入 VPN 隧道时，原本完整的 IP 数据包被整块读取，并进行了对称密码学加密。接着，VPN 客户端在加密数据外部重新贴上一层“新信封”：

+------------------------------------------------------------------------+
| 新的外层 IP 首部 (源: 本地网卡真实IP, 目的: 远端 VPN 服务器 IP)         |
+------------------------------------------------------------------------+
| 外层传输层首部 (UDP 端口 51820 / TCP 端口 443 等)                        |
+------------------------------------------------------------------------+
| VPN 协议首部 (含报文类型、随机数 Nonce、防重放序号 Counter)             |
+------------------------------------------------------------------------+
| 🔒 加密载荷 (包含: 原始内部 IP 首部 + 原始 TCP/UDP 首部 + 原始请求数据)    |
+------------------------------------------------------------------------+
| 校验鉴权标签 (如 Poly1305 / GCM 认证标签，确保报文完整性无篡改)          |
+------------------------------------------------------------------------+

对于途径的路由器与电信基站而言，它们只能读取到最外层的“新外层 IP 首部”，只知道该设备正在向 VPN 服务器发送 UDP 数据，无法得知内层究竟封装了访问哪个网站的请求。

二、加密全流程：从非对称密钥协商到对称流加密 ​

VPN 的安全性依赖于现代密码学的“组合拳”：非对称加密负责前期握手，对称加密负责后续高速数据传输。

mermaid
sequenceDiagram
    autonumber
    participant Client as 本地客户端
    participant Server as VPN 节点服务器

    Note over Client,Server: 阶段 1：握手认证与密钥协商 (基于非对称算法)
    Client->>Server: 发起连接握手请求 (携带临时公钥 Ephemeral PubKey)
    Server-->>Client: 响应握手包 (携带服务端公钥 + 数字证书签名)
    Note over Client,Server: 双方各自基于 ECDH (Curve25519) 计算出完全一致的对称共享会话密钥 (Session Key)

    Note over Client,Server: 阶段 2：数据高速加密传输 (基于对称算法)
    Client->>Server: 发送数据包 (使用 Session Key + ChaCha20-Poly1305 高速加密)
    Server-->>Client: 返回解密后的网站回包 (同样使用 Session Key 极速对称加密)
  1. 第一阶段：身份核验与 ECDH 密钥交换
    客户端和服务端各自生成一对临时的公私钥对。通过椭圆曲线 Diffie-Hellman（ECDH，如 Curve25519）数学算法，通信双方可以在完全不向公网透露私钥的情况下，各自独立计算出完全相同的共享秘密（Shared Secret）。即便第三方窃听者捕获了通信链路上的全部握手数据包，在数学上也无法在有效时间内反向推导出会话密钥。
  2. 第二阶段：对称会话加密（Symmetric Encryption）
    握手完毕后，后续海量的视频流、网页与文件传输全部切换为对称加密（如 AES-256-GCM 或 ChaCha20-Poly1305）。对称加密的计算速度极快，现代 CPU（如 Intel/AMD 的 AES-NI 指令集或 ARM 架构硬件加速）能够在保持千兆速率的同时仅消耗极低的处理器资源。

三、一手实操：虚拟网卡（TUN/TAP）与路由表底层接管 ​

要让所有软件的数据流量都自动走 VPN，操作系统依赖两项核心机制：虚拟网络适配器驱动与内核路由表重定向。

1. TUN 与 TAP 驱动的本质差异 ​

  • TUN 驱动（Network Tunnel）：模拟三层网络设备（Point-to-Point IP 层）。它不处理 MAC 地址与以太网广播帧，直接接收纯 IP 数据报文，开销更小，是现代绝大多数 VPN（如 WireGuard、OpenVPN 默认模式）的首选。
  • TAP 驱动（Network Tap）：模拟二层以太网适配器。它具有虚拟 MAC 地址，可以像真实网卡一样处理 ARP 请求与局域网广播。

2. 真实系统实测：开启 VPN 前后的 Windows 路由表变更 ​

我们在 Windows 11 环境下，使用管理员身份打开 PowerShell，执行 route print 观察路由表在开启虚拟网卡前后的实际物理变动：

未开启 VPN 时的默认路由表： ​

powershell
PS C:\Windows\system32> route print -4
===========================================================================
活动路由:
网络目标        网络掩码          网关            接口          跃点数
0.0.0.0          0.0.0.0       192.168.1.1     192.168.1.108      25
127.0.0.0        255.0.0.0     在链路上         127.0.0.1         331
192.168.1.0    255.255.255.0   在链路上         192.168.1.108     281
===========================================================================

分析：全局默认网关（0.0.0.0/0）直接指向本地路由器 192.168.1.1，接口为真实无线网卡 192.168.1.108。

启用 VPN TUN 虚拟网卡后的路由表变化： ​

powershell
PS C:\Windows\system32> route print -4
===========================================================================
活动路由:
网络目标        网络掩码          网关            接口          跃点数
0.0.0.0        128.0.0.0     在链路上         10.66.66.2          5
128.0.0.0      128.0.0.0     在链路上         10.66.66.2          5
198.51.100.25  255.255.255.255 192.168.1.1     192.168.1.108      25
0.0.0.0          0.0.0.0       192.168.1.1     192.168.1.108      35
===========================================================================

底层技术精髓解析：

  1. 巧妙的 /1 路由掩码覆盖法：VPN 驱动并未强行删除原来的默认路由（0.0.0.0/0），而是添加了两条细化的子网路由：0.0.0.0/1（覆盖 0.0.0.0 ~ 127.255.255.255）和 128.0.0.0/1（覆盖 128.0.0.0 ~ 255.255.255.255），跃点数（Metric）更小（仅为 5）。
  2. 最长前缀匹配原则（LPM）：根据网络路由基本原则，掩码更长的路由优先级更高。因此全系统所有出站流量均被优先导入虚拟网卡接口 10.66.66.2。
  3. 保留物理链路通信：为 VPN 服务器自身 IP（198.51.100.25/32）单独保留指向真实网关 192.168.1.1 的主机路由，避免“VPN 封装的数据包在寻找 VPN 服务器时自身陷入无限死循环”。

四、经典协议架构时序对比：OpenVPN vs WireGuard ​

协议对比维度OpenVPN (经典老牌)WireGuard (新一代现代协议)
内核态 vs 用户态用户态运行（存在频繁上下文切换开销）深度集成于 Linux 内核态运行，极致高效
代码行数约 70,000 ~ 100,000 行（代码库庞大）仅约 4,000 行（极简架构，易于形式化安全审计）
连接建立耗时典型握手耗时约 1.5 ~ 3.0 秒握手耗时小于 100 毫秒，几乎“瞬时连接”
漫游能力 (Roaming)手机由 Wi-Fi 切换到 5G 时通常断流需重连基于公钥无状态路由（Cryptokey Routing），IP 切换无缝漫游
混淆拓展性支持通过 TCP 443 伪装为标准 HTTPS 流量UDP 报文头部特征较为明显，在特定网络中易遭识别阻断

五、常见问题解答 (FAQ) ​

Q1：为什么开启 VPN 后，有些国内网站打不开了或提示验证码？ ​

这是由于开启全局 VPN 后，国内网站接收到的是海外机房的出口 IP，触发了网站的风控策略（例如防刷单或版权限制）。解决方案是在客户端中开启分流功能（Split Tunneling），配置规则使常用国内域名（如 *.cn）直接绕行本地网络直连。

Q2：数据包双层封装会导致 MTU 问题吗？ ​

是的，必须进行 MTU 调优。 传统以太网最大传输单元（MTU）为 1500 字节。由于 VPN 封装增加了额外的外层 IP 头、UDP 头与加密鉴权标签，如果内层数据包过大，就会导致报文在公网被分片（Fragmentation）甚至静默丢弃。优质的客户端会自动将虚拟网卡 MTU 设置为 1420 或 1280，以避免吞吐量骤降。

Q3：Kill Switch（断网急停）在底层是如何实现的？ ​

当 VPN 隧道意外中断时，操作系统原有的默认路由可能会瞬间恢复，导致流量在无加密保护下裸连泄露。Kill Switch 的底层实现是通过系统防火墙（如 Windows Filtering Platform 或 Linux iptables）注入强制规则：阻断除发往 VPN 服务器 IP 以外的所有出站流量，直到隧道重新建立成功。

六、延伸阅读与相关链接 ​

🛡️ 独立声明独立第三方声明与商业合规披露
展开查阅▾