NAT主流穿越技术

转载：http://www.rosoo.net/a/201103/11129.html

1. ALG（Application Level Gateway）

在NAT/Firewall上加入能够对于具体应用协议（如H.323）感知的模块，通过对于具体应用协议 的感知，进行针对不同协议的具体NAT/Firewall穿越处理。对于每一种应用协议都需要一个ALG实例（Instance）来支持。H.323需要 一个，SIP需要一个，H.248需要一个，如此等等。因此每增加一种新的协议，或者现有协议修改了，都需要一个新的ALG来支持。因此这种机制在实际应 用中复杂度高，可扩展性差，受到很大限制。

2. MIDCOM类机制

这是一大类方法，因其中非常典型的一种采用了 IETF的MIDCOM（MIDdlebox COMmunication）协议而得名。该类方法的共同特点是需要一个辅助设备（当然可以做在NAT/Firewall上）来支持。该设备对于具体的应 用协议是感知的，了解其具体的穿越需求。该设备通过一种通信协议来请求/控制NAT/Firewall，创建特定的地址/端口绑定关系或者打开特定端口允 许该应用协议的数据流通过。但是并非所有的NAT/Firewall都能够支持某种类似MIDCOM的请求/控制协议，因此这类技术在实际中的应用也受到 一定的局限。

3． 基于隧道的穿越

通过把需要穿越的数据流封装在某种隧道中，从而绕过NAT/Firewall，这是基 于隧道穿越的基本思想。可以考虑的隧道协议有L2TP、IPSEC、HTTP、UDP和TCP等。因为经过隧道封装的数据流在通过 NAT/Firewall的时候，在通信双方之间，都通过特定的隧道协议的端口，而不是原来数据流协议的端口。那么不论原来的应用协议是什么，只要隧道协 议能够正常穿越过NAT/Firewall，就能完成任何应用协议的穿越。这样在很大程度上解决了对于不同应用协议需要开发不同穿越策略的办法。但是隧道 机制需要多媒体终端和服务器能够支持隧道，这是一个比较大的限制条件。目前，通过提供集中式的功能实体在私网和公网侧分别提供隧道功能，是可以解决这个问 题的。隧道机制也会导致潜在的安全问题，因为被封装的数据是安全检查机制所不可见的，因此会引发一定的安全风险。需要某种机制保证通信终端和服务器的可信 性。

4． 基于终端的穿越

这是一个不太合适的名称（借用自ETSI/TISPAN标准组织的文稿），但是对于这类技术目 前并没有更好的名称。这类方法利用STUN和TURN或者类似的私有协议，由私网上的终端来获得关于穿越需要的信息并且实现某种协议的穿越：终端可以通过 STUN协议发现自己是否位于NAT/Firewall后面，并且发现NAT为它绑定的公网地址/端口。同时通过使用TURN协议来接收来自公网的TCP 和UDP数据。对于接收终端位于对称NAT/Firewall后的情况，TURN也能正确穿越。通过“反转”机制，可以把发送终端转变成接收终端，从而使 发送终端即便位于对称NAT/Firewall后的情况也能够实现穿越。并且可以不降低对称NAT/Firewall所提供的强安全性。

在 实际中，STUN和TURN可以和很多类型的NAT/Firewall配合实现穿越。因此得到了比较广泛的使用。类似的机制经过进一步发展和提高，穿越能 力和适用广泛性会更好。目前非常流行的VoIP软件Skype很可能就使用了类似的机制。

需要说明的事，对于STUN和TURN都需要有 对应服务器的支持，即分别需要STUN和TURN服务器。

5． 基于穿越代理的穿越

代理本质上是一种“反射” （Reflector）机制。对于数据流的发送端，代理就是接收端；对于数据流的接收端，代理就是发送端。采用代理，就可以把来自多个终端，本来需要发送 到另外多个终端/服务器的数据流发送到某个给定的IP地址和相应的知名端口，便于NAT/Firewall进行地址/端口绑定，同时也为NAT /Firewall对于地址/端口的管理提供了很大的方便。代理的使用将穿越问题大大简化。比较适合大规模的公众视讯/VoIP业务。运营商可以在公网上 部署一个功能强大的穿越代理，从而为很多私网中的终端/服务器提供穿越的支持。

需要说明的是，以上介绍的多种技术可以结合起来使用，达到 更好的穿越效果。比如代理可以和隧道机制结合，也可以和修改协议的方法结合。

6． 基于修改协议的穿越

在终端和服务器上 的协议栈进行必要的协议修改，比如H.323协议的修改，也可以支持穿越。修改协议的主要问题是需要现有终端和网络设备比如Gatekeeper等进行改 动和升级。