第45篇：NAT 穿越问题与 ALG
关键词：NAT穿越、NAT-PT、ALG、应用层网关、FTP穿越、SIP穿越、STUN、华为配置
一、引言
NAT 让内网设备可以访问外网，但它也带来了一个棘手问题：如果通信双方都在 NAT 后面，或者应用层协议本身携带了 IP 地址信息，简单的 NAT 就无法正常工作了。这就是 NAT 穿越（NAT Traversal）问题。
ALG（Application Layer Gateway，应用层网关）是解决 NAT 穿越问题的关键机制。它能够"深入"应用层协议载荷，识别并修改其中嵌入的 IP 地址和端口信息，使得被 NAT 阻断的通信得以恢复。
二、核心概念
2.1 NAT 穿越问题的本质
NAT 只修改 IP 包头和 TCP/UDP 头部的地址和端口信息。但如果协议的应用层载荷中也携带了 IP 地址或端口号，NAT 设备无法感知和修改这些内嵌地址，导致通信失败。
| 问题类别 | 说明 | 典型协议 |
|---|---|---|
| 载荷中的地址 | 协议载荷中携带 IP 地址或端口 | FTP、SIP、H.323、RTSP |
| 多通道连接 | 协议需要建立多个连接（控制+数据） | FTP、SIP |
| 双向连接 | 双方都需要主动发起连接 | P2P、VoIP |
| ICE/NAT 类型 | 对称型 NAT 导致端口不可预测 | STUN/TURN 场景 |
2.2 ALG 工作原理
ALG 是部署在 NAT 设备上的一个"协议理解器"。它在 NAT 地址转换的同时，对特定应用层协议的载荷进行检查和修改。
ALG 处理流程：
1. 检测到特定协议（如 FTP 控制连接）
2. 解析应用层载荷中的 IP 地址和端口
3. 将载荷中的私网地址替换为公网地址
4. 为载荷中提到的端口预先创建 NAT Session（预测性映射）
5. 完成协议载荷和 IP 头的双重转换
2.3 支持 ALG 的常见协议
| 协议 | ALG 作用 | 常见问题 |
|---|---|---|
| FTP | 修改 PASV 响应中的 IP 和端口，预建 DATA 通道映射 | 被动模式文件传输失败 |
| SIP | 修改 SDP 中的 c= 和 m= 行地址 | VoIP 单向无声、无法建立通话 |
| H.323 | 处理呼叫信令和媒体流地址 | 视频会议室连接失败 |
| RTSP | 修改 RTSP 描述中的媒体流地址 | 流媒体播放失败 |
| DNS | 检查 DNS 响应中的地址信息 | 内网域名解析回环问题 |
| PPTP | 处理 GRE 隧道封装 | VPN 连接无法建立 |
| TFTP | TFTP 载荷不携带 IP 地址，但每个传输使用独立的临时 UDP 端口，需相应 NAT 映射/会话支撑 | 传输中断、超时 |
注：华为 VRP 的 nat alg 支持协议为 dns/ftp/sip/pptp/rtsp（
nat alg { all | protocol-name } enable），未将 TFTP 列为受支持协议；TFTP 穿越 NAT 通常靠固定端口映射（nat server）加 NAT 会话老化配合解决。
三、技术细节
3.1 FTP ALG 详解
FTP 是 ALG 最经典的应用场景。FTP 使用两个独立的连接：控制连接（端口 21）和数据连接（随机高端口）。
FTP 主动模式（PORT）流程： 1. 客户端打开一个随机端口 P，向服务器 21 端口发起控制连接 2. 客户端打开端口 P+1，通过控制连接告知服务器"请连接我的 IP:P+1" 3. 服务器从 20 端口主动连接客户端的 IP:P+1 建立数据连接
问题：客户端在 NAT 后面，它告诉服务器的 IP 是私网地址，服务器无法直接连接。
FTP ALG 处理： - 修改控制连接中 PORT 命令的 IP 和端口（私网→公网） - 在 NAT 设备上预先创建从服务器 20 端口到客户端的映射
FTP 被动模式（PASV）流程： 1. 客户端向服务器 21 端口发起控制连接 2. 客户端发送 PASV 命令 3. 服务器打开随机端口 Q，回复"请连接我的 IP:Q" 4. 客户端连接服务器的 IP:Q 建立数据连接
问题：服务器在 NAT 后面，它回复的 IP 是私网地址，客户端无法直接连接。
FTP ALG 处理： - 修改 PASV 响应中的 IP 和端口（私网→公网） - 在 NAT 设备上创建从客户端到服务器端口 Q 的映射
# 启用 FTP ALG（缺省未使能，需要时显式开启）
[HUAWEI] nat alg ftp enable
# 说明：nat alg 只有 enable / undo 两种形式，不支持"端口范围""超时"等子参数；
# 如需限定被动模式数据端口段：在 FTP 服务器上配置 PASV 端口范围，
# 再在 NAT 设备上对该端口段做映射（写法见第44篇，以设备版本手册为准）
# 验证 ALG 使能状态
<HUAWEI> display nat alg
# 回显各协议 ALG 的使能状态（status），格式以设备版本为准
3.2 SIP ALG 详解
SIP（Session Initiation Protocol）用于 VoIP 呼叫建立，SDP（Session Description Protocol）载荷中携带了 RTP 媒体流的 IP 和端口信息。
SIP 信令交互（无 ALG 时）：
呼叫方（NAT后） NAT 设备 被叫方
| | |
INVITE |------------------->|------------------>|
(SDP: 192.168.1.10:5000) | (只转换IP头) |
| |
| 被叫方收到错误IP |
| 媒体流无法建立 |
SIP 信令交互（有 ALG 时）：
呼叫方（NAT后） NAT 设备 被叫方
| | |
INVITE |------------------->|------------------>|
(SDP: 203.0.113.1:12345) | (转换IP头+SDP载荷) |
[ALG修改了SDP中的IP:端口] | |
| 被叫方收到正确IP |
| 媒体流正常建立 |
# 启用 SIP ALG
[HUAWEI] nat alg sip enable
# 说明：SIP 信令/媒体流的会话老化由 NAT Session 老化时间控制，
# nat alg 本身没有独立的超时参数（以设备版本手册为准）
# 验证
<HUAWEI> display nat alg
3.3 DNS ALG
DNS ALG 解决内网 DNS 响应中的 NAT 回环问题。
# 启用 DNS ALG
[HUAWEI] nat alg dns enable
# 配置 DNS Mapping：域名 → 公网地址 → 公网端口/协议（与 NAT Server 的发布项对应）
[HUAWEI] nat dns-map www.company.com 203.0.113.10 80 tcp
# dns-map 表项是 DNS 响应的改写依据（缺一不可，仅使能 nat alg dns 不会改写）；
# 条目数有上限（如 AR 系列最多 64 条），支持情况以设备版本手册为准
# 场景（前提：203.0.113.10 是 NAT Server 对外发布 www.company.com 的公网地址）：
# 内网 PC 查询 www.company.com → DNS 返回 203.0.113.10（公网 IP）
# 设备按 DNS Mapping 表项 + NAT Server，将响应中的 203.0.113.10 替换为 192.168.1.100（inside 地址）
# PC 直接用私网地址访问内网服务器，避免"内网访问公网地址"绕经 NAT 设备（回环问题，见第44篇案例二）
3.4 ALG 的启用与关闭
# 查看所有 ALG 状态
<HUAWEI> display nat alg
# 关闭特定 ALG（某些场景下 ALG 会干扰业务）
[HUAWEI] undo nat alg ftp enable
# 批量关闭所有 ALG
[HUAWEI] undo nat alg all enable
# 注：nat alg 命令没有独立的 disable 形式，关闭一律用 undo nat alg ... enable；
# 缺省情况下 NAT ALG 处于未使能状态
四、实战配置/案例分析
4.1 案例一：FTP 被动模式穿越故障
故障背景：某企业 FTP 服务器（192.168.10.50）通过 NAT Server 对外发布。外网用户可以登录 FTP，但下载文件时连接立即断开。
# 排查过程：
# Step 1: 抓包分析
# 发现 PASV 响应中服务器返回的 IP 为 192.168.10.50，端口 55001
# 客户端尝试连接 192.168.10.50:55001 → 超时（公网无法访问私网地址）
# Step 2: 检查 ALG 状态
<HUAWEI> display nat alg
# 查看 FTP 等协议 ALG 的使能状态；缺省未使能
# Step 3: 启用 FTP ALG
[HUAWEI] nat alg ftp enable
# 若已限定被动模式端口段（如 50000~55000），需确保 NAT 侧有对应映射，
# 做法见第44篇（nat alg 命令本身不支持 port-range 子参数）
# Step 4: 在 FTP 服务器上配置被动模式端口范围
# Windows IIS FTP: 被动端口范围 50000~55000
# Linux vsftpd: pasv_min_port=50000, pasv_max_port=55000
# Step 5: 验证
# 再次抓包，PASV 响应中的 IP 已变为公网 IP 203.0.113.10
# 客户端成功连接数据通道，文件下载正常
4.2 案例二：SIP 电话单向无声
故障背景：企业部署了 IP-PBX（192.168.10.200），SIP 电话注册正常、可以振铃、可以接通，但通话时只有一方能听到声音。
# 排查过程：
# Step 1: 分析信令
# INVITE 中 SDP 携带 RTP 地址 192.168.10.100:16384
# NAT 只转换了 IP 头，SDP 中的地址未修改
# 对方发送 RTP 到 192.168.10.100:16384（私网地址），无法到达
# Step 2: 启用 SIP ALG
[HUAWEI] nat alg sip enable
# Step 3: 验证
# SIP ALG 修改 SDP 中的 RTP 地址为 203.0.113.1:映射端口
# RTP 媒体流双向正常，通话双方都能听到声音
# 补充：如果 SIP 服务器也在 NAT 后面，需要同时配置 NAT Server 发布 SIP 端口
[HUAWEI] nat server protocol udp global 203.0.113.1 5060 inside 192.168.10.200 5060
4.3 案例三：ALG 导致的问题
故障背景：某企业使用 IPSec VPN 连接分支机构，启用 ALG 后 VPN 隧道频繁中断。
# 问题根因：
# ALG 会深度检测某些协议的数据包
# 对于加密流量（如 IPSec ESP 包），ALG 尝试解析但失败
# 部分设备的 ALG 实现会对无法解析的包做丢弃处理
# 解决方案：
# 方案1：关闭相关 ALG（如不需要 FTP/SIP 穿越时）
[HUAWEI] undo nat alg ftp enable
[HUAWEI] undo nat alg sip enable
# 方案2：通过 ACL 让加密流量绕开 NAT（具体命令以版本手册为准）
# 思路：nat outbound 的语义是 ACL 匹配 permit 的流量做地址转换、deny 的流量不转换，
# 因此应在 NAT 引用的 ACL 中用 deny 排除 IPSec 流量，其余流量 permit 正常转换
# 示例1：在现有 Easy-IP 的 ACL 中先 deny 掉 IPSec 站点网段
[HUAWEI] acl 2000
[HUAWEI-acl-basic-2000] rule 5 deny source 10.1.1.0 0.0.0.255
[HUAWEI-acl-basic-2000] rule 10 permit source 192.168.1.0 0.0.0.255
# 示例2：用高级 ACL 按协议排除 ESP/IKE（nat outbound 支持 2000~3999，可用高级 ACL）
[HUAWEI] acl 3100
[HUAWEI-acl-adv-3100] rule 5 deny esp
[HUAWEI-acl-adv-3100] rule 10 deny udp source-port eq 500 # IKE（源端口 500）
[HUAWEI-acl-adv-3100] rule 15 permit ip
[HUAWEI] interface GigabitEthernet0/0/1
[HUAWEI-GigabitEthernet0/0/1] nat outbound 3100
# deny 的 ESP/IKE 流量不转换（绕开 NAT），其余流量正常地址转换；规则号与写法以版本手册为准
4.4 STUN 与 NAT 穿越（P2P 场景）
对于 P2P 视频会议、在线游戏等场景，ALG 不是唯一方案。STUN（Session Traversal Utilities for NAT）协议也是一种重要的 NAT 穿越机制。
| 机制 | 原理 | 适用场景 |
|---|---|---|
| ALG | 在 NAT 设备上修改应用层载荷 | 企业网关、路由器 |
| STUN | 客户端主动探测自己的公网映射地址 | P2P 应用、VoIP 终端 |
| TURN | 通过中继服务器转发媒体流 | 对称型 NAT、严格防火墙 |
| ICE | 综合 STUN + TURN + 直连，选择最优路径 | WebRTC、现代 VoIP |
注意：STUN/TURN/ICE 是应用层协议，与 ALG 是互补关系，不是替代关系。
五、总结
| ALG 协议 | 解决的核心问题 | 典型故障现象 |
|---|---|---|
| FTP ALG | PASV/PORT 模式中的地址转换 | 登录正常、传输失败 |
| SIP ALG | SDP 中 RTP 地址转换 | 能振铃、单向无声 |
| DNS ALG | 内网 DNS 响应回环 | 内网访问域名走外网 |
| H.323 ALG | 信令与媒体流地址分离 | 视频会议无法建立 |
| ALG 配置最佳实践 | 说明 |
|---|---|
| 按需启用 ALG | 不需要的协议关闭 ALG，避免干扰 |
| 限定应用动态端口段 | 在应用服务器侧限制动态端口范围（如 FTP PASV 50000~50100），缩小 ALG 处理面；nat alg 命令本身无端口范围参数 |
| 监控 ALG Session | 检查 ALG 创建的 Session 是否正常 |
| 注意 ALG 兼容性 | 加密流量、非标端口可能导致 ALG 异常 |
| ALG + NAT Server 组合 | 对外发布的服务器需要同时配置两者 |
| 抓包验证 | 使用 Wireshark 验证载荷中的地址是否正确转换 |
思考
- 为什么 FTP ALG 需要在数据通道建立之前就预先创建 NAT Session？如果不在控制连接阶段处理会有什么问题？
- ALG 对加密流量（如 HTTPS、IPsec）是否有效？为什么？
- 如果一个应用使用了非标准端口（如 FTP 不使用 21 端口），ALG 还能正常工作吗？
下篇预告：第46篇：DHCP 原理：Discover→Offer→Request→ACK