ALG应用层网关：NAT协作原理与启用条件

在大多数普通网络连接中，NAT只需要处理IP报文头以及TCP、UDP端口，就可以让使用私有地址的内网设备访问外部网络。但FTP、SIP等协议存在一个额外问题：建立后续连接所需要的IP地址、端口等信息，有时会直接写在应用层报文中。

这些地址进入NAT设备后，并不会因为外层IP地址已经完成转换而自动同步变化。如果对端继续按照应用报文中的私有地址建立连接，就可能出现数据通道无法建立、媒体无法到达等情况。

ALG（Application Layer Gateway，应用层网关）在这类场景中的主要作用，是识别特定应用协议，解析其中与地址、端口和后续连接有关的信息，并与NAT或状态防火墙协同处理。它并不是所有网络都必须开启的功能，也不能简单等同于防火墙、安全检测或Windows中的同名服务。

NAT为什么会遇到应用层地址问题

NAT的基本任务是转换网络层和传输层中的地址信息。例如一台内网终端以192.168.1.20发起TCP连接，经过NAT后，外部服务器看到的可能是路由器的公网地址以及重新分配的源端口。NAT设备保存这组映射，使返回报文能够再次找到原来的内网终端。

对于HTTP等单连接应用，这种方式通常已经足够。但有些协议会在一个控制连接中协商另一个连接，并把建立后续连接所需的地址或端口直接写入应用载荷。

这时需要区分两个层面：

• NAT地址转换：处理IP报文头以及TCP、UDP端口。
• 应用层信息处理：识别应用报文中携带的地址、端口以及相关连接参数。

普通NAT能够看到一个TCP或UDP会话，却不一定知道应用载荷中的某个数字代表另一条即将建立的数据连接。因此，当协议设计依赖这类信息时，才可能需要ALG或其他NAT穿透机制协助。

这也是理解ALG的关键：ALG不是NAT本身，而是针对特定应用协议给NAT提供额外上下文。

ALG如何与NAT协同处理连接

不同厂商对ALG的实现存在差异，但在NAT环境中，其基本处理逻辑通常包含协议识别、载荷解析、地址处理和关联会话建立几个环节。

识别应用协议

当流量经过启用了相关ALG功能的路由器或防火墙时，设备首先判断报文是否属于FTP、SIP等能够解析的协议。有些设备主要依据标准端口识别，也有设备能够进一步结合协议特征进行判断。

因此，使用非标准端口时，不能默认ALG仍然一定能够生效，需要结合具体网络设备的实现确认。

读取载荷信息

识别协议后，ALG会检查应用层报文中与连接相关的信息，例如FTP控制连接中的数据地址和端口，或者SIP信令与SDP中描述的联系地址、媒体地址和媒体端口。

配合NAT建立映射

如果应用报文中携带的私有地址在跨越NAT后已经不可使用，ALG可以按照自身实现修改相关字段，并使NAT建立与之对应的转换状态。

对于需要额外数据连接的协议，设备还可能根据控制连接中的协商结果建立临时关联状态，使后续连接能够通过NAT或状态防火墙。这类临时放行机制在部分设备文档中也被称为Pinhole。

需要注意，Pinhole、NAT映射和防火墙策略属于不同概念。ALG只是根据应用协议获得更多连接信息，并不意味着它单独承担完整的访问控制或网络安全功能。

FTP和SIP中的处理方式并不相同

FTP和SIP经常被用来说明ALG，但两种协议的通信模型并不一样。ALG只有理解具体协议，才能判断哪些字段与后续连接有关。

FTP：控制连接与数据连接分离

FTP通常使用控制连接传递命令，再建立独立的数据连接进行文件传输。这种设计使NAT不仅要处理已经存在的控制连接，还要知道后续数据连接将使用什么地址和端口。

在主动模式中，客户端可以通过PORT或EPRT等命令向服务器提供数据连接端点。如果客户端位于私有网络，而控制报文中仍携带私有地址，公网服务器就无法直接按照这个地址建立数据连接。

FTP ALG可以解析控制报文，识别其中的地址和端口，根据NAT后的实际连接条件进行相应处理，并使NAT为后续数据连接建立必要状态。

在被动模式中，服务器通过PASV等响应告诉客户端连接哪个数据端口。如果FTP服务器位于NAT之后，同样需要保证返回给客户端的连接信息与公网侧实际可达地址一致。

如果服务器已经正确配置公网地址、被动端口范围以及相应的NAT和防火墙规则，则是否还需要FTP ALG，应根据具体部署判断，而不是机械地要求启用。

SIP：信令与媒体需要分别判断

SIP环境更容易把不同问题归到ALG上。排查之前首先要区分SIP注册、会话建立和RTP媒体传输：

• REGISTER：用于SIP终端向注册服务器登记自身的可联系信息。
• INVITE等SIP消息：用于发起、建立、修改或结束会话。
• SDP：通常用于描述媒体地址、端口、编码等会话参数。
• RTP/RTCP：负责实际语音、视频媒体及相关控制数据传输。

如果位于私网中的SIP终端在Via、Contact或SDP等位置留下了跨NAT后不可达的地址，SIP ALG可能解析这些SIP消息，并根据实际NAT映射修改需要处理的地址或端口，同时为后续媒体连接建立相应状态。

但SIP ALG并不是RTP音质优化器。通常的SIP ALG重点在于SIP信令、SDP和NAT关联处理，并不需要为了改善音质而修改RTP序列号、时间戳，也不会替代抖动缓冲、丢包补偿、QoS或语音编码机制。

ALG何时有用，何时可能产生干扰

判断ALG是否应该开启，核心不是“网络中有没有NAT”，而是当前协议是否需要中间设备理解应用载荷，以及网络中是否已经有其他设备完成了相同工作。

以下情况中，ALG可能具有实际价值：

• 应用协议在载荷中携带经过NAT后失效的私有地址或端口；
• 协议需要根据控制连接动态建立其他数据连接；
• 终端本身没有完成相应的NAT处理；
• 网络架构明确依赖路由器或防火墙的协议ALG建立相关会话状态。

另一方面，ALG也可能成为兼容性问题来源。

例如在VoIP系统中，SIP服务器、SBC、媒体代理或终端可能已经完成NAT地址处理。如果边界路由器上的SIP ALG再次修改Contact、Via或SDP等信息，就可能形成重复处理，使原本已经正确的地址再次发生变化。

另一个限制来自加密。ALG能够修改应用载荷的前提，是中间设备能够读取相关协议内容。如果FTP控制通道、SIP信令等采用端到端加密，而ALG设备并不终止该加密连接，就无法按照普通明文ALG的方式读取和修改其中的地址信息。

因此不能简单得出“ALG默认开启更好”或者“SIP ALG一定要关闭”的统一结论。FTP ALG、SIP ALG以及其他协议ALG应分别判断。

启用或关闭前需要确认哪些条件

遇到FTP数据连接失败、SIP注册异常或单向语音时，直接切换ALG开关虽然容易，但并不能证明故障一定由ALG造成。更可靠的方式是先确定通信链路中各个组件的职责。

尤其是在SIP故障处理中，关闭SIP ALG与关闭SPI状态检测不是同一件事。为了验证SIP ALG，没有必要同时关闭防火墙SPI、放宽整个UDP策略或者改变其他无关的安全设置。

不同品牌、型号和固件版本的路由器，其SIP ALG、SIP Helper或SIP Passthrough实现和菜单位置可能不同。因此，比起使用固定的“某品牌路由器关闭步骤表”，更合理的方法是找到与SIP协议处理直接相关的设置，并在其他网络参数保持不变的条件下单独进行对照测试。

配置变更后如何确认ALG是否影响通信

ALG问题不能仅凭“开启后能打电话”或“关闭后恢复正常”作最终判断。配置修改后，应结合信令、媒体、连接状态和抓包结果确认真正发生了什么变化。

1. 先记录原始状态。 在修改配置前记录终端地址、NAT位置、服务器地址、注册状态以及当前ALG设置，避免测试过程中失去基线。
2. 一次只修改一个变量。 测试SIP ALG时不要同时修改SPI、防火墙、端口映射和QoS，否则即使故障消失，也无法确认是哪项配置起作用。
3. FTP同时验证控制和数据连接。 能够登录FTP服务器并不代表文件传输正常，还需要测试实际上传、下载，并检查数据连接是否建立。
4. SIP分阶段检查。 先确认REGISTER，再检查INVITE、响应、ACK和BYE等信令，随后核对SDP中的媒体地址和端口，最后检查RTP是否双向到达。
5. 比较地址是否被异常改写。 在条件允许时对NAT内外侧进行抓包，对比SIP头域、SDP或FTP控制命令，确认ALG究竟修改了哪些内容。
6. 测试双向业务。 VoIP应同时测试呼入、呼出、双向语音和通话释放，避免只根据“可以注册”判断整个通信链路正常。
7. 保留配置回退路径。 如果调整ALG后出现新的注册、呼叫或媒体问题，应先恢复原配置，再继续定位，而不是连续修改多个网络参数。

SIP注册失败、呼叫建立失败、单向语音或者通话一段时间后中断，都可能与NAT和ALG有关，但也可能来自SIP服务器配置、SDP地址、防火墙策略、端口范围、媒体代理或终端自身配置。故障现象本身不能直接证明ALG就是原因。

对于科能融合SIP服务器、语音网关、调度系统及其他SIP终端的跨NAT部署，也建议先明确SIP信令和RTP媒体的实际路径，再决定是否启用边界设备上的SIP ALG。通过拓扑、信令和抓包结果判断，比按照品牌或设备类型统一执行“开启”或“关闭”更可靠。