ＮＡＴ协议复杂性（ＲＦＣ ３０２７）

NAT RFC 3027---NAT协议复杂性

许多因特网应用可能被不好地影响，当终端结点不在同个地址域中， 且寻求IP 网络地址转换吕器（NAT） 终端路由的辅助以桥接这些域。该NAT 设备单独不能提供全部情况下的必要应用/协议透明度， 且寻求可能的应用层网关（ALG ）的辅助，以提供透明度。本文的目的是指出这些被NAT 终端路由所阻止的协议和应用。本文还尝试指出任何已知工作区。在单个文档中捕获全部被NAT 所阻止的应用是不可能的。本文尝试捕获心可能多的信息，但决不是完全覆盖。我们希望该覆盖为未覆盖的应用提供足够线索。

1.0 简介

本文要求读者熟悉如[NAT-TERM] 中所述的NAT 设备的术语和功能。在坚壳中，NAT 尝试提供透明路由解决方案给要求与完全不同地址域通迅的终端结点。NAT 修改终端结点地址（在分组的IP 头部内），终端路由并维护这些更新的状态，以便属于某个会话的数据报在任何域中被透明路由到正确的终端结点。可能时，应用特定ALG 可以与NAT 联合使用以提供应用层透明度。不像NAT，ALG 的功能是应用特定的，且将很可能要求检查并重组IP 负载。

下面章节尝试列出已知被NAT 调协终端路由所冲击的应用。然而，这决不是所有已知与NAT 有复杂性的协议和应用的完全列表——代之以仅是作者所收集清单的一个子集。还要重点注意的是， 本文并不是意图鼓吹NAT，而代之以指出当NAT 设备是终端路由时的协议和应用的复杂性。

2.0 NAT所阻止的一般协议特性

. [NAT-TERM] 和[NAT-TRAD] 有专门的章节列出NAT 设备的总是和限制的特定属性。某些限制在本节中重新说明，以总结NAT 所阻止协议的特性。

2.1 负载中域特定IP 地址信息

.广泛应用的NAT 终端路由失败，当IP 分组在负载中包含域特定IP 地址或端口信息时。ALG 可能大约在某些情况下能够使其工作。但是，若该分组负载被IPsec 加密（或被传输或应用层安全机制加密），则该应用注定要失败。

2. 2 打包会话应用

打包会话应用如FTP、H.323、SIP 和RTSP，它们使用控制连接以建立数据流，也都通常会被NAT 设备终端路由所阻止。这是因为这些应用在控制会话中交换地址和端口参数以建立数据会话和和会话方向。NAT 不可能知道这些打包会话的内部依赖关系，且将对待每个会话为相互间没有关系。在该情况下的应用可能因多种原因而失败。2 个最可能的失败原因是：

（a）控制负载中的地址信息是域特定的，且一旦分组跨过发起域时就是无效的，（b）控制会话允许数据会话从NAT 可能不许可的方向上发起。

当DNS 域名在控制负载中使用时，与DNS-ALG 关联的NAT 设备可能提供必要的应用层透明度，若NAT 对数据会话方向没有争议。然而，使用DNS 域名代替域特定IP 地址可能不是许多这些应用（如，FTP ）的选项。

当域特定寻址在负载中规定时，且该负载没被加密，则在某些情况下ALG 可能提供大约可使这些应用透明地跨域运行的机能。ALG 的复杂度取决于应用层要求处理负载和维护状态的知识。

2.3 点到点应用

点到点应用比基于客户——服务器的应用更可能被NAT 终端路由所阻止。不像客户—— 服务器应用，点到点应用可以由任何点发起。当点分布跨私有和公共域时，源自外部域的会话正好仿乎该会话来自私有域中的主机。外部结点将能够定位它们在私有域内的结点，仅当Holdrege 和Srisuresh 信息化2 页它们提前知道外部分配的IP 地址或FQDN 时。对已分配地址映射的FQDN 域名只可出现在终端路由NAT 设备支持DNS-ALG 时。点到点应用的例子包括交互游戏、因特网电话和基于事件的协议（如即时消息）。

这对于传统NAT 特别成问题，且对双向NAT 的问题更小，后者允许会话在两个方向上。

解决传统NAT 的这类问题的一种可能的方法是为私有主机维护与作为代表它们到全局路由因特网的向外连接。

2.4 使用NAPT 终端路由的IP 分片

使用NAPT 终端路由的IP 分片对任何单个应用不是问题，但遍及所有TCP/UDP 应用。该问题在[NAT-TRAD] 中详细描述。简而言之，该问题产生如下。比如，2 个私有主机发起分片TCP/UDP 分组到同个目标主机。而且，它们碰巧使用相同的分片标识符。当目标主机收到这2 个不相关的数据报时，挟带相同的分片ID，且从相同的已分配主机地址，这时目标主机不能判断该数据报属于这2 个会话中的哪个。因而，2 个会话都将被破坏。

2.5 要求维持地址映射的应用

NAT 将更可能阻止要求地址映射跨持续会话被维持的应用。这些应用要求私有到外部地址映射在会话间被维持，以便同个外部地址可为后序会话交互操作重用。NAT 不可能知道这种要求，且可能重新分配外部地址给会话间的不同主机。

试图保持NAT 不丢弃地址映射将要求为NAT该应用扩展协议以允许应用提醒该NAT设备保持该映射。另外，ALG 可能被要求与NAT 交互以保持地址映射不被NAT 所丢弃。

2.6 需要超过可用公共地址数的应用

当私有主机数量大于可用于映射私有地址的外部地址数时，这就是个问题。举个例子， 被NAPT所支持的源自私有域主机的rlogin 服务。rlogin 服务客户端使用众所周知的rlogin 端口512 作为它们的TCP 端口ID。某个私有域中不能有多个主机发起该服务。这是个试图使用某个根本需要超过可用公共地址数的服务的问题。NAT 设备可以保存地址，但它们不能创造更多地址。

2. 3.0 不能与NAT 终端路由协同工作的协议

3. 3.1 IPsec和IKE

NAT 基本通过修改终端结点地址（IP 头部内） 的终端路由来运作。另一方面IPsec AH 标准[IPsec-AH] 明确设计来检测对IP 分组头部的修改。因此当NAT 修改IP 头中中的地址信息终端路由时，收到该已修改分组的目标主机将使该分组无效，因该头部的内容已经被修改。其结果是，跨NAT 的IPsec AH 加密分组将完全到不了目标应用。

IPsec ESP（[IPsec-ESP]）加密分组只在有限种情况下可以被NAT 设备终端路由修改。在TCP/UDP 分组的情况下，NAT 将需要更新TCP/UDP 头部中的校验和，当IP 头部中的地址被修改时。然而，因TCP/UDP 头部被ESP 加，NAT 加将不能使该校验和更新。因此，在传传层模式ESP 中加密的TCP/UDP 分组，跨过NAT 设备在接收端将会使TCP/UDP 校验和验证失败且将完全到不了目标应用。

因特网密匙交换协议IKE 在主要、侵略和快速模模式中可以潜在地传递IP 地址作为结点标识符。为使IKE 协商正确地通过NAT 传递，这些负载需要被修改。然而，这些负载经常被哈希算法保护或被加密算法隐藏。甚至在IP 地址没有被用在IKE 负载中且IKE 协商可能不间断发生的情况下，也存在困难从IKE 完成协商时到IPsec 在某个应用上使用该值时之间保留NAT 上的私有到外部地址映射。最终，端到端IPsec 的使用最终将严重防碍，如上所述。

对于全部实践用途而言，端到端IPsec 不可能同NAT 终端路由一起完全。

3.2 Kerberos 4

Kerberos 4 的门票被加密了。因此，ALG 不能被编写。当KDC 收到门票请求时， 它在返回门票中包括源IP地址。并非全部Kerberos 4 服务都会实际检测源IP地址。AFS是Kerberos 4 服务器的很好例子，它就不（检测）。不检测的服务不会对NAT 设备终端路由有挑剔。Kerberos 门票与请求该门票的IP 地址捆在一起且使用它的服务使用门票。

K4 门票（ 响应）包含单个IP 地址，它描述客户端所使用来获取来自从KDC 观点的TGT 的门票的接口。若该KDC 跨NAT 网关，这工作很好，且这时全部Kerberos 服务也跨NAT 网关。私有网络上的终端用户将不会查觉到任何问题。

还要警告，NAT 在客户端和KDC 间使用同个为连接私有主机的地址映射以在客户端和应用服务器间建立连接。围绕该问题的一个操作将是在整个门票生存期间保持某个武断连接对远程服务器打开，以不使NAT 丢弃该地址绑定。另一种是，ALG 将需要被部署以确保在门票生存其间和门票发给私有主机时刻和门票被私有主机使用的时刻间该NAT 将不会修改地址绑定。

然而，该门票将对NAPT 私有域内的任何主机有效。离开NAPT， 某个攻击者需要能够欺骗某个连接的源IP 地址，该连接被创建以便使用在不同主机上的被盗门票。使用NAPT ，所有攻击者需要从NAPT 的私有域来运行来简单得到一张门票权利。当然，这是假设，NAPT 私有域不是可信任网络——不要惊奇， 因许多攻击从组织内部发生。

3.3 Kerberos 5

刚好如同使用Kerberos 4 一样，Kerberos 5 的门票被加密了。因此，ALG 不能被写出。

在Kerberos 5 中，客户端指定该门票应对其有效的IP 地址清单，或者它可以要求对所有IP 地址有效的门票。通过要求全部IP 地址门票或包含NAPT 设备地址的门票，你可以使krb5 与NAPT 设备协同工作，尽管它不是非常透明（ 它要求客户端表现得与另外情况不同）。MIT krb5 1.0 实现没有为客户要求什么IP 地址（它始终要求它的接口地址集） 的任何可配置性且与NAT 的交互不是很好。MIT krb5 1.1 实现允许你在krb5.conf 中某处放置“noaddresses”以请求全部IP 地址有效门票。

K5 门标（ 响应）包含IP 地址，如客户端结点所请求，从这里该门票将被认为有效。若使用Kerberos 认证的服务正被访问且位于NAT 的公共侧，这时Kerberos 认证将会失败因NAT（基本NAT 或NAPT ）所用的IP 地址不在可接受地址清单中。

在Kerberos 5 中存在2 个工作区，它们将降低该门票的安全性。第一个是使在NAPT 私有域中的客户端在门票IP 清单中指定该NAPT 的公共IP 地址。但这将对K4 引起同样的安全问题。加上，对在私有域中的客户端不能明显地发现NAPT 的公共IP 地址。它将在终端主机上引起对应用行为的修改。

第二个方法是从K5门票删除全部IP地址但现在这将使该门票偷窃甚至更严重因该门票可从任何地方使用。而不只是从该私有网络内。

3.4 X窗口系统和X 终端/Telnet

X 窗口系统基于TCP。然而，与这些应用的客户——服务器关系同多数其它应用的反向比较。X 服务器或开放窗口服务器是显示/鼠标/键盘单元（如，控制实际窗口接口的部分）。客户是操作该窗口接口的应用程序。

一些机器在同个机制上运行多个X 窗口服务器。首个X 窗口服务器位于TCP 端口6000。首个开放窗口服务器可位于端口6000 或端口2000（更灵活）。这里我们主要引用X 窗口系统作为说明用途。

X 终端从客户端到服务器传输IP 地址，为了设置DISPLAY 变量。当设置DISPLAY 变量被用于从该主机上的X 客户端到工作站上的X 服务器的后序连接时。该DISPLAY 变量在TELNET 协商期间内线发送为：

DISPLAY=<local-ip-addr>:<server>.<display>

这里的<local-ip-addr> 通过观察用于连接到<server> 的套接口相关的本地IP 地址来获取。<server> 决定哪个端口（6000+<server> ）应该被用于创建该连接。<display> 用于指示附加到X 服务器上的哪个显示器应用被使用，但对该讨论不重要。

所使用的<local-ip-addr> 不是DNS 域名因为：

.•离开执行对local-ip-addr 的反向DNS 查询， 本地机器不能知道它的DNS 域名。

.•不能保证反向DNS 查询所返回的域名实际映射回本地IP 地址。

•最后，离开DNSSEC，使用DNS 地址是不安全的，因为它们可以被轻松地欺骗。NAT 和DNS-ALG 不能工作除非DNSSEC 被关闭。

该应用的一般用法是人们从它们家里的X 终端播号到公司办公室。比如，X 客户端正运行于NAT 公共侧的主机上，且X 服务器正运行于NAT 私有侧的主机上。该DISPLAY 变量以某种方式内线传输到X 客户正运行的主机。传输该DISPLAY 变量内容的进程不知道该NAT 的地址。

若传输DISPLAY 变量的通道没有加密，则NAT 设备可能恳求ALG 的帮助来替换该IP 地址且在有效显示范围内（端口6000 或更大）配置一个端口以作为网关。另一个方法，NAT 可以被配置为监听向内的连接以提供对X 服务器的访问，不需要ALG 。但，该方法增加安全风险，通过提供否则将不可能的访问给X 服务器。因ALG 篡改IP 地址，它不将不可使用非MIT-MAGIC-COOKIE-1X 认证方法。MIT-MAGIC-COOKIE-1 是全部归档X 认证方法中安全性最小的。

当使用START_TLS 时，这里可能存在由NAT 引起的客户端证书验证问题，取决于在该证书中所提供的信息。

3.5 RSH/RLOGIN

RSH 使用多个会话为stdout 和stderr 支持单独的流。一个随机端口号从客户端被内线传输到服务器作为stderr 端口。该stderr 套接口是从服务器回到客户端的连接。且不像FTP，这里没有等价的PASV 模式。对于传统NAT，这是个问题，因传统将不允许向内会话。

RLOGIN 不使用多个会话。但Kerberos 保护版的RSH 和RLOGIN 将不会在NAT 环境中工作因门票问题和使用多个会话。

4.0 可以在ALG 辅助下工作的协议

本文主要指出与传统NAT，特别是NAPT 相关的问题。

4.1 FTP

FTP 是基于TCP 的应用，用于在2 个主机间可靠传输文件。FTP 使用捆绑会话方法来完成它。

FTP 由客户端发起，访问FTP 服务器上的众所周知端口号21。这被称为FTP 控制会话。通常，额外的数据会话伴随该控制会话。缺省时，该数据会话将从服务器的TCP 端口20 到客户端用于发起控制会话的TCP 端口。然而，该数据会话端口可以在FTP 控制会话中修改， 使用ASCII 编码的PORT 和PASV 命令及响应。

比如，FTP 客户端位于NAT 所支持的私有网络中。FTP ALG 将被要求监视FTP 控制会话（对全部PORT 和PASV 模式）以确定FTP 数据会话端口号且修改私有地址和端口号为外部有效的地址和端口号。此外，序列和确认号、TCP 校验和、IP 分且长度和校验和必须被更新。因此该流的全部后序分组中的序列号必须被调整，TCP ACK 域和校验和也一样。

在极少情况下，该分组大小的增加可能引起它超过指定传输链路的MTU 。该分组这里将必须被分片，这可能会影响性能。或者，若该分组设置DF 位，则它将被ICMP 反射且发起主机这里半必须执行路径MTU 发现。这可能对性能有负而影响。

然而要注意，若控制命令通道是加密的，在命令交互中ALG 更新IP 地址将是不可能的。

当AUTH 与Kerberos 4 、Kerberos 5 和TLS 一同使用时，发生在X 终端/Telnet 上的同样问题也会发生在FTP 上。

最后，有必有提醒RFC 2428（FTP 对IPv6 和NAT 的扩展）的4 节描述新FTP 端口命令（EPSV ALL）如何可以用于允许NAT 设备快速跟踪FTP 协议，排除通过ALG 的进一步处理， 若远端服务器接受“EPSV ALL”。

4.2 RSVP

RSVP 位于协议栈中的传输层，运行于IP（IPv4 或IPv6 之一）上面。然而，不像其它传输层协议，RSVP 不传输应用层数据，而代之行为如其它因特网控制协议（例如，ICMP、IGMP、路由协议）。RSVP 消息在可RSVP 路由器间一跳一跳的发送，原始IP 数据报使用协议号46。显然原始IP 数据报应用在终端系统和最前（或最后）一跳路由器间被使用。然而， 这可能不是始终可能的， 因为并非所有系统可以操作原始网络I/O。因为这点，可以为终端系统通迅将RSVP 消息封装在UDP 数据报内。UDP 封装的RSVP 消息被发送到端口1698（若由终端系统发送）或端口1699（若由允许RSVP 的路由器）。关于RSVP 消息的UDP 封装的更多信息；参考RFC 2205 的附录C。

RSVP 会话、有特殊目标和传输层协议的数据流， 被定义为：

目标地址—— 数据分组的目标IP 地址。这可以是单播或多播地址。

协议ID——IP 协议ID（例如，UDP 或TCP）。

目标端口——通用目标端口，用于IP 层上层多路分解。

NAT 设备会表现出独特的问题， 当它开始支持RSVP 时。2 个问题是：

1、RSVP 消息对象可能包含IP 地址。其结果是RSVP-ALG 必须能够基于该消息的方向和类型来替换IP 地址。例如，若外部发送方将发送RSVP 路径消息给内部接收方，该RSVP 会话将指定某个IP 地址，外部发送方认为它是内部接收方的IP 地址。然而，当RSVP 路径消息到达NAT 设备时，RSVP 会话必须被修正以反映接收方在内部所使用的IP 地址。同样操作必须对包含IP 地址的所有消息对象进行。

2、RSVP 提供某种手段，RSVP 完整性对像，来保证RSVP 消息的完整性。该问题是因为第一点，NAT 设备必须能够修改RSVP 消息内的IP 地址。然而，当这完成时，RSVP 完整性对象就不再有效，因RSVP 消息已经被修改。因此RSVP-ALG 将不会工作，当RSVP 完整性对象被使用时。

4.3 DNS

DNS 是基于TCP/UDP 的协议。域名对主机使用在NAT 私有域中的本地DNS 服务器是个问题。DNS 域名到私有域内主机的地址映射应该被配置到私有域内的认证域名服务器上。该服务器将因域名解析而被外部访问且内部主机一样。DNS-ALG 将被要求执行对DNS 查询和响应地址到域名转化。[DNS-ALG] 详细描述DNS-ALG 。若DNS 分组是经DNSSEC 加密的/认证的，这里DNS-ALG 将失败，因它不能执行负载修正。

使用DNS 解析器来解析DNS 域名为IP 地址的应用，假设分配给应用特定会话来重用的地址可用。因此，DNS-ALG 将被要求在预先配置周期内维持地址分配（有私有和外部地址间） 有效，直到DNS 查询完成。

另一种方式，若私有域内不需要域名服务器，私有域主机可以为外部域名查询简单地指向外部域名服务器。当域名服务器位于外部域时不要求ALG。

4.4 SMTP

SMTP 是基于TCP 的协议（[SMTP]），被因特网邮件程序如sendmail 所使用以发送基于TCP 的邮件消息到众所周知端口25。邮件服务器可以位于私有域内部或外部。然而，服务器必须被分配一个全局域名和地址，对外部主机可访问。当邮件服务器位于私有域内时，向内SMTP 会话必须从它外部已分配地址重定向到该私有主机。没有特殊映射被要求，当邮件服务器位于外部域时。

一般而言，邮件系统被这样配置， 所有用户指定单个集中地址（如[email protected]），而不是包括单独主机（如[email protected] ）。该集中地址必须在可被外部主机访问的DNS 域名服务器中指定一个MX 记录。

在大多数情况下，邮件消息不包含对私有IP 地址的引用或用对外部不可见的名称链接的内容数据。然而，某些邮件消息确实包含MTA 的IP 地址，它们在“Received: ”域中接力该消息。某些邮件消息为调试用途或因缺少DNS 记录而使用IP 地址来代替FQDN，在“Mail From: ”域中。

若一个或更多MTA 位于私有域的NAT 之后，且邮件消息没有用签名或密码密匙加密，则SMTP-ALG 可以用于转换MTA 所注册的IP 地址信息。若MTA 有静态地址映射，则该转换将可长期跨域有效。

跟踪邮件路由的能力可能会由NAT 独自防碍或阻止，离开ALG。这可能会引起问题当调试邮件问题或下向跟踪邮件的滥用用户时。

4.5 SIP

SIP（参考[SIP]）可以运行于TCP 或UDP 上，但缺省在相同端口5060 上。

当使用UDP 时，SIP 请求的响应不走向请求来到的源端口。正确的是SIP 消息中包含响应该被送到的端口号。SIP 在对请求传输的响应中利用ICMP 端口不可达错误。请求消息通常被发送到连接的套接口上。若响应发送到请求中的源端口，每个处理请求的线程将必须监听它发送请求的套接口。然而，通过允许响应到达单个端口，单个线程可以代之为监听被使用。

服务器可能选择在消息中放入每个已连接套接口的源端口。这里每个线程可以独自监听响应。因响应的端口号可能不走向请求的源端口，SIP 将不会正常通过NAT，且将要求SIP-ALG。

SIP 消息挟带武断内容，由某个MIME 类型所定义。对于多媒体会话，这通常是会话描述协议（SDP RFC 2327 ）。SDP 可能规定IP 地址或端口被用于交换多媒体。当通过NAT 时这些可能会失去意义。因此SIP-ALG 将需要智能地解释和转换域相关信息。

SIP 挟带URL 在其Contact 、To 和From 域中，它们规定发信号地址。这些URL 可能在UL 的主机端口部分包含IP 地址或域名。一旦它们通过NAT 时，这些可能不再有效。

作为对SIP-ALG 的替代方案，SIP 支持代理服务器， 它可以与NAT 共同驻留，且运行在全局有意义的NAT 端口上。这种代理将有本地规定配置。

4.6 RealAudio

在缺省模式中，RealAudio 客户端（比如，在私有域中）访问TCP 端口7070 以发起与real-audio 服务器（比如，位于外部域）的会话， 且在回放期间（如：暂停或停止音频流） 交换控制消息。音频会话参数按字节流被嵌入到TCP 控制会话中。

实际音频流量在反向向内指向范围6970-7170 内端口的基于UDP 的分组中挟带（源自服务器）。

因此，缺省时RealAudio 在传统NAT 设备中被破坏。对这的相关工作将是用ALG 检查TCP 通信量以判断该音频会话参数并有选择地在TCP控制会话中取得一致的端口上允许向内的UDP 会话。作为替代方案，ALG 可以简单重定向全部向内UDP 会话直到到私有域内的客户端地址的端口6970-7170 。

对于双向NAT，你将不需要ALG 。双向NAT 将可简单对待每个TCP 和UDP 会话为2 个不相关会话，且执行IP 和TCP/UDP 头部级转换。

读者可联系RealNetworks 以取得关于如何使它们的应用通过NAT 和防火墙设备可工作的详细指南。

4.7 H.323

H.323 是复杂的，使用动态端口，且包括多个UDP 流。这里是对相关问题的总结：

H.323 呼叫由许多不同的同时连接组成。至少2 个连接是TCP。对于只是音频的会议，这里可能最多由4 个不同的UDP“连接”组成。

所有连接除一个外都指向临时（动态）端口。

呼叫可以从私有域发起，外部域一样。对会议有用，外部用户需要能够直接与内部用户的桌面系统建立呼叫。

地址和端口在“下个更大的”连接的数据流内交换。例如。H.245 连接的端口号在Q.931 数据流内建立。（这使得它对ALG 特别困难， 要求该ALG 修改这些数据流内的地址。）使事情更糟的是，Q.931，例如，还可以指定该H.245 连接应该是安全的（被加密）。若会话被加密， ALG 将不可能解释该数据流，除非它可获得共享密匙。

多数控制信息都以ASN.1 编码（只有Q.931 协议数据单元，或PDU，内的用户——用户信息是用ASN.1 编码的，每个Q.931 PDU 的其它部分都没有编码）。对于不熟悉ASN.1 的人而言，它足够使其说它是个复杂的编码方案，它的地址信息不以固定字节偏移结束。实际上， 连接到同个目标的同个应用的同个版本可以协商包括不同的选项，将修改字节偏移。

下面是在用户A 和用户B 间的典型H.323 呼叫的协议交换。A 的IP 地址是88.88.88.88 且B 的IP 地址是99.99.99.99 。要注意，在RTP 分组负载中的Q.931 和H.245 消息被编码为ASN.1。因此要通过NAT 设备完成连接，H.323-ALG 将被要求检查该分组，解码ASN.1， 且转换不同的H.323 控制IP 地址。

用户A 用户B

建立连接到B 的众所周知的Q.931 端口（1720）

-----------------------------------------------&gt;

Q.931 设置呼叫者地址 = 88.88.88.88

呼叫者端口 = 1120

被叫者地址 = 99.99.99.99

被叫者端口 = 1720

<-----------------------------------------------

Q.931 提醒

&lt;-----------------------------------------------

Q.931 连接 H.245 地址 = 99.99.99.99

H.245 端口 = 1092

用户A 建立连接到99.99.99.99 ，端口1092 的用户B

&lt;---------------------------------------------->

几个H.245 消息被交换（终端能力集、主次决定和它们各

自的ACK）

<-----------------------------------------------

H.245 打开逻辑通道，通道= 257

RTCP 地址 = 99.99.99.99

RTCP 端口 = 1093

----------------------------------------------->

H.245 打开逻辑通道确认，通道 = 257

RTP 地址 = 88.88.88.88 RTP 端口 = 2002 （这是用户A 愿意RTP 数据发送的地址） RTCP 地址 = 88.88.88.88 RTCP 端口 = 2003

-----------------------------------------------&gt;

H.245 打开逻辑通道，通道= 257

RTCP 地址 = 88.88.88.88

RTCP 端口 = 2003

&lt;-----------------------------------------------

H.245 打开逻辑通道确认，通道 = 257

RTP 地址 = 99.99.99.99

RTP 端口 = 1092

（这是用户B 愿意RTP 数据发送的地址）

RTCP 地址 = 99.99.99.99

RTP 端口 = 1093

还要注意，若H.232 网关驻留在NAT 边界内，则ALG 将必须识别各种网关发现方案且同时适应这些方案。或者若只有H.323 主机/终端在NAT 边界内，且尝试向网关注册，则在该注册消息中的IP 信息将必须被NAT 转换。

4.8 SNMP

SNMP 是基于UDP 的网络管理协议。SNMP 负载可能包含IP 地址或可能引用通过索引表的IP 地址。因此，当私有网络中的设备被外部结点管理时，传过NAT 设备的SNMP 分组可能包含与外部域不相关的信息。在某些情况下，如[SNMP-ALG] 所述，SNMP ALG 可能用于透明转换域特定地址为全局唯一地址。这种ALG 假设静态地址映射和双向NAT。它只能对SNMP-ALG 实现可理解的数据类型集（ 文本化约定）和对特定MIB 模块集有效。进而，替换SNMP 负载中的IP 地址可造成通迅失败，因消息大小的改变或词典顺序的改变。

使用SNMP ALG 对所有管理应用完全透明是不可完成的任务。使用SNMPv3 安全特性时这些ALG 将出现问题，当认证（ 和可选保密性）被允许时，除非ALG 可获得安全密匙。[NAT-ARCH] 还提示跨NAT 使用SNMP 管理的潜在问题。

另一种方案，SNMP 代理，如[SNMP-APPL] 所定义，可以与NAT 联合使用以转发SNMP 消息给外部SNMP 引擎（且反之亦然）。SNMP 代理按私有域内容被裁剪且因此可单独操作被访问的特别管理对象类型。这种代理解决方案将要求外部管理应用清楚该代理转发者且被管理的个别结点将需要配置为定向它们的SNMP 通信量（通告和请求）到该代理转发者。

5.0 明确设计与NAT 终端路由协同工作的协议

5.1 Activision 游戏

Activision 游戏被设计与NAT 友好，以不至于要求ALG 来辅助游戏透明地跨传统NAT 设备工作。私有域内的游戏玩家可以与相同域或外部域中的其它玩家一起玩。Activision 游戏协议是私有的且基于UDP。寻址服务器使用UDP 端口号21157 且希望位于全局地址域中。

游戏玩家首先连接到该寻址服务器，且在初始连接消息中发送它们的私有IP 地址信息（如私有IP 地址和UDP 端口号）。该服务器记住来自该连接消息的私有地址信息和来自IP 和UDP 头部的外部地址住处。这里该服务器发送该玩家的私有和外部地址信息给所有其它结点的玩家。在这时，每个游戏玩家都知道每个其它结点的私有和公共地址信息。在这之后， 每个客户端相互间打开对称直接连接并使用首先可工作的地址（私有或外部）。

现在，客户端能够有会话直接与其它客户端（或）它们可以通过游戏服务器与其它客户端会话。关键是允许重用用于发起连接到游戏服务器的相同的（全局地址、已分配UDP 端口） 对给到该客户端的全部后序连接。游戏玩家通过（私有地址、UDP 端口）或（全局地址、已分配UDP 端口）之一来被所有其它结点玩家识别。因此，在这些对之间的绑定应该在NAT 中保持不变，只要该游戏玩家在与某个或多个其它玩家的会话中。

从私有主机打开连接到外部域中的游戏服务器没有问题。所有NAT 必须做的就是提供路由透明度且保持同个私有到外部地址绑定只要存在至少一个与外部结点的游戏会话。但是， NAPT 配置必须允许多个同时UDP 连接到同个已分配全局地址/端口。

上面的方法有些问题。例如，客户端可能尝试联系私有地址，但该私有地址可能正被本地所使用，当该私有地址在某些其它域中有意义时。若错误联系的结点有一些其它服务或没有服务注册到该UDP 端口，则该Activision 连接消息将期望被简单地丢弃。在不大可能的事件中，已注册应用选择解释该消息，则其结果可能是不可预测的。

读者可以参考Activision 的所有权，关于该协议的功能和设计的详细信息

本篇文章来源于 中国协议分析网|www. 原文链接：http://www./Class/NAT/200809/10-22982.html