第211篇：IPsec VPN 隧道模式与传输模式

关键词：IPsec VPN、隧道模式、传输模式、Tunnel Mode、Transport Mode、ESP封装、IPsec封装方式

一、引言

在第210篇中，我们系统学习了 IPsec VPN 的工作原理、IKE 密钥协商流程以及安全联盟（SA）的建立机制。IPsec 通过 IKE 完成密钥协商后，实际数据的加密和传输由 ESP 或 AH 协议承担。而 ESP/AH 对原始 IP 报文的封装方式，直接决定了 IPsec 的安全粒度、协议开销和适用场景。

IPsec 定义了两种封装模式：隧道模式（Tunnel Mode）和传输模式（Transport Mode）。理解两者的区别与适用场景，是正确部署 IPsec VPN 的前提。

二、核心概念

2.1 隧道模式（Tunnel Mode）

隧道模式是 IPsec VPN 最常用的封装方式。其核心思想是对整个原始 IP 报文进行封装和保护：IPsec 头部插入在原始 IP 头部之前，再添加一个新的外层 IP 头部。外层 IP 头部的源和目的地址为 IPsec 网关的接口地址，内层 IP 头部保留原始通信双方的地址。

2.2 传输模式（Transport Mode）

传输模式仅对 IP 报文的数据载荷部分（TCP/UDP 等上层协议数据）进行保护。ESP/AH 头部插入在原始 IP 头部之后、上层协议头部之前。外层 IP 头部与原始 IP 头部相同，源和目的地址仍为原始通信双方。

2.3 两种模式对比

三、技术细节

3.1 隧道模式数据流

3.2 传输模式数据流

3.3 隧道模式的 NAT 穿越问题

隧道模式下，ESP 头部的协议号为 50。当 IPsec 流量经过 NAT 设备时，NAT 需要修改 IP 头部中的源地址，但 ESP 头部中的认证数据（Authentication Data）包含了原始 IP 地址的校验和。NAT 修改 IP 地址后，认证数据校验失败，导致报文被丢弃。

IKE 协议定义了 NAT-T（NAT-Traversal）机制解决此问题： - 检测 NAT 存在：IKE 协商时比较 COOKI 长度判断 NAT 存在 - 封装转换：将 ESP 报文（协议号 50）封装到 UDP 4500 端口中传输 - NAT 设备正常修改 UDP 报文的 IP 地址，不影响 ESP 完整性校验

3.4 传输模式的典型应用场景

四、实战配置/案例分析

4.1 华为 AR 路由器：隧道模式配置

# ========== 隧道模式（默认，适用于站点到站点）==========
system-view
sysname Branch-Router

# 配置接口IP
interface GigabitEthernet 0/0/0
 ip address 10.10.1.1 255.255.255.0
 quit

interface GigabitEthernet 0/0/1
 ip address 203.0.113.1 255.255.255.252
 quit

# 到总部内网的路由
ip route-static 10.20.0.0 255.255.0.0 203.0.113.2

# IKE Peer配置
ike peer HQ
  address 203.0.113.2
  authentication-mode pre-shared-key
  pre-shared-key cipher Huawei@VPN2024
  ikev2 enable
quit

# IPsec Proposal - 指定隧道模式
ipsec proposal ipsec-tunnel
  encapsulation-mode tunnel
  auth-algorithm sha256
  encrypt-algorithm aes-256-gcm
  dh-group group14
quit

# ACL定义保护流量
acl 3000
 rule 5 permit ip source 10.10.1.0 0.0.0.255 destination 10.20.0.0 0.0.255.255
quit

# IPsec策略
ipsec policy ipsec-vpn 10 isakmp
 security-acquire-method ike
 proposal ipsec-tunnel
 conn acl 3000
 peer HQ
quit

# 应用到出接口
interface GigabitEthernet 0/0/1
 ipsec policy ipsec-vpn
 quit

4.2 华为 AR 路由器：传输模式配置

# ========== 传输模式（主机到主机加密）==========
ipsec proposal ipsec-transport
 encapsulation-mode transport
 auth-algorithm sha256
 encrypt-algorithm aes-256-gcm
quit

# ACL定义保护流量（两端设备IP）
acl 3000
 rule 5 permit tcp source 203.0.113.1 0 destination 198.51.100.1 0
quit

ipsec policy ipsec-transport 10 isakmp
 security-acquire-method ike
 proposal ipsec-transport
 conn acl 3000
 peer RemotePeer
quit

interface GigabitEthernet 0/0/1
 ipsec policy ipsec-transport
 quit

4.3 故障排查案例：隧道模式误配为传输模式

故障现象：分支机构与总部之间 IPsec VPN 已建立 SA，但业务流量无法互通。分支路由器 ping 总部内网地址超时，但 ping 对端公网 IP 正常。

排查步骤：

1. 检查 SA 状态

display ipsec sa

输出显示 SA 状态为 ACTIVE，但流量计数为 0，说明 SA 建立成功但没有业务流量匹配。

1. 检查 IPsec Proposal 封装模式

display ipsec proposal

发现本地配置为 encapsulation-mode transport（传输模式），而对端配置为 encapsulation-mode tunnel（隧道模式）。

1. 根因分析 传输模式下，外层 IP 地址为通信主机地址（10.10.1.100 → 10.20.1.200），但这些地址在对端网关的路由中不可达。而隧道模式下，外层 IP 为网关地址（203.0.113.1 → 198.51.100.1），对端网关可以正常路由。两端封装模式不一致，虽然 SA 协商成功（IKE 层不校验封装模式），但实际数据传输时地址解析失败。

2. 解决方案

# 分支侧修改为隧道模式
ipsec proposal ipsec-tunnel
 encapsulation-mode tunnel
quit

# 强制重新建立 SA
reset ipsec sa

修改后，display ipsec sa 显示流量计数持续增长，分支与总部互通恢复正常。

五、总结

思考

1. 隧道模式在外层 IP 头部使用网关地址，如果两个站点之间存在多条路由路径，外层 IP 路由和 IPsec SA 绑定之间会产生什么问题？
2. 传输模式下原始 IP 头部不在 ESP 保护范围内，这会带来哪些安全风险？在什么场景下可以接受这种风险？
3. 为什么大多数 IPsec VPN 厂商将隧道模式设为默认，而不是开销更小的传输模式？

下篇预告：第212篇：IPsec VPN 野蛮模式与主模式