VPN客户端与服务器之间如何通信？

周五晚上十一点，林薇还在办公室里。窗外的城市已经沉入夜色，只有零星的写字楼格子还亮着灯。她面前的三台显示器上，左边是公司内网的代码仓库，中间是正在编译的日志，右边则是一个视频会议窗口——屏幕那头，远在德国慕尼黑的架构师托马斯正端着咖啡，准备和她讨论明天上线的微服务方案。

“你那边能访问 staging 环境吗？”托马斯问。

林薇敲下 curl 命令，请求发往公司内网的一台测试服务器。三秒后，终端返回了 JSON 数据。她点点头：“可以，延迟大概 180 毫秒。”

托马斯笑了笑：“那就好。我这边通过 VPN 连过去，感觉就像在本地机房一样。”

林薇突然意识到一件事：她此刻能访问公司内网，是因为她的笔记本上运行着一个 VPN 客户端；而托马斯在慕尼黑，同样通过 VPN 连回北京的总部。他们之间的视频会议走的是公网，但所有对内部系统的访问，都穿过了一条看不见的“隧道”。

这条隧道究竟是怎么建立的？客户端和服务器之间，到底在说什么悄悄话？她决定在等待编译的间隙，把这个问题彻底搞清楚。

第一幕：隧道口的握手——从“我要连”到“你是谁”

林薇打开终端，输入 sudo openvpn --config company.ovpn。屏幕上立刻滚动出一行行日志。她盯着这些日志，仿佛看到了客户端与服务器之间第一次对话的全过程。

1.1 客户端：我在这里，我要进来

VPN 客户端启动后的第一件事，不是直接发送数据，而是寻找服务器的入口。这个入口通常是一个公网 IP 地址和一个端口，比如 vpn.company.com:1194。但 IP 地址只是门牌号，真正要建立隧道，还需要一套“敲门暗号”。

林薇看到日志里出现了 TLS: Initial packet from [AF_INET]...。这意味着客户端正在发起一个 TLS 握手。TLS 是传输层安全协议，它负责在不可信的公网上，建立一个加密的通道。但 VPN 的 TLS 握手和 HTTPS 的 TLS 握手有一个关键区别：VPN 通常使用双向认证——不仅客户端要验证服务器是不是真的，服务器也要验证客户端是不是有资格进入。

1.2 服务器：先证明你是自己人

服务器收到客户端的握手请求后，会先出示自己的证书。这个证书通常由公司内部的 CA（证书颁发机构）签发，或者由受信任的公共 CA 签发。客户端会检查证书的有效期、域名匹配、签名链。如果一切正常，客户端才会继续。

但故事到这里才走了一半。服务器紧接着要求客户端也出示证书。林薇的笔记本上，有一个 client.crt 和 client.key 文件。这两个文件就是她的“工牌”。服务器验证这个证书确实由公司 CA 签发，并且没有过期、没有被吊销，才会继续。

如果客户端没有证书，或者证书不对，服务器会直接断开连接。这就是为什么很多公司 VPN 不能随便连——不是知道地址和密码就能进，你还得有那张“数字工牌”。

1.3 密钥交换：我们来说悄悄话

双向认证通过后，客户端和服务器会通过 TLS 握手协商出一组对称密钥。这组密钥将用于加密后续所有数据。TLS 握手本身使用非对称加密（如 RSA 或 ECDHE）来安全地交换这个对称密钥。一旦密钥交换完成，双方就拥有了一个只有彼此知道的“会话密钥”。

林薇在日志里看到 Control Channel: TLSv1.3, cipher TLS_AES_256_GCM_SHA384。这意味着控制通道已经建立，而且用的是 TLS 1.3 和 AES-256-GCM 加密。控制通道是 VPN 的“指挥中心”，所有关于隧道配置、路由、保活的信息都走这里。

第二幕：隧道的骨架——数据通道如何搭建

控制通道建立后，客户端和服务器之间已经可以安全地“说悄悄话”了。但真正的用户数据——比如林薇访问内网代码仓库的 HTTP 请求——还需要一条专门的数据通道。这条通道就是 VPN 隧道本身。

2.1 虚拟网卡：在操作系统里挖一条暗道

林薇的笔记本上，VPN 客户端创建了一个虚拟网卡，通常叫 tun0 或 tap0。这个网卡不是物理网卡，它没有插网线，但它对操作系统来说就像一个真实的网卡。当林薇访问 10.0.0.5 这个内网地址时，操作系统会根据路由表，把数据包发送到 tun0。

VPN 客户端从 tun0 读到这个数据包，然后按照 VPN 协议（比如 OpenVPN 或 WireGuard）把它封装起来。封装的意思是：把原始数据包当作“货物”，装进一个“集装箱”，集装箱外面写上服务器的公网 IP 和端口。

2.2 封装与加密：给数据包穿上两层衣服

封装的过程分两步。第一步是加密。客户端使用刚才 TLS 握手协商出的会话密钥，对原始数据包进行加密。加密后的数据是一串看起来毫无意义的字节。第二步是封装。客户端把这串加密数据放进一个新的 UDP 或 TCP 数据包里，目标地址是 VPN 服务器的公网 IP。

这个新数据包的结构大致是：

• 外层 IP 头：源地址是林薇的公网 IP，目标地址是 VPN 服务器公网 IP。
• 外层 UDP 头：源端口是随机端口，目标端口是 1194。
• VPN 协议头：包含一些控制信息，比如数据包长度、序列号。
• 加密后的原始数据包：这就是林薇真正想发送的 HTTP 请求。

2.3 服务器解封装：打开集装箱，取出货物

VPN 服务器收到这个 UDP 数据包后，先检查外层 IP 和端口，确认是发给自己的。然后它剥离外层 UDP 头，读取 VPN 协议头，找到加密数据。接着用同样的会话密钥解密，得到原始数据包。

服务器看到原始数据包的目标地址是 10.0.0.5，知道这是内网流量。于是它把数据包注入到内网网卡，让它在内网中继续传输。内网服务器收到请求后，生成响应，响应数据包再沿着相反路径回到 VPN 服务器，被加密、封装，发回给林薇的客户端。

2.4 路由与 NAT：让回包找到回家的路

这里有一个关键问题：内网服务器怎么知道把响应发给 VPN 服务器？答案在路由表。VPN 服务器通常会在内网中宣告自己可以到达 VPN 客户端的虚拟网段（比如 10.8.0.0/24）。内网路由器会把发往这个网段的数据包转发给 VPN 服务器。

VPN 服务器收到内网响应后，需要知道这个响应属于哪个客户端。它通过查看数据包的源地址（比如 10.0.0.5）和目标地址（比如 10.8.0.2），在连接跟踪表中找到对应的客户端会话。然后它加密、封装，发回给林薇。

如果 VPN 服务器同时连接了多个客户端，它还需要做 NAT（网络地址转换）或者维护一个虚拟 IP 映射表，确保每个客户端的虚拟 IP 不冲突，并且回包能准确送达。

第三幕：隧道里的生活——数据包如何排队、保活与重连

隧道建立后，林薇的代码仓库访问变得流畅。但公网并不稳定，数据包可能丢失、乱序、延迟。VPN 客户端和服务器之间，还需要一套机制来保证隧道的可靠性。

3.1 序列号与重放保护

每个通过隧道发送的数据包，都会带一个序列号。接收方按序列号重组数据，如果发现某个序列号重复，就丢弃，防止重放攻击。如果发现序列号跳跃，说明中间有丢包，但 VPN 通常不负责重传——那是上层协议（如 TCP）的事。VPN 只负责把数据包尽力送到对端。

3.2 保活机制：心跳不能停

公网路由器或防火墙可能会清理长时间没有流量的连接。为了保持隧道活跃，VPN 客户端和服务器会定期发送保活包。OpenVPN 默认每 10 秒发送一个 ping，如果 60 秒内没有收到对端响应，就认为隧道断了，开始重连。

林薇看到日志里每隔 10 秒出现一次 PUSH: Received control message: 'PING'，这就是保活机制在工作。

3.3 重连与密钥轮换

如果网络切换——比如林薇从办公室 Wi-Fi 切换到手机热点——VPN 客户端会检测到链路变化，重新发起 TLS 握手，建立新的控制通道和数据通道。这个过程通常只需要几秒钟，用户几乎无感。

另外，TLS 会话密钥有生命周期。OpenVPN 默认每 3600 秒（1 小时）重新协商一次密钥。即使密钥泄露，攻击者也只能解密有限时间内的数据。这就是前向安全性。

第四幕：不同协议，不同性格——OpenVPN、WireGuard 与 IPsec

林薇公司用的是 OpenVPN，但她听说 WireGuard 更快、更简单。她决定对比一下几种主流 VPN 协议的通信方式。

4.1 OpenVPN：灵活但复杂

OpenVPN 使用 TLS 握手，支持 TCP 和 UDP，可以跑在 443 端口伪装成 HTTPS。它的控制通道和数据通道分离，配置选项极多。但代码量大，性能不如 WireGuard。

4.2 WireGuard：极简主义

WireGuard 没有复杂的握手协议。它使用 Noise 协议框架，每个客户端和服务器预共享一个公钥。通信时，双方直接用公钥加密数据。没有 TLS 证书链，没有协商过程。它的代码只有几千行，性能极高，但配置相对“硬编码”——每个对等体都要预先知道对方的公钥。

4.3 IPsec：企业级老将

IPsec 通常在内核层实现，支持 IKE（Internet Key Exchange）协议。它可以在网络层加密所有 IP 流量，不仅限于 VPN 客户端。但配置复杂，NAT 穿透有时会出问题。

林薇在日志里看到 OpenVPN 的 Control Channel 和 Data Channel 分别使用不同的密钥，这让她理解了为什么 OpenVPN 被称为“SSL VPN”——它把 TLS 的握手和加密能力，扩展到了网络层。

第五幕：当隧道遇到防火墙——NAT 穿透与端口伪装

林薇想起有一次在酒店，VPN 怎么都连不上。后来她换了 TCP 443 端口才成功。这背后是 NAT 穿透和防火墙规避的问题。

5.1 NAT 穿透：UDP 打洞

很多客户端位于 NAT 后面，没有公网 IP。VPN 客户端发送的 UDP 包，源地址会被 NAT 修改。服务器收到包后，看到的是 NAT 设备的公网 IP 和端口。服务器回复时，必须发回这个公网 IP 和端口，NAT 设备才能正确转发给客户端。

如果 NAT 设备对 UDP 超时时间很短，隧道可能频繁断开。OpenVPN 的保活机制就是为此设计的。

5.2 端口伪装：假装成 HTTPS

有些防火墙只允许 443 端口出站。OpenVPN 可以配置为 TCP 443，并且把流量伪装成 TLS。防火墙看到的是 TLS 握手，以为是 HTTPS 访问，就放行了。但实际上，里面跑的是 VPN 数据。

WireGuard 默认使用 UDP，如果遇到只允许 TCP 的网络，就需要额外工具（如 udp2raw）来伪装。

第六幕：回到那个深夜——隧道彼端的信任

凌晨一点，编译终于通过。林薇和托马斯确认了第二天的上线计划，关掉了视频会议。但她的 VPN 连接还开着，终端里偶尔滚动着保活日志。

她突然想到：这条隧道之所以能工作，不仅仅是因为加密和封装。它背后是一整套信任体系——证书、密钥、路由、NAT、防火墙规则。客户端和服务器之间的每一次通信，都是这些机制精密配合的结果。

她关掉 VPN 客户端，日志最后一行显示 SIGTERM received, process exiting。隧道消失了，但那些数据包走过的路径，那些握手、加密、封装、解封装的瞬间，已经在她脑海里留下了一幅清晰的图景。

下一次当有人问她“VPN 到底怎么通信”时，她不会只说“加密隧道”四个字。她会从那个深夜的 curl 命令讲起，讲到 TLS 握手、虚拟网卡、序列号、保活包，讲到公网上的每一跳，和内网里的每一次转发。因为真正的理解，从来都藏在细节里。