常见隧道与加密协议浅析
本文梳理企业网络中常见的隧道与加密协议的工作原理、报文结构与适用场景。
一、隧道与加密
在展开具体协议之前，先明确两个经常被混用的概念。
隧道（Tunnel） 的核心功能是封装与穿越——把一种网络协议的数据打包塞进另一种协议里传输，让原本无法直接通信的两端建立逻辑上的连通。隧道本身不一定提供加密（比如 GRE 就是纯明文的隧道协议）。
加密协议 的核心功能是机密性与完整性保护——确保数据在传输过程中不被窃听和篡改。加密协议不一定构建隧道（比如 TLS 只是在已有的 TCP 连接上加了一层安全壳，并没有改变数据的路由路径）。
有些协议兼具两种能力：IPSec 的隧道模式既构建了隧道（套了一层新 IP 头），又提供了加密。有些方案则是将两者组合使用：GRE 负责修隧道，IPSec 负责加密。
1.1 “N 层隧道”的命名由来
“二层”和”三层”直接借用 OSI 七层模型的层级编号。所谓”N 层隧道”，指的是隧道内部封装的数据属于 OSI 第 N 层：
- 二层隧道：内部封装的是完整的以太网帧（数据链路层，第 2 层）
- 三层隧道：内部封装的是 IP 数据包（网络层，第 3 层）
理论上确实可以存在更高层的”隧道”——比如 SSH 端口转发可以看作应用层（第 7 层）的隧道，SOCKS5 代理工作在会话层（第 5 层）。但在网络工程的日常沟通中，“隧道”这个术语几乎专指二层和三层，因为它们解决的是最基础的网络互通问题：让两个物理上隔离的网络在逻辑上”连”起来。更高层的方案通常被称为”代理”或”端口转发”，而不叫隧道。
1.2 二层隧道
二层隧道在内部封装完整的以太网帧（含源/目的 MAC 地址）。打通后，两端设备逻辑上位于同一个子网内，所有二层帧都可以透传——包括广播包、组播包以及任意自定义的二层协议数据。
- 典型协议：VXLAN、L2TP、OpenVPN 的 TAP 模式
TAP 是操作系统提供的二层虚拟网卡接口。OpenVPN 运行在 TAP 模式下时以二层帧为传输单位，从而实现二层隧道。TAP 本身不是协议，而是操作系统内核的网络设备抽象，多种 VPN 软件都可以使用它。
- 适用场景：跨园区组建统一局域网、局域网联机游戏、依赖广播发现机制的应用（如 ARP、DHCP、局域网打印机发现）
1.3 三层隧道
三层隧道封装的是 IP 数据包。两端网络仍然是独立子网，需要通过路由表决定哪些流量走隧道，不转发广播和组播（除非配合额外协议）。
- 典型协议：IPSec、GRE、WireGuard、OpenVPN 的 TUN 模式
TUN 是操作系统提供的三层虚拟网卡接口，只处理 IP 包，不涉及 MAC 地址。与 TAP 的关系类比：TAP 模拟网线插在交换机上（二层），TUN 模拟直连路由器接口（三层）。
- 适用场景：企业分支机构互联、远程接入 VPN、跨云网络互通
小结：二层隧道把异地网络”缝合”为同一个局域网（二层帧全部透传），三层隧道把异地网络变成可通过路由互访的两个独立网络（只传 IP 路由包，更高效）。
二、基于 IPSec 的隧道方案
2.1 IPSec
IPSec（Internet Protocol Security）是对 IP 协议的安全扩展，工作在 OSI 第三层（网络层）。它处理的最小单位是 IP 数据包，核心组件是 ESP（封装安全载荷），提供加密和数据完整性校验。
根据封装方式不同，IPSec 有两种工作模式。
传输模式（Transport Mode）
ESP 只加密 IP 数据包的有效载荷（TCP/UDP 头部 + 应用数据），保留原始 IP 头部不变。
flowchart LR
ip1["原始 IP 头部<br/>A -> B"] --> esp1["ESP 头部"] --> payload1["加密的 TCP/UDP 头部<br/>+ 应用数据"] --> tail1["ESP 尾部<br/>+ 校验"]
隧道模式（Tunnel Mode）
ESP 将整个原始 IP 数据包（含原始 IP 头部）全部加密，然后在最外面加上一个全新的 IP 头部。
flowchart LR
outer["全新外层 IP 头部<br/>X -> Y"] --> esp2["ESP 头部"] --> inner["加密的原始 IP 头部<br/>A -> B + TCP 头 + 数据"] --> tail2["ESP 尾部<br/>+ 校验"]
两种模式的差异与选择
| 维度 | 传输模式 | 隧道模式 |
|---|---|---|
| 加密范围 | 仅加密 IP 载荷，保留原始 IP 头 | 加密整个原始 IP 包，套新 IP 头 |
| 加解密执行者 | 通信的终端主机自身 | 两端的网关/路由器 |
| 是否隐藏内部拓扑 | 否，原始 IP 暴露 | 是，内网 IP 完全不可见 |
| 是否支持私有 IP 跨公网 | 否，私有 IP 无法公网路由 | 是，外层使用公网 IP |
| 报文开销 | 较小（无额外 IP 头） | 较大（多一个 20B 的外层 IP 头） |
| 典型场景 | 机房内主机间加密、配合 GRE 使用 | 企业 VPN、SD-WAN 站点互联 |
传输模式有一个硬性约束：执行 IPSec 加密的设备 IP 必须与原始数据包的源/目的 IP 一致。直白地说，它只能加密”自己发出的流量”，无法代理转发其他设备的流量。因此在站点互联（Site-to-Site）场景中，路由器代理转发内网流量时，不能单独使用传输模式——但它在与 GRE 组合时能发挥重要作用。
隧道模式是目前企业 VPN 和 SD-WAN 中最常用的模式。
2.2 纯 IPSec 的局限
纯 IPSec 不支持组播（Multicast）和广播，只能传输单播流量。这意味着两台路由器之间无法直接运行 OSPF 等依赖组播的动态路由协议——OSPF 需要组播来发现邻居和交换链路状态信息。在网段众多的企业网络中，如果只能手写静态路由，运维成本极高。
GRE（Generic Routing Encapsulation，通用路由封装）弥补了这一缺陷。它虽然没有加密能力，但能够封装 IP 组播包和广播包——OSPF 使用的 224.0.0.5 组播地址等都依赖这一能力。需要注意的是，这里说的组播/广播仍然是 IP 层面（三层） 的，不是以太网帧层面（二层）的广播。GRE 在标准配置下封装的是 IP 数据包，因此 GRE over IPSec 仍然是三层隧道。
补充：组播和广播也分二层与三层
组播和广播不是某一层的专属概念，而是在二层和三层各有对应形式：
类型 二层（以太网帧级别） 三层（IP 包级别） 广播 目的 MAC 为 FF:FF:FF:FF:FF:FF，到达同一 LAN 内所有设备目的 IP 为 255.255.255.255或子网广播地址（如192.168.1.255）组播 特殊组播 MAC（如 01:00:5E:...），用于 STP 等链路层协议目的 IP 在 224.0.0.0/4范围，如 OSPF 的224.0.0.5二层隧道（如 VXLAN、L2TP）透传的是以太网帧，所以二层广播（ARP 请求、DHCP Discover 等）可以直接穿过隧道。三层隧道中的 GRE 则是封装 IP 包，能传输 IP 组播包（让路由器跑 OSPF），但不会透传以太网帧级别的广播。纯 IPSec 连 IP 组播包都不支持——它只能处理点到点的单播 IP 包。
2.3 GRE over IPSec
以下是一个典型的 GRE over IPSec 示意，两端分支机构通过专线连接：
%%{init: {'flowchart': {'curve': 'linear'}}}%%
flowchart TB
subgraph topo[" "]
direction LR
subgraph siteA["分支 A 内网"]
pcA["PC-A<br/>10.0.1.5"]
rA["路由器 A<br/>172.16.0.1"]
pcA --> rA
end
rA ==>|"加密隧道"| wan(["专线 / 公网"])
wan ==>|"加密隧道"| rB
subgraph siteB["分支 B 内网"]
rB["路由器 B<br/>172.16.0.2"]
sB["Server-B<br/>10.0.2.5"]
rB --> sB
end
end
subgraph encap["路由器 A 封装 → 路由器 B 解封装"]
direction TB
s1["① GRE 封装：外层 IP 头 172.16.0.1→172.16.0.2 + GRE 头 + 原始 IP 包"]
s2["② IPSec 传输模式加密：保留外层 IP 头，ESP 加密 GRE 头及载荷"]
s3["③ 对端解封装：IPSec 解密 → 剥离 GRE → 恢复原始 IP 包并转发"]
s1 --> s2 --> s3
end
topo ~~~ encap
关键在于第 ② 步：GRE 封装后，最外层 IP 头的源/目地址变成了两台路由器自己的接口 IP（172.16.0.1 → 172.16.0.2），恰好满足了 IPSec 传输模式的约束——”加解密方就是报文的源/目”。因此 IPSec 可以使用传输模式，不再额外添加一层 IP 头部。
以 AES-256-GCM 加密算法为例的报文开销对比：
| 方案 | 附加开销（估算） | 说明 |
|---|---|---|
| 纯 IPSec 隧道模式 | ~58 ~ 76 字节 | 外层 IP 头(20B) + ESP 头(~8B) + IV(~16B) + ESP 尾部/填充 + 校验 |
| GRE over IPSec（传输模式） | ~62 ~ 80 字节 | 与上者相比，外层 IP 头同为 20B（由 GRE 产生），但多了 4B 的 GRE 头 |
两者开销非常接近。GRE over IPSec 仅多出约 4 字节，换来的是对 IP 组播的支持——可以运行 OSPF 等依赖组播的动态路由协议。BGP 虽然使用 TCP 单播（不依赖组播），但 GRE 隧道同样为 BGP 提供了灵活的逻辑互联拓扑。
2.4 L2TP over IPSec
L2TP over IPSec 与 GRE over IPSec 的底层逻辑一致——都是”无加密的隧道协议 + IPSec 加密保护”的组合，且都配合 IPSec 传输模式使用。
它们之间有两个核心差异：
差异一：封装的数据层级不同。 GRE 封装的是三层 IP 数据包（包括 IP 组播包）——隧道内外仍然是两个独立的子网，通过路由互访。虽然 GRE 能传输 IP 组播，但这仍然是三层行为，并不意味着它是二层隧道。L2TP 则封装的是二层 PPP 帧——隧道打通后，远端设备通过 PPP 协议获取内网 IP 地址，逻辑上如同直接插入了公司交换机的网口。这就是为什么 GRE over IPSec 被归类为三层隧道，而 L2TP over IPSec 被归类为二层隧道。
补充：GRE 协议实际上也支持封装以太网帧（称为 EoGRE，Ethernet over GRE），此时它就变成了二层隧道。但在标准的 GRE over IPSec 企业组网方案中，GRE 封装的是 IP 数据包，用于跑动态路由协议，属于三层隧道的用法。
差异二：设计场景不同。 GRE 面向站点互联（Site-to-Site），解决的是路由器之间跑动态路由的需求；L2TP 面向远程拨号接入（Client-to-Site），解决的是个人终端远程获取内网 IP 和账号认证的需求。L2TP 基于 UDP 传输，NAT 穿越能力强，加上 Windows/macOS/iOS/Android 均原生支持，无需额外安装客户端，因此在远程接入场景中使用广泛。
| 维度 | GRE over IPSec | L2TP over IPSec |
|---|---|---|
| 内部封装层级 | 三层（IP 数据包） | 二层（PPP 帧） |
| 场景 | 站点互联（Site-to-Site） | 远程拨号接入（Client-to-Site） |
| 核心能力 | 支持组播、运行动态路由协议 | 账号认证、IP 分配、二层漫游 |
| 额外协议头 | GRE 头（4B） | PPP 头(4B) + L2TP 头(~8B) + UDP 头(8B) |
| 报文开销 | 比纯 IPSec 多 ~4 字节 | 比纯 IPSec 多 ~20+ 字节 |
关于 GRE 协议的可用性：GRE 是 IETF 公开标准（RFC 2784），不是运营商专用协议，也不需要任何授权即可使用。但 GRE 在 IP 层面使用的是协议号 47——它既不是 TCP（协议号 6）也不是 UDP（协议号 17），而是一种独立的 IP 协议类型。部分小型运营商或家用 NAT 网关只放行 TCP 和 UDP 流量，会直接丢弃协议号 47 的数据包，导致 GRE 隧道无法建立。相比之下，L2TP 运行在 UDP 端口 1701 之上，能够正常穿越几乎所有 NAT 和防火墙，因此在网络环境受限时成为替代方案。
三、TLS 与 mTLS
3.1 与隧道协议的区别
前面讲的 IPSec、GRE 都是工作在 IP 层的网络层协议，它们要解决的核心问题是”让两个网络在逻辑上连通”，因此被称为隧道。
TLS 解决的是不同的问题：它工作在 TCP 连接之上，为已经能正常通信的两端提供加密保护和身份验证。TLS 不会改变数据的路由路径，也不会在 IP 层增加新的封装头——它只是在 TCP 管道内部加了一层安全壳。因此通常称其为”加密协议”或”安全协议”，而不是隧道。
不过在实际使用中，这条界线有时会模糊。比如在零信任架构中，mTLS 连接本身会承载被封装的内网流量，此时它事实上也充当了一种”应用层隧道”的角色。
3.2 TCP、TLS 与 HTTP
理解 TLS/mTLS 之前，需要先厘清三者的层级关系：
- TCP（传输层）：负责建立可靠的端到端字节流管道。TCP 本身不提供加密，数据以明文传输。
- TLS（安全层）：直接架在 TCP 之上的加密协议，对 TCP 管道中的数据进行加密保护。TLS 是协议中立的——它不关心上层跑的是 HTTP、gRPC 还是 MySQL，在它眼里都是透明的字节流。
- HTTP（应用层）：定义具体的业务语义（URL、Header、Body 等）。
三者的组合关系：
flowchart TB
http["HTTP（应用层）<br/>URL / Header / Body"] --> tls["TLS（安全层）<br/>加密 + 身份验证"] --> tcp["TCP（传输层）<br/>可靠传输"] --> ip["IP（网络层）<br/>路由寻址"]
TLS 不仅服务于 HTTP——任何基于 TCP 的应用层协议都可以使用 TLS 保护：gRPC over TLS（微服务 API 调用）、MySQL over TLS（数据库连接加密）、MQTT over TLS（物联网数据传输）等。HTTPS 只是 TLS 最常见的一种应用形式。
3.3 加密流程
一次 TLS 加密通信分三个阶段：
- TCP 三次握手：建立可靠的传输管道（此时仍为明文通道）。
- TLS 握手：服务器出示数字证书证明自身身份，双方通过非对称加密算法（RSA/ECC）协商出对称会话密钥（Session Key）。TLS 1.3 将握手优化为 1-RTT（首次连接）甚至 0-RTT（恢复连接），比 TLS 1.2 的 2-RTT 显著减少延迟。
- 加密数据传输：后续所有 TCP 有效载荷使用协商好的对称密钥加密。
3.4 报文格式
TLS 数据包封装在 TCP Payload 中，外层的 TLS Record Header 固定为 5 字节：
+----------------------------------------------------------+
| Content Type (1B) | Version (2B) | Payload Length (2B) |
+----------------------------------------------------------+
| TLS Payload (Fragment) |
+----------------------------------------------------------+
Content Type：标识 Payload 类型——0x16(Handshake 握手)、0x17(Application Data 应用数据)、0x15(Alert 告警)Version：协议版本，TLS 1.2 为0x0303（TLS 1.3 为兼容旧设备仍写0x0303，真实版本在扩展字段协商）Length：后续 Payload 的字节长度（最大 16KB）
握手完成后，Content Type: 0x17 的 Payload 是被 AEAD 算法（如 AES-256-GCM 或 ChaCha20-Poly1305）加密的密文及 MAC 认证标签。
3.5 mTLS
普通 TLS 是单向认证——只有客户端验证服务器的身份（通过服务器出示的证书）。任何人都可以与服务器建立 TLS 连接，服务器不在乎对方是谁。
mTLS（Mutual TLS，双向 TLS）在此基础上增加了反向验证：服务器也强制要求客户端出示证书。只有双方都验证了对方的合法性，TLS 连接才能建立。
两者在握手完成后的加密数据包结构完全一致，差异仅体现在握手阶段（以下以 TLS 1.2 握手流程为例，TLS 1.3 的流程有所简化但 mTLS 的核心机制不变）：
sequenceDiagram
participant C as 客户端
participant S as 服务器
C->>S: 1. ClientHello
S-->>C: 2. ServerHello
S-->>C: 3. Certificate（服务器证书）
S-->>C: 4. CertificateRequest（请出示客户端证书）
Note over C,S: 第 4 步为 mTLS 特有
S-->>C: 5. ServerHelloDone
C->>S: 6. Certificate（客户端证书）
C->>S: 7. CertificateVerify（私钥签名证明）
Note over C,S: 第 6、7 步为 mTLS 特有
C->>S: 8. ClientKeyExchange
C->>S: 9. Finished
S-->>C: 10. Finished
Note over C,S: 握手完成后进入加密数据传输
mTLS 握手中服务器多发了一个 CertificateRequest（Handshake Type 0x0D），客户端多回了两个报文：
| 报文 | Handshake Type | 作用 |
|---|---|---|
| CertificateRequest | 0x0D (13) |
服务器要求客户端出示证书，声明支持的签名算法和可信 CA 列表 |
| Certificate | 0x0B (11) |
客户端发送完整的 X.509 证书链（叶子证书 + 中间 CA） |
| CertificateVerify | 0x0F (15) |
客户端使用私钥对前序握手报文的摘要签名，证明真正拥有该证书 |
3.6 mTLS 适用场景
mTLS 的核心价值是在网络连接建立阶段就完成设备/服务身份认证，无需等到应用层的登录环节：
- 零信任网关准入：只有安装了企业 CA 签发证书的终端设备才能与网关建立连接，未授权设备在 TLS 握手阶段即被拒绝。
- 微服务间通信：服务 A 调用服务 B 的 gRPC 接口时，双方通过 mTLS 互验证书，防止未授权服务伪造调用。
- 数据库安全连接：业务服务器连接 MySQL 时，数据库要求客户端出示证书，拒绝未经认证的连接。
- 物联网设备认证（MQTT over mTLS）：云平台只接受持有合法证书的 IoT 设备上报数据。
四、其他常见协议
除了上述企业级的经典协议外，还有一些在不同场景中广泛使用的协议值得了解。
4.1 WireGuard
WireGuard 是一个现代的三层加密隧道协议，于 2020 年正式合入 Linux 内核。它可以看作 IPSec 的轻量替代品。
| 维度 | IPSec | WireGuard |
|---|---|---|
| 代码量 | 数十万行 | 约 4000 行 |
| 加密算法 | 可协商（灵活但配置复杂） | 固定使用 ChaCha20 + Curve25519（零配置） |
| 协议层级 | IP 层（协议号 50/ESP） | UDP 封装（易穿越 NAT） |
| 连接模型 | 需要复杂的 IKE 协商 | 基于公钥的静态配对，1-RTT 握手 |
| 性能 | 较高（硬件加速成熟） | 极高（内核态，代码路径短） |
WireGuard 的设计哲学是极简：固定加密算法避免了协商开销和配置错误，UDP 封装让它在 NAT 环境下比 IPSec 更容易穿透。
4.2 Tailscale / Headscale
Tailscale 是基于 WireGuard 构建的零配置 Mesh VPN 服务。它的核心贡献不在协议层面（底层就是 WireGuard），而在控制面：
- 自动 NAT 穿透：集成了 STUN/DERP 打洞技术，设备之间即使在复杂 NAT 后面也能直连。
- 节点自动发现：通过中央协调服务器（Coordination Server）自动分发公钥和路由信息，不需要手动配置。
- 身份集成：使用 SSO（如 Google、GitHub 账号）做身份认证，替代传统 VPN 的预共享密钥。
Headscale 是 Tailscale 控制面的开源替代实现，允许自建协调服务器，适合不希望将节点信息托管给第三方的场景。
4.3 Cloudflare Zero Trust
Cloudflare 的零信任方案由两个组件构成：
- Cloudflare WARP（客户端侧）：安装在用户终端的 Agent，底层使用 WireGuard 协议（Cloudflare 称之为 BoringTun，是 WireGuard 的用户态 Rust 实现）。它将用户流量加密后发往最近的 Cloudflare 边缘节点。
- Cloudflare Tunnel（服务端侧）：安装在企业内网服务器上的
cloudflared守护进程，使用 HTTP/2 或 QUIC 协议主动向 Cloudflare 边缘建立出站连接。这种”反向连接”的设计使得内网服务器无需暴露任何入站端口。
两者通过 Cloudflare 的全球边缘网络中转，配合身份验证（OIDC/SAML）实现零信任访问控制。
4.4 代理协议
这类协议和前面讨论的隧道协议有本质区别。它们工作在应用层（第 7 层）或会话层（第 5 层），核心目标不是”连通两个网络”，而是伪装流量特征以规避深度包检测（DPI）。
| 协议 | 工作层级 | 传输方式 | 核心特点 |
|---|---|---|---|
| Shadowsocks | 应用层 | TCP/UDP | 将数据加密为无特征的随机字节流 |
| Trojan | 应用层 | TLS (TCP 443) | 伪装为标准 HTTPS 流量，与正常网页流量几乎不可区分 |
| VLESS | 应用层 | 可选 WebSocket/gRPC/TLS | VMess 的精简版，降低协议头开销 |
| Hysteria 2 | 应用层 | QUIC (UDP) | 基于 QUIC 协议，利用 UDP 多路复用和前向纠错优化高延迟、高丢包网络的性能 |
这些协议通常运行在本地代理客户端（如 mihomo/Clash、sing-box 等）与远端服务器之间。本地客户端通过 TUN 虚拟网卡或系统代理（SOCKS5/HTTP）接管终端流量，加密后发往服务器，服务器解密后代为访问目标站点。
与 IPSec/WireGuard 等三层隧道协议的关键区别在于：后者的加密特征容易被 DPI 识别（大量加密 UDP 包或 ESP 协议包），而代理协议专门设计了流量伪装机制——Trojan 把流量混入普通 HTTPS 中，Hysteria 伪装为正常的 HTTP/3 通信，Shadowsocks 则追求无任何可识别特征的随机化。
五、适用场景总结
| 协议 | 工作层级 | 核心能力 | 典型场景 |
|---|---|---|---|
| IPSec 隧道模式 | L3 | IP 包级加密 + 拓扑隐藏 | 企业 VPN、SD-WAN 站点互联 |
| IPSec 传输模式 | L3 | IP 载荷加密（省一层 IP 头） | 主机间直连加密、配合 GRE/L2TP 使用 |
| GRE | L3 | 通用封装（支持 IP 组播/广播） | 作为 IPSec 前置封装，支持动态路由 |
| GRE over IPSec | L3 | 路由互通 + 加密 | 多网段企业网、需要跑 OSPF 的场景 |
| L2TP over IPSec | L2 | 远程拨号 + 账号认证 + IP 分配 | 员工远程接入企业内网 |
| WireGuard | L3 | 轻量加密隧道 | 现代 Mesh VPN、轻量组网 |
| TLS | L5-L6 | 传输加密 + 服务器身份验证 | HTTPS 网站、数据库连接加密 |
| mTLS | L5-L6 | 双向证书认证 + 传输加密 | 零信任设备准入、微服务间通信、IoT |
| Tailscale | L3 (WireGuard) | 零配置 Mesh + NAT 穿透 + SSO 认证 | 个人设备互联、小型团队组网 |
| Shadowsocks/Trojan/VLESS | L7 | 流量加密 + 特征伪装 | 规避 DPI 审查的代理场景 |