4. NAT穿透与ALG技术
NAT在解决IPv4地址枯竭问题的同时，也破坏了IP端到端透明性。对于VoIP、FTP、SIP这类在载荷中携带地址和端口信息的应用，NAT设备若只做简单的地址端口转换，往往会导致连接建立失败或媒体流单向不通。本节从NAT对典型应用的影响入手，分析ALG、STUN、TURN、ICE四类穿透方案的原理、适用场景与配置要点。
一、NAT对应用协议的三类破坏方式
NAT对应用的影响可以归纳为三种机制。第一种是地址嵌入：应用层协议把私网IP和端口写在报文载荷里，NAT只改IP头和TCP/UDP头，载荷中的私网地址原样转发到公网，对端按该地址回包必然失败。FTP的PORT/PASV命令、SIP的SDP中的c=和m=行、H.323的Q.931消息都属于此类。
第二种是反向连接不可达：主动方在私网内监听端口，公网对端无法直接发起连接，因为NAT没有为该端口建立映射。FTP主动模式、SIP被叫方接收INVITE、VoIP的RTP媒体流都可能遇到。
第三种是端口映射超时：NAT的UDP映射通常只有30～120秒，TCP映射数分钟到数小时。SIP注册周期、RTP静默期、FTP控制连接空闲期若超过映射老化时间，映射被删除后后续报文无法通过。
二、ALG：让NAT“看懂”应用层
ALG（Application Level Gateway，应用层网关）的思路是让NAT设备解析应用层载荷，识别其中的地址端口字段，在转发时同步修改。以FTP主动模式为例，客户端在私网10.1.1.10:50000向服务器21端口发起控制连接，NAT为其建立映射并分配公网地址203.0.113.5:40001。客户端发送PORT 10,1,1,10,195,80（即10.1.1.10:50000），ALG解析该命令后改写为PORT 203,0,113,5,156,65（即203.0.113.5:40001），服务器据此向公网地址发起数据连接，NAT再根据已有映射转发回私网客户端。
SIP ALG的处理更复杂：它需要解析SIP消息头中的Via、Contact、From字段，以及SDP中的c=连接地址和m=媒体端口，分别改写为NAT的公网映射。配置时通常在NAT策略中启用alg sip或alg ftp。但SIP ALG在多层NAT、SIP over TLS、SDP中带多路媒体时容易出错，很多运营商网络反而建议关闭SIP ALG，改用STUN/TURN/ICE方案。
三、STUN：发现自己的公网映射
STUN（Session Traversal Utilities for NAT，RFC 5389）不修改应用载荷，而是让客户端主动向公网STUN服务器发送Binding Request，服务器把观察到的源地址端口放在Binding Response的XOR-MAPPED-ADDRESS属性中返回。客户端由此得知NAT为自己分配的公网映射，这个地址称为srflx候选（server-reflexive candidate）。
STUN能工作有一个前提：NAT是锥形（Cone）类型。锥形NAT对同一内部地址端口的映射，允许任意外部地址通过该映射回包。若NAT是对称型（Symmetric），同一内部地址端口访问不同外部目标会分配不同公网端口，STUN发现的映射只对STUN服务器有效，对通信对端无效，此时STUN失效，必须用TURN中继。
STUN服务器通常部署在公网，监听3478/UDP和3478/TCP。客户端配置示例（以coturn客户端为例）：
# 向STUN服务器查询公网映射
stunclient 203.0.113.40 3478
# 输出示例：
# Binding test: success
# Local address: 10.1.1.10:50000
# Mapped address: 203.0.113.5:40001四、TURN：中继兜底
TURN（Traversal Using Relays around NAT，RFC 5766）在公网部署中继服务器。客户端向TURN服务器申请一个relay地址，所有发往对端的流量先发给TURN，由TURN转发。TURN必然能穿透NAT，因为客户端到TURN是主动出站连接，TURN到对端也是主动出站或已有映射。代价是带宽和时延增加，服务器成本高，因此TURN只作为STUN失败时的兜底。
TURN的典型交互：客户端发送Allocate请求，TURN返回XOR-RELAYED-ADDRESS（如203.0.113.41:50000）；客户端用CreatePermission授权对端IP；再用Send/Data指示把媒体封装在TURN消息中转发。配置时需在TURN服务器上设置realm、认证方式（长期凭证或OAuth）、端口范围与带宽限制。
五、ICE：组合候选，择优连通
ICE（Interactive Connectivity Establishment，RFC 8445）不是一种新的穿透协议，而是一套框架，把host、srflx、relay三类候选地址组合起来，通过STUN Binding请求做连通性检查，选出可用且优先级最高的路径。候选优先级通常按类型排序：host > srflx > relay，同类型内再按本地偏好和组件ID计算。
ICE工作流程可概括为：收集候选（host从本地接口获取，srflx从STUN获取，relay从TURN获取）→ 交换候选（通过SIP/SDP或信令通道）→ 配对并排序 → 连通性检查（STUN Binding Request/Response）→ 提名并选定路径。若host和srflx都失败，才使用relay。ICE还处理了NAT类型变化、多网卡、IPv6/IPv4双栈等复杂场景。
六、方案选择与配置要点
| 方案 | 原理 | 适用场景 | 局限 |
|---|---|---|---|
| ALG | NAT解析并改写应用载荷地址 | FTP、SIP、H.323等传统协议 | 多层NAT、加密载荷失效；SIP ALG常出错 |
| STUN | 客户端发现公网映射 | 锥形NAT、UDP媒体 | 对称型NAT失效 |
| TURN | 公网中继转发 | 对称型NAT、严格防火墙 | 带宽成本高、时延增加 |
| ICE | 候选收集+连通性检查 | WebRTC、现代VoIP | 需信令通道交换候选 |
判断穿透是否成功，可在客户端抓包观察：STUN Binding Response是否返回了非私网的XOR-MAPPED-ADDRESS；ICE是否收到Binding Success；媒体流是否双向到达。若只有单向流，通常是NAT映射未建立或ALG改写不完整。排查时先确认NAT类型（用STUN测试），再检查ALG开关与映射老化时间，最后考虑部署TURN中继。