VPN 工作原理：隧道、封装与握手到底做了什么

第一步：系统里多了一块网卡

安装 VPN 客户端后，操作系统里会出现一个虚拟网络接口 —— Linux 下叫 tun0，Windows 上是一个虚拟适配器。它没有对应的物理硬件，但在系统看来和真网卡一样可以收发数据包。

TUN 设备处理的是 IP 层数据包，TAP 设备处理的是以太网帧。个人用的 VPN 几乎都用 TUN，因为只需要转发 IP 流量。

第二步：路由表被改写

有了虚拟网卡还不够，还要告诉系统「哪些流量走它」。客户端连接成功后会往路由表里插入条目，常见的做法是加两条 0.0.0.0/1 和 128.0.0.0/1 的路由 —— 它们合起来覆盖全部 IPv4 地址，且优先级高于默认路由，同时又不会把原来的默认网关整个覆盖掉。

如果只想让部分流量走隧道（分流 / split tunneling），客户端就只插入特定网段的路由。

第三步：封装

这是「隧道」这个比喻的技术实体。原始数据包并没有被修改，而是被整个当作数据，装进一个新的数据包里：

[新 IP 头 | 协议头 | 加密后的( 原 IP 头 | TCP/UDP 头 | 应用数据 ) ]
      ↑ 目的地是 VPN 服务器            ↑ 中间设备只看到密文

不同协议的外层不一样：IPsec 用 ESP 头（RFC 4303），WireGuard 用自己定义的 UDP 报文格式，OpenVPN 把加密后的内容放进 UDP 或 TCP 里。

外层包头一定会占用空间。以太网默认 MTU 是 1500 字节，封装后可用于原始载荷的空间就少了几十字节。如果不调整，超长的包要么被分片，要么被丢弃 —— 表现就是「小网页能开、大文件卡死」。

第四步：握手与密钥

在传数据之前，双方必须先商量出一把只有彼此知道的钥匙，而且要在一条不可信的线路上完成。

大致流程是：

1. 身份验证 —— 服务器出示证书或公钥，客户端验证它是不是自己要连的那台。
2. 密钥交换 —— 用 Diffie-Hellman 一类的算法，双方各自算出同一个共享秘密，而窃听者拿不到。现代实现普遍用椭圆曲线版本（ECDHE / Curve25519）。
3. 派生会话密钥 —— 从共享秘密派生出用于加密和校验的对称密钥。
4. 切换到对称加密 —— 之后所有数据用 AES-GCM 或 ChaCha20-Poly1305 加密，因为对称算法比非对称快几个数量级。

优秀实现还会定期更换会话密钥（rekey）。这样即便某把密钥日后被攻破，也无法解开之前录下的流量 —— 这就是前向保密。详见 VPN 加密原理。

第五步：服务器侧的转发

VPN 服务器收到包后解密、还原出原始 IP 包，然后做一次 NAT：把源地址换成自己的公网 IP，记录映射关系，再发往目标网站。回包按相反顺序处理。

正因为这一步，目标网站看到的永远是服务器 IP。也正因为这一步，服务器本身处于能看到全部明文流量的位置。

现实中的两个麻烦

NAT 穿透。 家庭路由器和运营商 NAT 会改写端口，长时间无流量的映射会被回收，表现为连接「假死」。协议层的应对是定期发保活包，或者用 MOBIKE（RFC 4555）这类机制在地址变化后重新绑定。

协议特征。 封装后的流量虽然内容不可读，但报文长度、握手模式、端口号构成了可识别的特征。想要不被识别，就需要额外的伪装层，见 混淆与伪装协议。