隧道过渡是什么
没有原生六层链路时，可以把六层报文封装在四层报文里穿越现有网络，两端解封装后再还原成六层流量。这类做法叫隧道过渡，好处是不需要运营商改造网络，代价是增加了封装开销与运维复杂度，而且沿途设备对封装协议的处理方式各不相同。
常见几种方案
固定端点隧道用专门的协议号承载，需要两端都有公网地址；面向运营商的版本在固定端点基础上把四层地址与六层前缀做了算法映射，便于批量部署；面向带地址转换的主机方案改用用户数据报承载，能穿透部分转换设备但性能一般；还有一种基于特定前缀的自动隧道方案，因为缺乏可控性已被标准标注弃用。
基本信息
| 固定端点隧道 | 使用专门的封装协议号，两端需公网地址 |
|---|---|
| 运营商版本 | 在固定端点基础上做地址与前缀的算法映射 |
| 主机穿透方案 | 改用用户数据报承载，可穿透部分转换设备 |
| 自动隧道方案 | 基于固定前缀自动生成，标准已弃用 |
| 共同代价 | 封装开销、路径不可控、排障链路变长 |
典型使用场景
- 应急接入：暂时无法获得原生链路时，用固定端点隧道先把六层连通性建立起来
- 实验环境：在实验室里模拟跨网段六层互通，验证应用与策略的兼容性
- 路径摸底：先用隧道验证目标服务可达，再评估是否值得推动原生链路改造
- 排查小包通大包不通：隧道封装占用额外字节，大包触发路径最大传输单元问题
- 迁移评估：把隧道作为过渡手段纳入迁移计划，明确退出时间与替换路径
- 安全评估：隧道会绕过部分策略检查，上线前必须纳入安全检查范围
MTU 提醒
MTU 提醒
隧道需减去封装开销，常见的做法是把六层接口的最大传输单元调低
或对传输控制协议做最大报文段长度钳制，避免小包通、大包不通
# 症状：小包能通（连通性测试正常），大包全部丢失（页面打不开）
# 处置：放行承载单元过大的差错报文，或按封装层数调低接口值隧道方式对比
| 方式 | 封装形式 | 适用场景 | 现状 |
|---|---|---|---|
| 固定端点 | 专门协议号 | 两端有公网地址 | 经典可用 |
| 运营商版 | 运营商封装的固定端点 | 快速铺开六层 | 区域性使用 |
| 主机穿透 | 用户数据报承载 | 位于转换设备之后的主机 | 遗留方案，性能一般 |
| 自动隧道 | 特定前缀自动生成 | 早期过渡 | 标准已弃用 |
判断是不是封装开销引起的问题，常用办法是逐步加大探测报文长度：小包正常、超过某个尺寸后全部丢失，基本可以确定是路径最大传输单元与差错报文放行的问题。
不要在生产环境依赖已弃用的自动隧道方案：主流网络对其过滤严格，路径质量差，遇到问题几乎没有可用的排查手段，应尽快迁移到原生双栈或地址转换方案。