GRE over IPSec - 技术栈

不管是野蛮模式还是主模式，IPSec都有个通病：不支持组播。

产生背景

一、整体时代大背景

早期企业跨地域分支互联，主流方案是运营商物理专线（SDH、MPLS VPN、裸光纤）：

优势：链路专属、传输安全、网络稳定；
致命短板：租用成本极高、部署周期长、地域限制大，小微企业、临时分支、跨省 / 跨区域大量分支组网完全不划算。

随着互联网全网普及，公网带宽成本大幅下降，企业开始提出新诉求：利用廉价的互联网公网，替代昂贵物理专线实现分支互联 。但互联网是不可信公网 ：报文明文传输，存在数据窃听、篡改、伪造、中间人攻击风险；同时企业内网还有动态路由、广播、组播等基础网络需求。业界先后诞生了 GRE 隧道 和 IPSec 安全加密 两类技术，但二者单独使用都无法同时满足「网络功能性」和「传输安全性」，GRE over IPSec 正是为了解决这一矛盾应运而生。

二、单独部署：纯 IPSec 的核心缺陷（无法满足网络功能需求）

先回顾：我们之前学的 IPSec（IKEv1+ESP/AH）是三层安全加密协议，核心定位是「给 IP 报文做加密、认证、防重放」，而非通用隧道技术。在分支互联场景下，纯 IPSec 存在多个硬伤：

1. 原生不支持广播、组播报文（最核心痛点）

企业内网组网几乎都依赖两类报文：

动态路由协议：OSPF、RIP、PIM 等，默认依靠组播报文邻居发现、传递路由条目；
局域网基础业务：DHCP 广播、ARP 广播、VRRP 组播、视频会议 / IP 语音组播流。

而 IPSec 仅对 单播 IP 报文 提供加密转发，直接丢弃广播 / 组播报文。这就导致一个结果：

只用纯 IPSec 打通两端网段后，无法跑动态路由协议，只能配置静态路由；分支一多、网段复杂，静态路由配置量爆炸，运维难度剧增。

2. 依赖 ACL 兴趣流引流，复杂组网配置繁琐

传统策略型 IPSec，依靠ACL 规则定义 "哪些流量需要加密"。

若企业存在多网段互访、分支网状互联，ACL 规则会成倍增加；
没有独立的虚拟隧道接口，工程师无法像操作普通物理接口一样做路由策略、QoS、策略路由，组网灵活性差。

3. 协议支持范围窄

IPSec 只针对IPv4/IPv6 单播 IP 报文生效，不兼容老旧非 IP 协议（部分传统工业网络、老旧运维系统仍在使用），适配场景受限。

补充：哪怕使用 IPSec 隧道模式，也只是对 IP 报文二次封装，依然没有解决组播 / 广播的转发问题。

三、单独部署：纯 GRE 隧道的核心缺陷（无安全能力）

GRE（通用路由封装）是标准的三层隧道协议 ，设计初衷就是：在公网 IP 网络中，封装各类内网报文穿越广域网。它完美弥补了 IPSec 的功能短板：

✅ 支持 单播、广播、组播 ，可以正常跑 OSPF/RIP 等动态路由；

✅ 拥有独立的 Tunnel 虚拟接口，运维逻辑和物理接口完全一致，支持路由、QoS、ACL、策略路由，组网灵活；

✅ 兼容 IP 及非 IP 协议，通用性极强。

但 GRE 有一个致命短板：

GRE 本身不具备任何加密、认证、防篡改、防重放能力。

所有被 GRE 封装的内网报文，在互联网公网中全程明文传输：

业务数据、员工账号、财务数据、设备配置、路由信息都可能被黑客抓包窃听；
报文可被恶意篡改、伪造，引发网络故障或数据泄露。

因此：

纯 GRE 仅能用于运营商内网、企业专属可信链路；
绝对不能直接跑在开放的互联网公网，安全风险完全不可接受。

四、核心诉求碰撞：催生 GRE over IPSec 融合方案

结合上面两大技术的优缺点，企业在互联网公网做分支互联 时，产生了双重刚性需求：

网络功能层面 ：需要隧道支持组播 / 广播、动态路由、灵活组网 → 选用 GRE；
安全防护层面 ：需要对公网传输的所有报文加密、认证、防攻击 → 选用 IPSec。

业界最终确定组合逻辑：先 GRE 封装内网报文，再把整个 GRE 报文交给 IPSec 加密保护 ，也就是 GRE over IPSec（GRE 承载在 IPSec 之上）。

封装顺序解释（为什么是 GRE over IPSec，而非反过来）

网络界有两种组合形式，主流只选用 GRE over IPSec，这也是背景里重要的技术选型原因：

GRE over IPSec（主流）

封装层级：原始内网报文 → GRE 封装 → IPSec 加密 → 公网 IP 头

优势：IPSec 对整个 GRE 隧道流量统一加密，无需针对内网多网段配置复杂 ACL；所有组播、广播、路由报文全部被加密，安全覆盖完整；
运维：GRE Tunnel 接口负责路由转发，IPSec 负责安全，职责分离，逻辑清晰。

IPSec over GRE（极少使用）

封装层级：原始报文→IPSec 加密→GRE 封装→公网 IP 头

缺陷：IPSec 依然受组播限制，加密后的 IPSec 报文再进 GRE，依旧无法正常传递路由组播，等于没解决核心问题。

结论：技术特性决定了 GRE over IPSec 是唯一合理的融合方案。

**************************************************************************************************************

核心答疑：为什么 GRE 能简化 ACL？（重点区分两种部署模式）

先给结论先行：

不是用了 GRE 就不需要 ACL ，所有 IPSec 场景都必须有 ACL（感兴趣流），区别只在于：ACL 匹配的对象不一样；
传统纯策略型 IPSec ：ACL 匹配内网业务网段，内网网段越多、分支越多，ACL 越臃肿复杂；
工程主流 GRE over IPSec（接口绑定模式） ：ACL 只匹配GRE 隧道外层的公网 IP 流量，和内网网段无关，因此 ACL 极度精简；
你之前做 GRE 也要配感兴趣流，是因为用了老式「GRE + 流量型 IPSec」（淘汰方案），不是现在主流的接口绑定模式。

下面先定义两个关键部署形态，再用同一份多网段业务场景做三套配置对比，一眼看懂差异。

前置场景（统一测试环境）

总部公网 IP：202.1.1.1，内网多网段：192.168.1.0/24、192.168.2.0/24、192.168.3.0/24
分支公网 IP：202.1.1.2，内网多网段：192.168.11.0/24、192.168.12.0/24
需求：所有内网网段互相访问，流量加密穿越公网

场景 1：纯策略型 IPSec（无 GRE，传统方案）→ ACL 极度复杂

这就是最早的 IPSec 部署，ACL 直接匹配两端内网原始流量，有多少个网段，就要写多少条规则。

1. 总部 ACL 配置（核心痛点）

bash 复制代码

acl number 3000
 # 总部3个网段 → 分支2个网段，排列组合出 3×2=6 条规则
 rule permit ip source 192.168.1.0 0.0.0.255 destination 192.168.11.0 0.0.0.255
 rule permit ip source 192.168.1.0 0.0.0.255 destination 192.168.12.0 0.0.0.255
 rule permit ip source 192.168.2.0 0.0.0.255 destination 192.168.11.0 0.0.0.255
 rule permit ip source 192.168.2.0 0.0.0.255 destination 192.168.12.0 0.0.0.255
 rule permit ip source 192.168.3.0 0.0.0.255 destination 192.168.11.0 0.0.0.255
 rule permit ip source 192.168.3.0 0.0.0.255 destination 192.168.12.0 0.0.0.255

2. 问题总结

网段越多、分支越多，ACL 规则指数级增长；
新增内网网段，必须两端同步修改 ACL，运维麻烦；
这就是我们之前说的「复杂 ACL」的来源。

场景 2：老式 GRE + 流量型 IPSec（你之前实操的方案）→ 依然要复杂 ACL

很多教材 / 老旧配置会把 GRE 和策略 IPSec 结合，本质还是流量型 IPSec，ACL 依旧匹配内网业务流，所以你会觉得 "用了 GRE 还是要配感兴趣流"。

1. 逻辑流程

内网报文 → GRE 封装 → 原始 GRE 报文（内网 IP 头 + GRE 头）→ IPSec ACL 匹配内网网段 → 加密转发

2. ACL 配置（和纯 IPSec 完全一样）

ACL 3000 内容和上面场景 1 一模一样，还是 6 条规则，复杂度没有降低。

3. 结论

这种组合只是借用了 GRE 的组播 / 动态路由能力，没有改变 IPSec 的流量匹配逻辑，所以 ACL 依旧复杂，现网基本淘汰。

场景 3：主流方案 GRE over IPSec（Tunnel 接口 + 接口型 IPSec）→ ACL 极简（工程首选）

这是目前政企、运营商最常用的架构，也是「GRE 简化 ACL」的真正原因。

1. 核心逻辑变化（最关键）

所有内网流量先进入GRE Tunnel 虚拟接口 ，被统一封装成「总部公网 IP ↔ 分支公网 IP」的 GRE 报文；
IPSec 不再匹配五花八门的内网网段，而是直接绑定在 Tunnel 接口上；
此时 IPSec 的 ACL 只需要匹配：两端公网 IP 之间的 GRE 协议流量，和内网网段彻底无关。

2. 封装层级回顾

原始内网 IP → GRE 头 → 公网 IP 头 → ESP 加密 → 公网传输

对外只暴露一对公网 IP，内网网段被完全封装在 GRE 内部。

3. 极简 ACL 配置（总部 + 分支通用，仅 1 条规则）

bash 复制代码

# 总部 ACL 3000：仅匹配 总部公网IP <--> 分支公网IP 的 GRE 流量
acl number 3000
 rule permit gre source 202.1.1.1 0 destination 202.1.1.2 0

# 分支 ACL 3000：反向匹配
acl number 3000
 rule permit gre source 202.1.1.2 0 destination 202.1.1.1 0

4. 配套关键配置（接口型 IPSec 核心）

区别于策略模式，IPSec 直接应用在 Tunnel 接口，不再靠全局策略引流：

bash 复制代码

# 总部 Tunnel接口配置
interface Tunnel0/0/1 mode gre
 ip address 10.0.0.1 255.255.255.252  # 隧道互联地址
 source 202.1.1.1                     # 本端公网IP
 destination 202.1.1.2                 # 对端公网IP
 ipsec profile IPSEC-PROFILE           # 接口绑定IPSec模板（核心）

# 分支 Tunnel接口配置
interface Tunnel0/0/1 mode gre
 ip address 10.0.0.2 255.255.255.252
 source 202.1.1.2
 destination 202.1.1.1
 ipsec profile IPSEC-PROFILE

5. 该方案的巨大优势

ACL 永久固定 ：无论内网新增多少网段、多少 VLAN，ACL 不需要改一个字符；
新增内网网段，只需要在设备上添加静态 / 动态路由指向 Tunnel 接口即可；
完美兼容 OSPF/RIP 组播、广播，同时全程加密；
分支数量再多，ACL 依旧只有 1 条，运维零负担。

GRE over IP Sec的感兴趣流是GRE流量（公网）而不是原始私网流量

1. 先明确：GRE over IPSec 的保护对象是谁？

IPSec 的本质是「对指定的流量进行加密保护」，我们需要保护的是整个 GRE 隧道的所有流量，而不是隧道里的某一个私网网段。

如果把原始私网流量作为感兴趣流，那本质上还是原生 IPSec 的玩法，GRE 就失去了意义。而把 GRE 流量作为感兴趣流，有三个不可替代的优势：

优势 1：配置极简，彻底解耦业务和安全

感兴趣流只需要写一条规则：匹配「总部公网 IP → 分支公网 IP，协议号为 GRE（47）」的流量。华为防火墙 ACL 示例：

bash 复制代码

acl number 3000
 rule permit gre source 202.1.1.1 0 destination 202.1.1.2 0

无论 GRE 隧道里承载了多少个私网网段、多少种业务、是否跑动态路由，IPSec 配置完全不用改。新增业务只需要调整 GRE 隧道的路由，安全层无感知。

优势 2：符合分层设计原则

业务层：GRE 隧道负责内网连通、路由传递，管「传什么、怎么传」；
安全层：IPSec 负责对整条隧道加密，管「安不安全」。两层完全独立，故障排查也可以分层定位：先查 GRE 隧道通不通，再查 IPSec 加密有没有问题。

优势 3：天然支持所有 GRE 可封装的流量

GRE 能封装的组播、非 IP 协议、MPLS 标签等，只要匹配了 GRE 协议的感兴趣流，都会被 IPSec 自动加密，无需为每一种流量单独配置 ACL。

反例：如果用原始私网流量做感兴趣流

每新增一个业务网段，就要在 IPSec 的 ACL 里加一条规则，同时两端都要同步修改，运维成本极高，而且动态路由的组播报文还是没法被加密，失去了 GRE 的价值。

GRE over IP Sec 封装的三个报头

「三个 IP 头」是教学上的分层理解方式，对应IPSec 隧道模式下的 GRE over IPSec ；而工程中最常用的IPSec 传输模式是两个 IP 头。

先统一组网示例（全程沿用）

总部内网：192.168.1.0/24，公网 IP：202.1.1.1

分支内网：192.168.2.0/24，公网 IP：202.1.1.2

GRE 隧道接口地址：总部 10.0.0.1/30，分支 10.0.0.2/30

报文触发：PC1（192.168.1.1）访问 PC2（192.168.2.1）

1. 第一步：单独 GRE 封装（两个 IP 头）

报文到达总部路由器，查路由发现去 192.168.2.0 的下一跳是 Tunnel0（GRE 隧道接口），进行第一次 GRE 封装：

层级	内容	作用
第 1 层（最内层）	原始私网 IP 头 + 数据源 IP：192.168.1.1，目的 IP：192.168.2.1	用户原始业务报文
第 2 层（外层）	GRE 头 + 公网 IP 头源 IP：202.1.1.1，目的 IP：202.1.1.2协议号：47（表示载荷是 GRE）	GRE 隧道封装，公网路由转发依据

此时报文结构：公网IP头 + GRE头 + 私网IP头 + 数据，一共两个 IP 头，明文传输。

2. 第二步：IPSec 加密封装（分两种模式）

模式 A：IPSec 传输模式（工程主流，两个 IP 头，标准 GRE over IPSec）

这是现网 90% 以上的部署方式，没有第三个 IP 头，效率最高。

IPSec 传输模式的特点：在原始 IP 头和上层协议之间插入 ESP 头，不新增外层 IP 头。

这里的「原始 IP 头」就是 GRE 的外层公网 IP 头，上层协议就是 GRE 协议。

最终封装结构（从外到内）：

bash 复制代码

【公网IP头（GRE的源目：202.1.1.1→202.1.1.2）】
    ↓
【ESP头】
    ↓
【GRE头】
    ↓
【原始私网IP头（192.168.1.1→192.168.2.1）】
    ↓
【数据】
    ↓
【ESP尾 + ICV认证数据】

✅ 特点：只有两个 IP 头，额外开销小，转发效率高，是 GRE over IPSec 的标准部署形式。

模式 B：IPSec 隧道模式（三个 IP 头，你老师说的「封装更冗长」的情况）

IPSec 隧道模式的特点：把整个原始报文作为载荷，在最外面新增一层独立的 IPSec 外层公网 IP 头。

这里的「原始报文」就是整个已经封装好的 GRE 报文（含 GRE 外层 IP 头），所以最终会出现三层 IP 头：

最终封装结构（从外到内）：

bash 复制代码

【第3层：IPSec外层公网IP头（202.1.1.1→202.1.1.2）】
    ↓
【ESP头】
    ↓
【第2层：GRE外层公网IP头（202.1.1.1→202.1.1.2）】
    ↓
【GRE头】
    ↓
【第1层：原始私网IP头（192.168.1.1→192.168.2.1）】
    ↓
【数据】
    ↓
【ESP尾 + ICV认证数据】

✅ 特点：三个 IP 头，封装冗余，额外开销大，转发效率低。

关键疑问：既然源目 IP 完全一样，为什么还要多封装一层？

答：绝大多数场景下，这是多余的设计，所以现网几乎不用。只有一种特殊场景会用到：GRE 的源目 IP 是私网地址，需要 IPSec 隧道模式再封装一层公网 IP 实现跨公网转发（极少见于嵌套隧道场景）。

你老师讲「三个 IP 头」，更多是教学层面的分层逻辑：把「私网业务层、GRE 隧道层、IPSec 安全层」每层对应一个 IP 头，帮你直观理解每一层的封装作用，不用死记硬背。

原生IP Sec的隧道模式跟GRE over IP Sec的隧道模式对比

✅ 原生 IPSec 的隧道模式：现网极其常用，是站点到站点 VPN 的主流方案；
❌ GRE over IPSec 的隧道模式：现网几乎不用，99% 的场景都会选择「GRE over IPSec + 传输模式」。

两者的核心差异，本质是一句话：隧道模式的核心价值是「新增外层公网 IP 头，解决内层地址不可达的问题」------ 如果 GRE 已经完成了这个工作，IPSec 再套一层就是纯冗余，有害无利。

一、先把两个概念彻底掰开：别混为一谈

很多人学这里容易混淆，先明确两个独立维度：

维度 1：「原生 IPSec」 vs 「GRE over IPSec」------ 封装顺序不同

原生 IPSec：直接对原始业务报文做 IPSec 封装，中间没有其他隧道协议；

GRE over IPSec：先把原始报文封装成 GRE 报文，再对整个 GRE 报文做 IPSec 加密。

维度 2：「传输模式」 vs 「隧道模式」------ IPSec 自身的封装模式

这是 IPSec 协议本身的属性，和有没有 GRE 无关：

传输模式：不新增 IP 头，只在原 IP 头和载荷之间插 ESP 头；

隧道模式：新增一层外层 IP 头，把整个原始报文当载荷加密。

两个维度正交组合，理论上有 4 种方案，但现网常用的只有 2 种：

组合方案	现网使用频率	核心定位
原生 IPSec + 隧道模式	极高	标准站点到站点加密 VPN
GRE over IPSec + 传输模式	高	需动态路由 / 组播的加密 VPN
原生 IPSec + 传输模式	极低	仅主机端到端加密场景
GRE over IPSec + 隧道模式	几乎为 0	纯冗余，无实用价值

二、本质拆解：为什么 GRE over IPSec 不配隧道模式？

1. 先回顾：隧道模式的核心使命是什么？

IPSec 隧道模式诞生的唯一核心价值：给「公网不可达的内层 IP 报文」套一层公网 IP 外壳，让它能跨公网传输。

原生 IPSec 场景下，内层是私网 IP（192.168.1.0/24），公网路由器不认这个地址，必须靠隧道模式新增外层公网 IP（202.1.1.1），才能把报文送到对端。

这时候隧道模式是刚需，没有它报文根本传不过去。

2. 再看：GRE 本身已经完成了「跨公网封装」的工作

GRE 协议天生就是三层隧道协议，它的标准封装结构本身就有两层 IP：

bash 复制代码

【外层：GRE公网IP头】源202.1.1.1 → 目的202.1.1.2
    ↓
【GRE头】
    ↓
【内层：私网IP头】源192.168.1.1 → 目的192.168.2.1
    ↓
【业务数据】

也就是说：GRE 自己已经解决了「私网报文跨公网传输」的问题，外层公网 IP 已经能让报文在公网正常路由转发了。

3. 这时候再加隧道模式，就是纯纯的冗余

如果 GRE over IPSec 用隧道模式，IPSec 会把「整个 GRE 报文（含 GRE 外层公网 IP）」当成内层载荷，再套一层一模一样的公网 IP 头：

bash 复制代码

【第3层：IPSec外层公网IP】源202.1.1.1 → 目的202.1.1.2
    ↓
【ESP头】
    ↓
【第2层：GRE外层公网IP】源202.1.1.1 → 目的202.1.1.2
    ↓
【GRE头】
    ↓
【第1层：私网IP】源192.168.1.1 → 目的192.168.2.1
    ↓
【数据】

✅ 关键问题：两个外层 IP 头的源目地址完全一模一样，没有任何额外作用，就是重复封装。

而用传输模式的话，结构非常简洁高效：

bash 复制代码

【唯一外层公网IP（GRE的）】源202.1.1.1 → 目的202.1.1.2
    ↓
【ESP头】
    ↓
【GRE头】
    ↓
【内层私网IP】
    ↓
【数据】

三、现网为什么几乎不用 GRE over IPSec 隧道模式？4 个核心原因

组网场景	首选 IPSec 模式	核心原因
固定站点间原生 IPSec VPN（无 GRE）	隧道模式	内层私网 IP 公网不可达，必须靠隧道模式加外层公网 IP
GRE over IPSec（需动态路由 / 组播）	传输模式	GRE 已经提供外层公网 IP，隧道模式纯冗余，传输模式效率最高
两台主机端到端直接加密	传输模式	两端都是公网 IP，无需额外封装，开销最小

GRE over IP Sec的配置

是要在IP Sec的隧道上去跑GRE，要把路由丢进GRE隧道，不能丢进物理口

acl需要改变

这个acl是匹配不到感兴趣流的，如果想写简单一些可以就写成GRE

删除这个rule 5

改成

**************************************************************************************************************

这是 GRE over IPSec 场景下的标准最简写法 ，本质是：匹配所有协议号为 47 的 GRE 报文，全部交给 IPSec 加密处理。

它精准、省事、通用，完全契合「IPSec 保护整条 GRE 隧道」的设计逻辑，也是 HCIE 考试、现网运维的主流写法。

只要 IP 报文头里的「协议号字段 = 47」，就会被这条规则命中，和源 IP、目的 IP 无关，和内层承载的内容无关。

不管是总部发往分支的 GRE，还是分支发往总部的 GRE；

不管 GRE 里装的是 TCP 业务流量、OSPF 组播报文，还是 ICMP ping 包；只要外层是 GRE 封装，就会被这一条规则全部匹配到。

「GRE over IPSec 的设计本质」：IPSec 的保护对象，从「原始私网业务流量」变成了「整条 GRE 隧道的流量」。

现网还有一种更严谨的写法，就是指定 GRE 的源目公网 IP，两种写法都正确，区别如下：

写法	示例	适用场景	特点
最简全量	`rule permit gre`	单条 GRE 隧道、动态 IP 场景、教学实验	配置极简、兼容性强、维护方便
精确匹配	`rule permit gre source 202.1.1.1 0 destination 202.1.1.2 0`	多条 GRE 隧道共用一个公网接口、需要区分不同加密策略	更严谨、粒度更细，避免不同隧道策略混淆

**************************************************************************************************************

进入GRE隧道（配置GRE隧道）

隧道口的地址跟对端隧道口的地址不需要在同一个网段，因为OSPF建立的时候，遇见隧道口会认为是点到点类型，而点到点的网络类型在OSPF建立的时候不会看是否在同一网段的。

一定要将隧道口划入进安全区域，不划分到安全区域就没办法去处理单播报文了。

华为防火墙的所有三层接口（包括物理接口、Tunnel 逻辑接口），必须加入安全区域才能参与三层转发；未加入安全区域的接口，入向和出向的所有 IP 报文（包括单播）都会被防火墙直接丢弃，无法进行任何转发、封装、加密处理。

安全区域不是 "安全等级标签"，是转发的 "准入开关"

1. 默认铁则 ：未加入任何安全区域的接口，属于 "无归属" 的非法接口，防火墙不认可它的转发合法性。所有从这个接口进入、或者要从这个接口发出的报文，都会被直接丢弃，连路由查表、安全策略匹配的流程都进不去。

域间管控前提：只有两个接口都加入了安全区域，它们之间的流量才会进入 "域间安全策略" 的匹配流程，决定是放行还是拒绝。

单播是最基础、最通用的 IP 通信形式（比如 ping、业务访问）。连单播都无法处理，说明接口连最基础的三层转发能力都不具备；组播、广播等更复杂的流量就更不可能通了。

隧道口UP的条件

1、首先要有一个IP v4的地址

2、隧道口的目标地址要有路由，源地址必须是自己身上UP的地址

对端FW2上的配置

划入安全区域

把接口的Ping功能打开，FW1上配置

把接口的Ping功能打开，FW2上配置

现在由于隧道口不是同网段的IP地址，所以是没有路由的，这是不能通的。

**************************************************************************************************************

为什么GRE隧道口配置同网段的IP地址就能有路由，能通

GRE Tunnel 本质是一条「虚拟的点到点直连网线」，两端的隧道口 IP，就相当于插在这根虚拟网线两端的物理接口 IP。

同网段：接口 UP 后自动生成直连路由，设备天然知道这个网段要从 Tunnel 口出去，所以不用额外写路由就能通；

不同网段：路由表里没有对应网段的转发路径，设备不知道要把报文送进隧道，所以不通，必须手动加静态路由 / 动态路由指向 Tunnel 接口。

中间的公网设备完全感知不到隧道口的 IP，它们只负责转发外层的公网 GRE 报文 ------ 这就是「Overlay 隧道」的核心逻辑：上层虚拟网络跑在底层物理网络之上，互相解耦。

GRE 是标准的点到点（P2P）三层隧道协议，它在逻辑上完全模拟了一根 "看不见的网线"：

两端的 Tunnel 接口，就是这根虚拟网线的两个端头；

只要隧道协议 UP（也就是公网能通、GRE 源目配置正确），这根 "虚拟网线" 就相当于插好了；

接口 UP 后，设备会自动给 Tunnel 网段生成直连路由，和物理接口的直连路由没有任何区别。

完整转发流程：从 ping 发出到收到回复，报文走了两遍路由

这是最容易混淆的点：整个过程有两层完全独立的路由表查询，一层管隧道里面的虚拟流量，一层管隧道外面的公网物理流量。

第一步：内层路由查询（隧道 Overlay 层）

总部设备收到 ping 包：

内层 IP 头：源 IP=8.8.8.9（隧道口），目的 IP=8.8.8.8（对端隧道口）

查全局路由表：匹配直连路由 8.8.8.0/24，出接口Tunnel 0/0/1

结论：把这个报文送进 Tunnel 接口，做 GRE 封装。

第二步：GRE 封装 + 外层路由查询（公网 Underlay 层）

报文进入 Tunnel 接口后，设备做 GRE 封装：

加上 GRE 头（协议号 47）；

加上外层公网 IP 头：源 IP = 总部公网地址（比如 202.1.1.1），目的 IP = 分支公网地址（比如 202.1.1.2）。

封装完成后，设备第二次查路由表，这次查的是外层公网 IP 的路由：

外层 IP 头：源 202.1.1.1，目的 202.1.1.2

查公网路由：匹配默认静态路由，出接口是公网 GE0/0/0，下一跳是运营商网关。

结论：把封装好的 GRE 报文，从公网接口发出去。

第三步：公网转发（中间设备完全不感知内层）

互联网上的所有路由器、交换机，只看外层的 202.1.1.1→202.1.1.2 这个公网 IP 头，按正常公网路由一跳一跳转发，根本不知道里面还有一层 8.8.8.x 的 IP，也不知道这是 GRE 隧道。

第四步：分支端解封装 + 内层路由

分支公网口收到 GRE 报文：

识别 IP 协议号 = 47，知道是 GRE 报文，交给 Tunnel 接口处理；

剥掉外层公网 IP 头和 GRE 头，还原出内层原始 IP 报文：8.8.8.9→8.8.8.8；

查本地路由：目的 8.8.8.8 是自己 Tunnel 接口的 IP，直接接收处理。

第五步：回复报文原路返回

回复包走完全一样的流程：内层查直连路由进隧道→封装外层公网 IP→公网转发→总部解封装→接收。

🎯 一句话总结两层路由的分工：

内层隧道路由：管「报文要不要进隧道、进哪条隧道」，靠直连 / 静态 / OSPF 实现；

外层公网路由：管「封装好的隧道报文，怎么跨过互联网送到对端」，靠运营商公网路由实现。两层路由完全独立，互不干扰。

为什么不同网段的隧道口 IP，不写路由就不通？

反过来理解：

比如总部 Tunnel 口配10.1.1.1/24，分支 Tunnel 口配10.2.2.1/24，两个接口不在同一个网段。

不通的根因：内层路由缺失

总部 ping 10.2.2.1 的时候：

查路由表：只有直连的 10.1.1.0/24 网段，根本没有 10.2.2.0/24 的路由条目；

设备不知道这个目的地址要送到哪里，也不知道要送进 Tunnel 接口；

匹配不到路由，直接丢包，连 GRE 封装的步骤都进不去，自然就不通。

怎么才能通？

手动加一条静态路由，明确告诉设备：「10.2.2.0 这个网段，要从 Tunnel 接口发出去」

bash 复制代码

# 总部配置
ip route-static 10.2.2.0 255.255.255.0 Tunnel 0/0/1

加完之后，路由表里有了对应条目，ping 包就能匹配路由、送进 Tunnel 接口、触发 GRE 封装，后续流程和同网段完全一致，自然就通了。

延伸：为什么实际组网里，隧道口经常用 / 30 的同网段地址？

这是行业通用规范，核心原因有两个：

节省地址：点到点链路只需要 2 个可用 IP，/30 网段刚好 4 个地址（网络、两个可用、广播），不浪费；

天然生成直连路由：不用额外写静态路由，隧道 UP 了两端接口天然互通，配置最简洁，也不容易出错。

而内网业务网段（比如 192.168.1.0/24、192.168.2.0/24），才需要额外写静态路由，或者跑 OSPF 动态路由，把内网网段的下一跳指向 Tunnel 接口。

HCIE-Security 高频考点 & 排错坑

**************************************************************************************************************

隧道口地址改成同网段的IP，就能产生直连路由了

现在隧道口就能通了

如果依然是在隧道口上用不同网段的IP，可以运行OSPF（不要跟公网运营商网络起一样的ospf号）

FW1上配置

发布的是隧道口跟私网路由。

对端FW2上配置

**************************************************************************************************************

为什么不同网段，连路由都没有，还可以建立起OSPF邻居呢？

本质是 「GRE 隧道的点到点天然属性」+「OSPF 点到点（P2P）网络类型的特性」 共同作用的结果：

公网层：两端防火墙的公网口配好了 IP（总部 100.1.11.1、分支 100.1.12.2），配了运营商的默认路由，公网能互相 ping 通；

隧道层 ：两端配好了 GRE Tunnel 接口，源目填的是双方的公网 IP，此时display interface tunnel 0能看到「协议 UP」；

接口 IP ：给 Tunnel0 接口分别配上了不同网段的 IP：

总部 Tunnel0：9.9.9.9 255.255.255.0

分支 Tunnel0：8.8.8.8 255.255.255.0

这时候你会发现：直接 ping 对方的 Tunnel 口 IP 是不通的，你觉得 "连路都没有，OSPF 怎么可能建邻居？"。

第一部分：先打破你的核心误区

现在的固有认知是：「IP 通信必须先有路由，没有路由就发不了包」。

这个认知只适用于普通的以太网物理接口，放到「GRE 点到点隧道接口」上是不成立的。

1. 先搞懂：GRE 隧道的本质是什么？

GRE Tunnel 是一条虚拟的、纯点到点（P2P）的链路，你可以把它理解成一根「看不见的网线」，两头分别插在总部和分支的 Tunnel0 接口上。

这根虚拟网线有一个最关键的特性：

只要隧道协议是 UP 的，从本端 Tunnel 口发出去的任何报文（不管单播、组播、广播，也不管目的 IP 是什么网段），都会 100% 直接送到对端的 Tunnel 口。

它不需要 ARP 解析、不需要查下一跳、不需要关心目的 IP 属不属于同网段 ------ 因为链路只有两头，没有第三个节点，扔出去就只会到对面。

内层隧道的路由一开始没有，但外层公网的路由早就通了；而 GRE 封装后的报文，靠外层公网路由就能跑通，根本不需要内层的路由。

第二部分：OSPF 邻居到底是怎么建立起来的？（全程不用内层路由）

OSPF 建邻居的第一步，是发组播 Hello 包 "喊人"，而不是先发单播包。我们顺着时间线，走一遍第一个 Hello 包的完整旅程，你就彻底懂了。

步骤 1：OSPF 在 Tunnel 口启动，开始发送组播 Hello 包

在两端配置了ospf 1，并且用network命令把 Tunnel 接口的网段宣告进了 OSPF 区域 0。

这个network命令的第一个作用，就是让对应接口启用 OSPF 进程，开始周期性发送 OSPF Hello 报文。

OSPF Hello 包的固定格式：

目的 IP：224.0.0.5（所有 OSPF 路由器都监听的组播地址，相当于 OSPF 的 "公共频道"）

源 IP：本地 Tunnel 接口的 IP（总部是 9.9.9.9，分支是 8.8.8.8）

协议号：89（标识上层是 OSPF 协议）

步骤 2：组播 Hello 包从 Tunnel 口直接发出，不查单播路由表

重点来了：对于点到点（P2P）类型的接口，发送组播报文的时候，根本不会去查全局单播路由表。

设备的逻辑很简单：

这个 Tunnel0 接口是 P2P 类型，现在 OSPF 要从这个口发组播包，那直接把包从这个口扔出去就行 ------ 反正只有一个对端，肯定不会送错。

这个 Hello 包进入 Tunnel 接口后，立刻触发 GRE 封装：

加上 GRE 协议头（协议号 47）；

套上外层公网 IP 头：源 IP = 本地公网 IP，目的 IP = 对端公网 IP（GRE 隧道配置里的目的地址，是你早就写死的）。

步骤 3：外层公网报文靠公网路由跨网传输

封装好的 GRE 报文，外层是普通的公网 IP 报文（源 100.1.11.x，目的 100.1.12.x）。

设备查公网路由表（你早就配好的默认路由），把报文从公网物理口发出去，经过运营商网络，直达对端的公网接口。

步骤 4：对端解封装，把 Hello 包交给 OSPF 进程

对端防火墙的公网口收到报文，一看 IP 头里的协议号是 47，知道这是 GRE 报文，直接交给 Tunnel0 接口处理。

Tunnel 接口做两件事：

剥掉外层公网 IP 头和 GRE 头，还原出内层的原始 OSPF Hello 包；

把还原后的 Hello 包，交给本机的 OSPF 进程处理。

OSPF 进程收到 Hello 包后，校验参数（区域号、Hello 时间、Dead 时间等，P2P 类型不校验同网段），确认合法，就会在本地邻居表里记录：

我在 Tunnel0 接口上，发现了一个 OSPF 邻居，它的 IP 是 8.8.8.8。

步骤 5：双向 Hello 交互，邻居状态进入 2-Way

分支用同样的流程，把自己的 Hello 包发给总部。

当两边都收到了对方的 Hello 包，并且在对方的 Hello 里看到了自己的 Router-ID，OSPF 邻居状态就进入了2-Way------ 邻居关系的基础就建立完成了。

序号	操作 / 阶段	结果	核心逻辑
1	配公网 IP + 默认路由	公网能互相 ping 通	底层物理网络三层可达，是所有隧道的基础
2	配置 GRE 隧道源目	Tunnel 接口协议 UP	虚拟点到点链路打通，报文能物理上送达对端
3	给 Tunnel 口配 8.8.8.8/9.9.9.9	接口有 IP，但 ping 不通对方	没有对端网段的路由，设备不知道往哪发包
4	OSPF 宣告 Tunnel 接口网段	Tunnel 口启用 OSPF，开始发组播 Hello	P2P 接口组播直接发，不查单播路由，靠公网路由封装传输
5	双向收到 Hello，OSPF 邻居建立 Full	邻居起来了，但 ping 对方 Tunnel 口还是不通	邻居只是 "认识了"，但还没交换路由信息，全局路由表没有条目
6	双方交换 LSA，计算生成 OSPF 路由	路由表出现对端 Tunnel 网段的 OSPF 路由	设备知道了去往对端网段要走 Tunnel 口
7	ping 对方 Tunnel 口 IP	双向通了	报文能正确进入隧道，封装解封装闭环完成
8	宣告内网网段进 OSPF	两端内网也能互通	内网网段的路由也通过 OSPF 学习到，业务流量正常转发

网络类型	建邻居是否要求同网段	核心原因
广播型（Broadcast，普通以太网）	✅ 必须同网段	1. 以太网是多路访问，一个接口连很多设备，需要靠 ARP 解析下一跳的 MAC 地址；2. 不同网段无法完成 ARP 解析，单播报文根本发不出去；3. 组播 Hello 虽然能收到，但后续单播交互无法完成，建不了 Full 邻居。
点到点（P2P，GRE / 串口）	❌ 不需要同网段	1. 链路只有一个对端，没有二层 MAC 的概念，不需要 ARP；2. 组播、单播报文直接从接口发，一定能到对端；3. 路由只是 "指导业务报文进隧道"，不是建邻居的前置条件。

**************************************************************************************************************

FW1上是可以学到对端的私网路由的

OSPF 隧道开销：为什么隧道口网段是双倍 1562，私网是 1562+1

第一步：先钉死 2 个基础前提（所有计算的根源）

第二步：核心难点：OSPF 怎么描述一条 P2P 链路？（两次开销的根源）

Link 类型	Link ID	链路数据	携带的开销	本质作用
Type 1：点到点链路（P2P Link）	对端路由器的 Router-ID	本端 Tunnel 接口的 IP 地址	本端 Tunnel 接口的 Cost（1562）	描述「我和对端路由器之间有一条直连链路，走这条链路的成本是 1562」------ 对应过桥费
Type 3：存根网络（Stub Network）	本端 Tunnel 接口的网段地址	子网掩码	本端 Tunnel 接口的 Cost（1562）	描述「我自己直连着一个 IP 网段，要进入这个网段的成本是 1562」------ 对应桥头堡进门费

为什么要设计成 2 个条目？

第三步：站在总部视角，一步步算开销（彻底搞懂 2*1562）

知识点回顾：IPSec NAT 穿越、AH/ESP、传输 / 隧道模式的底层逻辑

一、前置基础：TCP 伪首部与校验和原理（所有问题的根源）

二、IPSec 两大协议：AH vs ESP，为什么放弃 AH？

IPSec 有两个核心协议：AH（认证头）和ESP（封装安全载荷）。现网几乎 100% 使用 ESP，AH 已经被淘汰，核心原因有两点：

1. 功能定位与覆盖范围对比

协议	核心功能	加密能力	认证 / 完整性校验范围
AH（认证头）	仅提供数据源认证、数据完整性校验、防重放	❌ 完全不加密，数据全程明文	整个 IP 报文（除 TTL、首部校验和等可变字段），包括 IP 头部
ESP（封装安全载荷）	同时提供数据加密、源认证、完整性校验、防重放	✅ 支持 AES 等强加密，加密传输层 + 数据	仅校验「ESP 头 + 加密载荷 + ESP 尾部」，不认证外层 IP 头部

2. 为什么 AH 被彻底淘汰？

三、两种封装模式：传输模式 vs 隧道模式的结构差异

四、核心问题：为什么传输模式不能穿越 NAT，隧道模式可以？

五、承接之前的知识点：GRE over IPSec 为什么用传输模式？

**************************************************************************************************************

NAT 的两类独立问题 + NAT-T 的本质 + GRE over IPSec 的适配逻辑

我先帮你把之前零散的知识点拆成两个完全独立的 NAT 问题，你之前混淆了「TCP 校验和问题」和「NAPT 端口区分问题」------ 这两个是 NAT 场景下完全不同的两个难点，对应不同的解决方案，搞懂这个你就全通了。

第一部分：先破题：NAT 场景下 IPSec 面临 2 个完全独立的问题

很多人学这里会乱，核心是没分清：NAT 不是一个问题，是两个不同维度的问题，解决方案也完全不同。

问题分类	问题本质	谁能解决	谁解决不了
问题 A：内层 TCP/UDP 校验和失效	NAT 修改 IP 地址后，TCP 伪首部校验和对不上	✅ IPSec 隧道模式能解决❌ IPSec 传输模式解决不了	NAT-T 不解决这个问题
问题 B：NAPT 无法区分多条 ESP 流	ESP 是 IP 协议号 50，没有 TCP/UDP 端口，多对一 NAT（PAT）没法区分不同用户的 VPN 流	✅ NAT-T（UDP 4500 封装）能解决❌ 传输模式、隧道模式都解决不了	隧道模式解决不了这个问题

之前讲的「传输模式不能穿越 NAT，因为 TCP 校验不通过」，只说了问题 A；

你现在问的「为什么隧道模式还要加 NAT-T」，对应的是问题 B------ 隧道模式解决了问题 A，但天生解决不了问题 B，必须靠 NAT-T 补全。

第二部分：详解问题 B：为什么原生 ESP 隧道模式，也需要 NAT-T？

1. 先分清：NAT ≠ NAPT，我们日常遇到的 99% 是 NAPT

很多人对 NAT 的认知停留在「改 IP 地址」，但实际企业出口、家用宽带用的都是 NAPT（网络地址端口转换，也叫 PAT、多对一 NAT）：

普通 NAT（一对一静态 NAT）：只改 IP 地址，一个公网 IP 对应一个内网主机，不需要端口；

NAPT（多对一）：多个内网主机共用一个公网 IP，靠「IP 地址 + TCP/UDP 端口号」区分不同的数据流，这是最主流的 NAT 形态。

2. ESP 的天生缺陷：没有端口号，NAPT 认不出来

ESP 协议的身份是IP 协议号 50 ，它直接封装在 IP 头后面，没有 TCP/UDP 层，也就没有端口号。

这就导致 NAPT 设备遇到 ESP 报文时：

只能看到「IP 头 + 协议号 50」，没有端口号可以做映射；

如果只有一个内网用户发起 VPN，NAPT 还能勉强一对一转发；

如果有多个内网用户同时发起 IPSec VPN，NAPT 根本分不清哪个 ESP 报文对应哪个内网主机，只能乱转发，最终隧道全断。

哪怕你用的是 ESP 隧道模式，外层有独立的公网 IP 头，也改变不了「IP 头里协议号是 50、没有端口」的本质 ------NAPT 只认「IP + 端口」，没有端口就没法做多用户映射。

3. NAT-T 的核心作用：给 ESP 套上 UDP 端口 "马甲"

NAT-T（NAT Traversal，NAT 穿越）的本质非常简单：给整个 ESP 报文，再套一层 UDP 4500 的报文头，强行给 ESP 加上端口号。

封装后报文结构（ESP 隧道模式 + NAT-T）：

bash 复制代码

【外层公网IP头（NAT可修改）】
    ↓
【UDP头（源端口随机，目的端口固定4500）】 ← NAT-T新增的，给ESP加端口
    ↓
【ESP头】
    ↓
【内层原始IP + TCP/UDP + 业务数据（全加密）】
    ↓
【ESP尾 + ICV校验】

解决逻辑：

NAPT 设备现在看到的是「IP + UDP 4500 端口」的普通 UDP 报文，完全可以靠端口号区分不同用户的 VPN 流，做正常的端口映射；

NAPT 只修改外层 IP 和 UDP 端口，碰不到里面加密的 ESP 和内层 IP，不影响 IPSec 的加密、认证、校验；

对端防火墙收到后，剥掉 UDP 4500 的头，剩下的就是正常的 ESP 报文，按原有的 IPSec 流程解密处理。

4. NAT-T 是自动协商的，不需要手动强制开启

华为等主流防火墙默认开启 NAT-T，整个探测和切换过程是 IKE 阶段 1 自动完成的：

双方一开始用 UDP 500 端口（标准 IKE 端口）发起协商，报文中携带NAT-D（NAT 发现）载荷；

NAT-D 载荷里是「源 IP + 端口、目的 IP + 端口」的哈希值，双方对比本地计算的哈希和收到的哈希，如果不一致，就说明中间路径存在 NAT；

检测到 NAT 后，双方自动把后续的 IKE 协商和 ESP 数据，都切换到UDP 4500 端口封装，也就是启用 NAT-T；

全程不需要人工干预，设备自动适配。

📌 HCIE 考点补充：为什么不用原来的 UDP 500，要切到 4500？因为很多 NAT 设备会对 UDP 500 端口做特殊限制，或者修改 500 端口的载荷；而 UDP 4500 是 IANA 专门分配给 IPSec NAT-T 的端口，NAT 设备对它的处理更友好，不会随意修改载荷。

第三部分：GRE over IPSec 需要 NAT-T 吗？分场景结论

1. 先看本质：GRE over IPSec 的外层还是 ESP

GRE over IPSec（传输模式）的报文结构是：

bash 复制代码

【公网IP头】
    ↓
【ESP头】 ← 外层协议号还是50，和原生ESP没有区别
    ↓
【GRE头】
    ↓
【内层私网IP + 数据】

它的外层依然是IP 协议号 50 的 ESP 报文 ，和原生 ESP 传输模式、隧道模式在 NAPT 面前的处境完全一样：没有端口号，NAPT 没法区分多流。

2. 分场景给出明确结论

**************************************************************************************************************

GRE over IP Sec 修改成传输模式

需要重启