此文章发布于3个月前,其中某些内容可能过时,或与作者现时状况、观点不同。
RFC 3235 阅读摘要

原文信息

RFC 3235
Network Address Translator (NAT)-Friendly Application Design Guidelines
D. Senie, Amaranth Networks Inc., January 2002

Abstract

本文是信息性INFORMATIONAL文档,是为了给互联网社区提供信息,而非定义互联网标准。

本文讨论了应用设计者在设计新协议时可能会考虑的问题,虽然很多互联网应用对于NATNetwork Address Translator的支持都很清楚系,但有也有一些深陷泥潭,所以本文就是为了帮助解决与NAT的兼容问题而诞生的。

Introduction

本段指出,当协议无法通过NAT的时候,ALGApplication Level Gateway不失为一种解决方法,不过有时候也可能会很困难或者根本行不通,更何况ALGs不应该用于大量运算。

另外,NAT上如果有问题(就算用了ALG支持),多半防火墙firewalls也会有问题,这将导致应用部署deploy的困难,所以,应用设计者应该注意本文提到的问题。

Discussion

本段首先介绍了NAT的广泛使用(主要是家庭和小型办公室)然后指出NAT上最大的问题是正确递交数据addressing data between stations,并可以通过学习其他现存协议的解决方案。

然后列举了两种常见的NAT形式,分别是基础NATBasic NAT和NAPTNetwork Address Port Translation,前者即每个内网地址一一对应公网地址,后者则是把多个内网地址的不同端口对应到一个公网地址不同端口上。

因此,NAPT的兼容性要更难做,但是NAPT的使用更广,所以应用开发者最好还是兼容它。

Recommendations and Examples

本段是文字的核心内容,列出了许多建议和例子,并再次提醒了ALG会影响应用的部署因此最好还是不要用ALG,直接通过这些做法解决。

影响全类型 NAT 的问题和对应建议

  • Peer-to-Peer Applications Limitations
    本段指出P2P在NAT世界是一大难题。(1)基础NAT配合静态地址分配比NAPT使用P2P的可能性大得多。(2)根据不同厂商,某些基于UDP的P2P应用可能在特定NAT实现implementations下可以工作。(3)如果NAT硬件支持,则有可能建立一个UDP通道channel专门放流入站流量incoming traffic,以规避IP问题。(4)NAT通常和防护墙机能同时实现,不过许多硬件支持用户调整防护墙安全级别。
  • Applications Requiring End-to-End IPSec Will Fail
    现有NAT实现不支持端对端的IPSec安全策略,请使用TLS或参见关于在相同硬件上使用隧道模式Tunnel-modeIPSec的讨论。
  • Use DNS Names, Not IP Addresses In Payload
    要使用DNS名称,而非192.168.1.10这样的地址,因为IP可能在不同的网域下指向不同的服务器(或不可用)。
  • Multicast Considerations
    使用多拨的应用应该先检查兼容性,因为不是所有NAT硬件都支持。
  • Retention Of Address Mapping
    不应该依赖于地址映射,因为NAT没有义务要一直保持某硬件与某IP地址的关系。均衡负载这样的服务则可能是同一个IP后面有多个终端。

针对 NAPT 的建议

  • IP Addresses Specific To A Realm
    避免在数据payload of packets中直接使用IP地址和端口号,虽然通过ALGs或许可以工作,但过时的NAT硬件不一定支持。
  • Avoid Session Bundles
    要避免会话包session bundles即一系列会话(连接),比如FTP中第一个连接发送文件信息,第二个连接才发送文件内容。应该把它们整合为一个会话,这样可以节省资源。
  • Session Bundles Originate From Same End
    在无法避免使用会话包的时候,请确保包内的每一个会话是从同一终端站点end station发出。
  • Choice of Transport Protocol
    NAT对于TCP的策略分为两种,计时器Timer和终始包SYN and FIN packets,而对于UDP就只有计时器一种,不过有的坑也会只使用计时器一种方式(即通过时间判断连接已经结束)
  • IP Fragmentation
    应该避免拆分包。假设有两个硬件同时在访问一个应用,甚至可能会出现分不清是谁的包的情况。

针对 Basic NAT 的建议

  • Use IP and TCP/UDP Headers Alone
    不要放附加的定位信息addressing information到包内,这样可以保持简单和共识,从而减少问题。
  • Avoid Addressing In Payload
    还是不要在包内附加信息,因为某地址不一定在所有网域都一致。

Bi-directional NAT

使用DNS名称映射定位私有域内服务器的一种方案。

Twice NAT

同时修改源source和目标destinationIP的一种方案,用于两个私有网域定位冲突。

Multi-homed NAT

使用多台NAT设备提供冗余,以防止故障的方案,需要多个实现拥有相同的外部地址。

Realm Specific IP (RSIP)

使用领域专有IP以区分公网和内网地址。

地址转换的性能影响

本段讨论了NAT网关的性能问题。

Security Consideration

本段再次提醒应用在NAT下时IPSec会出问题,安全方面应该用TLS。

  Comment
  • 您正在回复给 Poi