运营商侧承载方案是什么
这类方案解决的是运营商在只有六层链路可用时，如何继续为用户提供四层访问能力。用户侧四层流量先被封装进六层报文送到运营商侧设备，由它解封装并用共享的四层地址访问外部；或者由运营商按算法把四层地址与端口范围成块映射给用户，用户按规则自行封装。
为什么端口范围要成块
共享地址意味着多用户共用一个对外地址，只能靠端口号区分。动态分配端口时会话日志压力大、可预测性差；成块映射则给每个用户固定的端口范围，规则一旦下发，用户与服务商都能预先知道可用端口，便于放行与审计。
基本信息
| 隧道型方案 | 用户侧四层流量整体封装到运营商侧设备 |
|---|---|
| 映射型方案 | 四层地址与端口块按算法静态映射 |
| 共享地址范围 | 运营商级地址转换专用段 |
| 前提条件 | 链路本身必须具备六层能力 |
| 共同影响 | 对外地址与端口可能变化，影响固定端口类应用 |
典型使用场景
- 宽带开通排障：用户报“没有公网地址”时，先确认线路采用哪种承载方式
- 服务对外发布：需要固定端口对外时，确认运营商是否提供成块映射，否则端口不可用
- 日志溯源：共享地址环境下必须保存映射记录，否则无法把外部访问对应到具体用户
- 合规审计：审计要求可追溯到用户级时，成块映射比动态分配更容易满足
- 游戏与实时通信：部分应用依赖特定端口范围，成块映射的可用性明显更好
- 迁移评估：从共享地址迁移到原生双栈时，评估哪些应用依赖四层地址
用户侧确认要点
用户侧确认要点
# 在用户侧路由器上确认对外看到的地址与端口
curl -s https://ifconfig.example/ | head # 示例：查看出口地址
# 记录出口地址与端口范围，与运营商下发的映射规则比对
# 若应用需要固定端口，确认该端口是否落在映射块内
# 运营商侧查询映射规则得到当前生效的地址与端口范围方案对比
| 方案 | 原理 | 可预测性 | 适用判断 |
|---|---|---|---|
| 隧道型 | 四层流量封装到运营商侧设备 | 端口动态，不可预测 | 兼容性最好 |
| 映射型 | 地址与端口块静态映射 | 端口块可预测 | 便于放行与审计 |
| 纯转换 | 仅四层侧共享地址 | 依赖会话日志 | 传统方式 |
| 原生双栈 | 无共享地址 | 完全可预测 | 最优但需网络支持 |
用户侧统一排障动作是先确认出口地址与端口范围、再比对应用是否需要固定端口、最后核对映射记录与日志时间是否对应，这三步能解决绝大多数“外网访问不稳定”的问题。
把共享地址范围与私有地址混用是常见误解：共享地址段既不属于私有地址，也不可全球路由，规划与过滤规则时要单独对待。