3.1 隧道技术与叠加网络 Overlay
3.1 隧道技术与叠加网络 Overlay
上一章确立了"控制器下发策略、边缘执行"的分权框架；本节解释策略执行的第一载体——Overlay。它在整个体系里的位置：Underlay 提供裸连通性，Overlay 在其上加密成网，第 3.2/3.3 节的感知与选路都发生在 Overlay 隧道这一层。读完本节，你应当能把"叠加网络"从名词变成一张可计算的隧道拓扑账。
为什么公网不能直接跑业务流量
企业流量上公网面对的是三重不可信：信道不可信（中间设备可窃听篡改）、寻址不可信（分支多为动态地址，藏在 NAT 后面）、质量不可信（运营商之间绕路、拥塞丢包）。Overlay 的回答分三步：用 IPSec 封装解决机密性与完整性；用站点注册加控制器的牵线（类似打洞）解决 NAT 后可达性；用多隧道并行把"单路质量"问题转化为"选路"问题——后两步正是 3.2 与 3.3 的主题。
Overlay 与 Underlay 的分工
Underlay 只负责"把 IP 包从 A 送到 B"：MPLS 电路、宽带、4G/5G，各有各的质量特征，Overlay 对它们一视同仁。Overlay 层维护一张隧道拓扑：每个站点边缘与其它站点边缘之间建立 IPSec 隧道，隧道端点信息（地址、承载链路、颜色标记，如"这端走 MPLS、那端走宽带"）由控制器统一登记与分发。业务流量在边缘按策略被引入不同隧道——应用层看到的只是一个虚拟的扁平专网，底层怎么绕、走哪条线，应用无感知。
隧道拓扑的算术：全网状还是中心枢纽
n 个站点两两建隧道，数量是 n×(n−1)/2：10 站 45 条，50 站 1225 条，500 站约 12.5 万条。好在 SD-WAN 边缘通常按需建隧道——流量触发才建，闲置超时拆除——控制平面只登记端点信息，压力远小于字面数字。工程上仍有取舍：全网状（任意两点直达）时延最优，适合站点少、互访密的网络；中心枢纽（各站只连区域 Hub，经 Hub 中转）把隧道数压成 n，代价是中转绕路，适合站点多、互访少的连锁形态；多数成熟部署是混合：区域内网状、跨区走枢纽、SaaS 流量本地分流出去根本不进隧道。
图：Overlay 与 Underlay 分层：隧道把异构链路缝成一张虚拟专网
隧道怎么建起来：注册、牵线、协商
分支藏在 NAT 后、地址还是动态的，两点怎么找到彼此？标准答案是控制器牵线。分支上电后通过零接触流程（第 6 章展开）向控制器注册，上报自己的公网映射地址与可用承载链路；控制器把对方的端点信息推给双方；两端直接协商 IPSec（IKEv2，证书认证而非预共享密钥），隧道建立。整个过程不需要任何一方有固定公网地址。看一遍时序更直观：
加密不是选项，是默认
传统组网里 IPSec 是"按需拨号"：敏感流量才拉 VPN。SD-WAN 把它翻转为默认全覆盖——所有 Overlay 隧道一律 IPSec，因为底层混进了不可信的公网。这带来两个工程后果：其一，边缘设备的加密吞吐成为硬指标，选型时看"IPSec 开启后的实测吞吐"而不是裸转发性能；其二，密钥管理集中化——证书由控制器体系签发与轮换，站点增删不牵一发动全身。
隧道颜色的巧思：同一条链路的两副面孔
主流方案有个精巧设计值得单独讲：链路颜色标记。同一个站点的同一条物理宽带，边缘设备可以为它建立多条不同颜色的隧道——比如"业务色"与"探测色"。业务色隧道承载业务流量并按业务 SLA 校准；探测色隧道专门跑探测包，探测间隔更密、优先级更低，用于提前发现拥塞苗头。还有一个用途：同一条宽带走不同运营商出口（策略路由分出两条路径）时，两个方向各自建隧道、各自标色、各自体检——一条物理线在拓扑上变成两条逻辑链路，选路粒度更细。颜色机制的原理就是隧道元数据里加了个标签字段，但它让"链路"这个概念彻底虚拟化了——3.2 节体检单上的"一条链路"，未必对应一条物理线。
问题：隧道全互联会不会造成广播或路由风暴？
不会，这是 Overlay 与传统二层组网的本质区别。SD-WAN 隧道是三层点到点封装，没有二层广播域的概念；路由信息由控制平面集中计算分发，不存在传统动态路由协议的全网洪泛。即便 500 个站点的全网状，隧道也只是"静静躺在那里等流量触发"的状态条目，不产生周期性广播。真正要控制的不是风暴，是控制平面的状态数量——这也是大规模网络采用枢纽与按需建隧道的原因。
问题：为什么不用现成的商用 VPN 产品拼一个？
拼得出连通，拼不出体系。商用 VPN 能在两点之间建加密通道，但它没有：集中的拓扑与端点管理（几百站点的 VPN 网关配置是运维灾难）、按应用的选路（VPN 是"全部流量走这条隧道"的粗粒度）、链路级体检与秒级切换（VPN 故障切换通常靠路由协议，收敛以十秒计）。SD-WAN 的价值不在隧道本身，而在隧道之上那套"感知、决策、编排"的体系——这正是第 2 章三件套存在的意义。
隧道的保活与"半开"陷阱
每条隧道都需要保活机制，细节里藏着一个经典陷阱：半开隧道。一端认为隧道活着（在发探测、也收得到自己方向的包），另一端其实已经重建或失效——中间某台 NAT 设备悄悄换了映射表项就会造成这种状态。业务流量打进半开隧道的结果是单向通、双向断，症状诡异且难查。成熟方案的对策是双向确认：探测包要求对端在固定窗口内回执，连续若干个窗口收不到回执即判隧道失效并重建，重建走控制器重新牵线。验收时可以主动制造半开（在中间防火墙上静默丢弃一个方向的隧道流量），看平台多久发现、业务多久恢复——判得快、恢复稳的方案，才配得上"自愈"两个字。
本节要点
- Overlay 三步回答公网三重不可信：IPSec 保机密、控制器牵线穿 NAT、多隧道把质量变成选路问题。
- 隧道数量按 n×(n−1)/2 增长，用按需建隧道与枢纽拓扑控制规模；SaaS 流量分流后根本不进隧道。
- 封装开销约 50–73 字节，MTU 与 MSS 不调会出"能通但慢"的暗坑，验收要逐条隧道打大包验证。
- 加密从按需变默认：看加密后吞吐选边缘，密钥由控制器体系集中签发轮换。
隧道把流量装进了管道，但管道有好有坏——下一节解决"怎么知道每条管道此刻的质量"。