10.1 IPsec 中的协议号与端口号
1. 先建立一个坐标：数字写在哪一层
IPsec 是"协议号与端口号"这个话题最好的入门案例，因为它同时用到了这两个概念：
- 数据加密部分（AH / ESP）是网络层协议，在 IP 头里用 Protocol（协议号） 标识。
- 密钥协商部分（IKE）跑在 传输层之上，在 UDP 头里用 端口号 标识。
先看它们在报文里的位置，理解"谁标识谁"：
+----------------+------------------------------------------+
| IP Header | Protocol = 50 (ESP) 或 51 (AH) | <- 协议号在这里
+----------------+------------------------------------------+
| ESP Header | SPI + Sequence Number |
+----------------+------------------------------------------+
| Payload | 加密后的原始数据（TCP/UDP/ICMP...） |
+----------------+------------------------------------------+
| ESP Trailer | Padding + Pad Length + Next Header | <- 原协议号藏在这里
+----------------+------------------------------------------+
| ESP Auth Data | ICV（完整性校验值） |
+----------------+------------------------------------------+而 IKE 的报文长这样：
+----------------+------------------------------------------+
| IP Header | Protocol = 17 (UDP) |
+----------------+------------------------------------------+
| UDP Header | Src Port / Dst Port = 500 或 4500 | <- 端口号在这里
+----------------+------------------------------------------+
| IKE Payload | 协商参数、密钥材料、身份信息... |
+----------------+------------------------------------------+记住这一句，后面全部内容都是它的推论：
协议号回答"IP 头后面装的是谁"，端口号回答"这个包该交给哪个进程"。
2. IPsec 协议号与端口号总览
这是本文最核心的一张表，建议对照实验逐行验证：
| 组件 | 全称 | IP 协议号 | 端口号 | 作用 | 是否加密 |
|---|---|---|---|---|---|
| AH | Authentication Header | 51 | 无 | 认证 + 完整性保护（含 IP 头） | ❌ 不加密 |
| ESP | Encapsulating Security Payload | 50 | 无 | 加密 + 认证 + 完整性保护 | ✅ 加密 |
| IKE / ISAKMP | Internet Key Exchange | 17（UDP） | UDP 500 | 主模式/野蛮模式/快速模式协商，建立 SA | 协商过程本身不加密 |
| NAT-T | NAT Traversal | 17（UDP） | UDP 4500 | 把 ESP 包进 UDP，穿透 NAT | ✅ 内部仍是 ESP 密文 |
| NAT-T 探测 | NAT Discovery | 17（UDP） | UDP 4500 | 源/目的为 0.0.0.0:4500 的 NAT 检测与保活 | 否 |
2.1 三个最容易踩的认知陷阱
ESP 和 AH 没有端口号。 它们不是 TCP/UDP 之上的应用，而是与 TCP、UDP 平级的网络层协议。看到"ESP 端口"这种说法，直接判定为错误说法。
协议号 50 和 51 是十进制，不是十六进制。 抓包里 IP 头的 Protocol 字段是 1 字节，十六进制显示为
0x32（50）和0x33（51）。 注意别和 GRE 的 47（0x2F）、OSPF 的 89（0x59）混淆。IPsec 用了两个不同端口号，不是重复。 500 用于协商，4500 用于数据穿透 NAT 后的封装。两者分工不同，缺一不可。
3. 一次完整的 IPsec 会话，数字是怎么流动的
以"总部 AR1 ↔ 分部 AR3，两端都位于 NAT 设备之后"为例：
AR1 (总部) NAT 1 NAT 2 AR3 (分部)
| | | |
| 第一阶段：IKE 协商（UDP 500） |
|---- IKE_SA_INIT (UDP 500) ------------------------>|
|<--- IKE_SA_INIT 响应 (UDP 500) --------------------|
|---- IKE_AUTH (UDP 500) ------------------------>|
|<--- IKE_AUTH 响应 (UDP 500) -----------------------|
| | | |
| 第二阶段：NAT 探测（UDP 4500） |
|---- NAT-D 探测 (UDP 4500, 源 0.0.0.0:4500) ------->|
|<--- NAT-D 响应 (UDP 4500) -------------------------|
| | | |
| 第三阶段：ESP 加密数据传输 |
|---- ESP in UDP 4500 (外层协议号 17，内含 50) ------>|
|<--- ESP in UDP 4500 (外层协议号 17，内含 50) -------|
| | | |三个阶段对应三组数字：
| 阶段 | 用途 | 外层协议号 | 外层端口 |
|---|---|---|---|
| 第一阶段（IKE SA） | 协商加密算法、交换密钥、身份认证 | 17 (UDP) | 500 |
| NAT 探测 | 检测链路中是否存在 NAT | 17 (UDP) | 4500 |
| 第二阶段（IPsec SA）+ 数据传输 | 建立数据加密通道并传输业务 | 17 (UDP) → 内层 50 | 4500 |
4. NAT-T：为什么需要 UDP 4500
4.1 问题的本质：ESP 没有端口号
NAT 设备要做的核心工作是 PAT（端口地址转换）：把多个内网地址复用一个公网地址，靠端口号区分不同的会话，并据此维护转换表。
于是问题来了：
- IKE (UDP 500)：有端口号，NAT 能正常建表转发，这一步通常没问题。
- ESP (协议号 50)：根本没有端口号，NAT 无法为它建立"地址 + 端口"的转换表项，只能按"地址对地址"处理。
后果有两个：
- 多台内网设备同时建 IPsec 隧道时，NAT 无法区分它们，转换表项互相覆盖。
- NAT 会话老化后，外网回来的 ESP 包找不到对应表项，被直接丢弃。
4.2 解决方案：给 ESP 套一个 UDP 外壳
NAT-T（NAT Traversal，RFC 3947 / 3948） 的做法非常朴素——既然 NAT 只认端口号，那就给 ESP 加一个 UDP 头：
正常 ESP： NAT-T 封装后：
+----------------+ +----------------+
| IP (Proto=50) | | IP (Proto=17) | <- UDP
+----------------+ +----------------+
| ESP Header | | UDP 4500 | <- 有端口号了，NAT 可建表
+----------------+ +----------------+
| Encrypted Data | | ESP (Proto=50) | <- 原样保留，密文不变
+----------------+ +----------------+
| Encrypted Data |
+----------------+关键点：
- 外层是 UDP 4500，NAT 设备"看得懂"，能正常做 PAT。
- 内层还是完整的 ESP（协议号 50），加密内容一字未改，安全性不受影响。
- 这套封装由隧道两端自动协商启用（检测到 NAT 后才用），不需要手工配置。
⚠️ 常见误区
"NAT-T 会降低安全性"——不会。UDP 头只是传输外壳，ESP 的加密与认证完整保留，中间设备依然看不到任何明文。
4.3 为什么用 4500 这个数字
IANA 将 UDP 4500 同时分配给 IPsec NAT-T 与 IKEv2，原因很实际：
- IKEv2 允许直接使用 4500 发起协商（RFC 7296），省去"先 500 后 4500"的切换；
- NAT-T 的保活报文（Keepalive） 就发往
对端:4500，用于刷新 NAT 会话表——所以设备上display ike sa常能看到"NAT-T keepalive"的计数。
5. ESP 的 Next Header 字段：被藏起来的协议号
ESP 的尾部有一个 Next Header（下一个头） 字段，它记录的是原始载荷的协议号。这是排错时极有价值的信息：
| 内层原始载荷 | ESP Next Header 值 |
|---|---|
| TCP | 6 |
| UDP | 17 |
| ICMP | 1 |
| GRE | 47 |
| IPv6 | 41 |
所以观察一个 ESP 包，可以读出两层协议号：
IP Header: Protocol = 50 (ESP) <- 外层：加密通道
ESP Trailer: Next Header = 6 (TCP) <- 内层：被加密的是 TCP 流量实战意义：当 IPsec 隧道建立成功（SA 为 Up）但业务不通时，看 ESP 的内层 Next Header 就能快速判断——加密的到底是不是你期望的那类流量。如果 ACL 匹配的是 TCP 80，而 Next Header 显示为 1（ICMP），说明感兴趣流（interesting traffic）配置错了。
6. 配置实例：华为设备上的 IPsec
6.1 实验拓扑
[PC1]---[AR1]=========[Internet]=========[AR3]---[PC2]
192.168.1.0/24 | | 192.168.2.0/24
12.1.1.1 23.1.1.36.2 第一步：ACL 定义感兴趣流
ACL 的作用是告诉设备哪些流量需要被 IPsec 加密。注意这里的写法仍然使用协议号与端口号：
# 用协议号和端口号精确描述感兴趣流：只加密 ICMP 和 TCP 80
[AR1] acl number 3000
[AR1-acl-adv-3000] rule 5 permit icmp source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255
[AR1-acl-adv-3000] rule 10 permit tcp source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255 destination-port eq 80
[AR1-acl-adv-3000] quit
💡 关键点
ACL 里的 icmp、tcp、destination-port eq 80 就是本文主题的直接应用。ACL 写不对，IPsec 隧道能起来但业务不通——这是最常见的排错场景。
6.3 第二步：配置 IKE（第一阶段）
[AR1] ike proposal 10 [AR1-ike-proposal-10] encryption-algorithm aes-256 [AR1-ike-proposal-10] authentication-algorithm sha2-256 [AR1-ike-proposal-10] dh group14 [AR1-ike-proposal-10] quit[AR1] ike peer AR3 v2 [AR1-ike-peer-AR3] pre-shared-key cipher Huawei@123 [AR1-ike-peer-AR3] remote-address 23.1.1.3 [AR1-ike-peer-AR3] ike-proposal 10 [AR1-ike-peer-AR3] quit
6.4 第三步：配置 IPsec（第二阶段）
[AR1] ipsec proposal tran1 [AR1-ipsec-proposal-tran1] esp authentication-algorithm sha2-256 [AR1-ipsec-proposal-tran1] esp encryption-algorithm aes-256 [AR1-ipsec-proposal-tran1] quit[AR1] ipsec policy map1 10 isakmp [AR1-ipsec-policy-isakmp-map1-10] security acl 3000 [AR1-ipsec-policy-isakmp-map1-10] ike-peer AR3 [AR1-ipsec-policy-isakmp-map1-10] proposal tran1 [AR1-ipsec-policy-isakmp-map1-10] quit
6.5 第四步：应用到出接口
[AR1] interface GigabitEthernet 0/0/0 [AR1-GigabitEthernet0/0/0] ip address 12.1.1.1 24 [AR1-GigabitEthernet0/0/0] ipsec policy map1 [AR1-GigabitEthernet0/0/0] quit
6.6 IPsec 与 GRE 的协议号叠加
如果采用 GRE over IPsec（先用 GRE 封装，再用 IPsec 加密整个 GRE 包），协议号会出现两层嵌套：
+----------------+ IP Proto = 50 (ESP)
+----------------+ ESP Header
+----------------+ IP Proto = 47 (GRE) <- 内层：被加密的 GRE 包
+----------------+ GRE Header
+----------------+ IP（原始私网包）
+----------------+ 真实业务数据这正是 VPN 与 GRE 中提到的方案——加密后 GRE 的协议号 47 被"藏"在 ESP 里的原因。
7. 验证与排错
7.1 常用验证命令
# 查看第一阶段（IKE SA）状态，可看到协商使用的 UDP 500/4500 [AR1] display ike sa# 查看第二阶段（IPsec SA），确认协议号 50/51 与 SPI [AR1] display ipsec sa
# 查看会话与 SA 对应关系，确认业务流量确实命中了隧道 [AR1] display ipsec sa brief
7.2 抓包过滤器写法对照
Wireshark 的过滤器直接使用协议号与端口号，是验证本文内容的最直接手段：
| 想看什么 | Wireshark 过滤器 |
|---|---|
| 所有 ESP 包（协议号 50） | ip.proto == 50 |
| 所有 AH 包（协议号 51） | ip.proto == 51 |
| IKE 协商过程 | udp.port == 500 |
| NAT-T 封装后的 ESP | udp.port == 4500 |
| 隧道内承载的 TCP 流量（需密钥解密） | esp && ip.proto == 50 解密后 tcp |
在设备侧，华为 VRP 的 ACL 同样可以直接匹配协议号：
# 方式一：用关键字匹配（推荐，可读性好） [AR1] acl number 3001 [AR1-acl-adv-3001] rule 5 permit esp# 方式二：用数字协议号匹配（等价写法） [AR1] acl number 3002 [AR1-acl-adv-3002] rule 5 permit 50
7.3 排错决策表
| 现象 | 最可能的原因 | 验证方法 |
|---|---|---|
display ike sa 无任何表项 | UDP 500 被中间设备/ACL 拦截 | 抓包看是否有 UDP 500 交互 |
| IKE 第一阶段成功，第二阶段失败 | IPsec proposal 两端不一致；感兴趣流不匹配 | 核对两端 proposal 与 ACL |
| 隧道 Up 但 ping 不通 | ACL 未匹配实际流量（协议号/端口号写错） | 检查 ESP 的 Next Header；display ipsec sa 看加解密计数 |
| 隧道建立后间歇性中断 | NAT 会话老化，保活未生效 | 抓包确认是否有 UDP 4500 保活报文 |
| 有 NAT 环境下隧道无法建立 | NAT-T 未启用或被拒绝 | 确认 UDP 4500 可达 |
| 抓包只看到 ESP，看不到内层 | 正常现象（已加密） | 导入密钥解密，或看 ESP 的 Next Header 字段 |
8. 拓展：与之相邻的常见协议号
把 IPsec 放进整张"协议号地图"里，记忆会更牢固：
| 协议 | 协议号 | 端口号 | 备注 |
|---|---|---|---|
| ICMP | 1 | — | Ping / Tracert |
| IGMP | 2 | — | 组播成员管理 |
| TCP | 6 | — | 端口号在 TCP 头中 |
| UDP | 17 | — | 端口号在 UDP 头中 |
| GRE | 47 | — | 通用封装，不加密 |
| ESP | 50 | — | IPsec 加密 |
| AH | 51 | — | IPsec 认证 |
| ICMPv6 | 58 | — | IPv6 的 NDP 依赖它 |
| OSPF | 89 | — | 直接封装在 IP 之上 |
| VRRP | 112 | — | 直接封装在 IP 之上 |
| L2TP | 115 | UDP 1701 | 配合 IPsec 常用于远程接入 |
| ISAKMP / IKE | 17 (UDP) | 500 / 4500 | 密钥协商与 NAT-T |
9. 总结
三句话记住 IPsec 的数字：
- 加密用 50，认证用 51——它们是网络层协议，没有端口号。
- 协商用 UDP 500，IKE 建立和管理 SA。
- 穿 NAT 用 UDP 4500，把 ESP 装进 UDP 外壳，数据照样是密文。
再往上一层总结，本章真正要建立的认知是：
协议号定位"上层是什么协议"，端口号定位"是哪个应用"。 NAT、ACL、防火墙策略、抓包过滤器——所有"放行/加密/统计"动作，最终都落在这两个数字上。
10. 思考题
- 为什么 ESP 过不了 PAT，而 IKE 可以？
- 如果两端设备之间是普通路由器（无 NAT），还需要 UDP 4500 吗？为什么？
- 某 IPsec 隧道
display ipsec sa显示 Up，但 TCP 80 业务不通、ICMP 可以通。最可能的原因是什么？ ip.proto == 50 && udp.port == 4500这个过滤器能同时命中包吗？为什么？
