NAT的優點不必多講,它提供了一系列相關技術來實現多個內網用戶通過一個公網ip和外部通信,有效的解決了ipv4地址不夠用的問題.那么位于NAT后 的用戶使用私網ip真的和使用公網ip一樣嗎?NAT解決了所有地址轉換的相關問題了嗎?
下面主要講一些NAT不支持的方面,以及所謂的NAT 的"缺陷".

一些應用層協議(如TCP和SIP),在它們的應用層數據中需要包含公網IP地址.拿FTP來說吧,眾所周知,FTP是通過 兩個不同的連接來傳輸控制報文和數據報文的.當傳輸一個文件時,FTP服務器要求通過控制報文得到即將傳輸的數據報文的網絡層和傳輸層地址 (IP/PORT).如果這個時候客戶主機是在NAT之后的,那么服務器端收到的ip/port將會是NAT轉化前的私網IP地址,從而會導致文件傳輸失 效.
SIP(Session Initiation Protocol)主要是來控制音頻傳輸的,這個協議也面臨同樣的問題.因為SIP建立連接時,需要用到幾個不同的端口來通過RTP傳輸音頻流.而且這些 端口以及IP會被編碼到音頻流中,傳輸給服務器端,從而實現后續的通信.
如果沒有一些特殊的技術(如STUN),那么NAT是不支持這些協議的, 這些協議經過NAT也肯定會失敗.
Some Application Layer protocols (such as FTP and SIP) send explicit network addresses within their application data. FTP in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its network layer and transport layer addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address and/or TCP port number makes the information received by the server invalid. The Session Initiation Protocol (SIP) controls Voice over IP (VoIP) communications and suffers the same problem. SIP may use multiple ports to set up a connection and transmit voice stream via RTP. IP addresses and port numbers are encoded in the payload data and must be known prior to the traversal of NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and communications may fail.

下 面講一些特殊的技術,來使NAT支持這些特殊的應用層協議.

最直觀的想法就是:既然NAT修改了IP/PROT,那么我們也修改應用層數 據中相應的IP/PORT.應用層網關(ALG)(硬件或軟件都行)就是這樣來解決這個問題的.應用層網關運行在設置了NAT的防火墻設備中,它會更新傳 輸數據中的IP/PORT.所以,應用層網關也必須能夠解析應用層協議,而且對于每一種協議,可能需要不同的應用層網關來做.
Application Layer Gateway (ALG) software or hardware may correct these problems. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs obviously need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG.

另外一個解決此問題的辦法就是NAT穿透.此方法主要利用STUN或 ICE等協議或者一些和會話控制相關的特有的方法來實現.理論上NAT穿透最好能夠同時適用于基于TCP和基于UDP的應用,但是基于UDP的應用相對比 較簡單,更廣為流傳,也更適合兼容一些種類的NAT做穿透.這樣,應用層協議在設計的時候,必須考慮到可支持NAT穿透.但一些其他類型的NAT(比如對 稱NAT)是無論如何也不能做穿透的.
Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or ICE or proprietary approaches in a session border controller. NAT traversal is possible in both TCP- and UDP-based applications, but the UDP-based technique is simpler, more widely understood, and more compatible with legacy NATs. In either case, the high level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly-behaved legacy NATs.


還有一些方法,比如UPnP (Universal Plug and Play) 或 Bonjour (NAT-PMP),但是這些方法都需要專門的NAT設備.
Other possibilities are UPnP (Universal Plug and Play) or Bonjour (NAT-PMP), but these require the cooperation of the NAT device.


大部分傳統的客戶-服務器協議(除了FTP),都不定義3層以上的數據格 式,所以,也就可以和傳統的NAT兼容.實際上,在設計應用層協議的時候應盡量避免涉及到3層以上的數據,因為這樣會使它兼容NAT時復雜化.
Most traditional client-server protocols (FTP being the main exception), however, do not send layer 3 contact information and therefore do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.


NAT也會和利用ipsec加密的一些應用沖突.比如SIP電話,如果有很多SIP電話設備在 NA(P)T之后,那么在電話利用ipsc加密它們的信號時,如果也加密了port信息,那么這就意味著NAPT就不能轉換port,只能轉換IP.但是 這樣就會導致回來的數據包都被NAT到同一個客戶端,從而導致通信失敗(不太明白).不過,這個問題有很多方法來解決,比如用TLS.TLS是運行在第四 層(OSI模型)的,所以它不包含port信息.也可以在UDP之內來封裝ipsec,TISPAN 就是用這種方法來實現安全NAT轉化的.
NATs can also cause problems where IPsec encryption is applied and in cases where multiple devices such as SIP phones are located behind a NAT. Phones which encrypt their signaling with IPsec encapsulate the port information within the IPsec packet meaning that NA(P)T devices cannot access and translate the port. In these cases the NA(P)T devices revert to simple NAT operation. This means that all traffic returning to the NAT will be mapped onto one client causing the service to fail. There are a couple of solutions to this problem, one is to use TLS which operates at level 4 in the OSI Reference Model and therefore does not mask the port number, or to Encapsulate the IPsec within UDP - the latter being the solution chosen by TISPAN to achieve secure NAT traversal.


Dan Kaminsky 在2008年的時候提出NAPT還會間接的影響DNS協議的健壯性,為了避免DNS服務器緩存中毒,在NA(p)T防火墻之后的DNS服務器最好不要轉換 來自外部的DNS請求(UDP)的源端口.而對DNS緩存中毒攻擊的應對措施就是使所有的DNS服務器用隨機的端口來接收DNS請求.但如果NA(P)T 使DNS請求的源端口也隨機化,那么在NA(P)T防火墻后面的DNS服務器還是會崩潰的.
The DNS protocol vulnerability announced by Dan Kaminsky on 2008 July 8 is indirectly affected by NAT port mapping. To avoid DNS server cache poisoning, it is highly desirable to not translate UDP source port numbers of outgoing DNS requests from any DNS server which is behind a firewall which implements NAT. The recommended work-around for the DNS vulnerability is to make all caching DNS servers use randomized UDP source ports. If the NAT function de-randomizes the UDP source ports, the DNS server will be made vulnerable.

位 于NAT后的主機不能實現真的端對端的通信,也不能使用一些和NAT沖突的internat協議.而且從外部發起的TCP連接和一些無狀態的協議(利用 udp的上層協議)也不能正常的進行,除非NAT所在設備通過相關技術支持這些協議.一些協議能夠利用應用層網關或其他技術,來使只有一端處于NAT后的 通信雙方正常通信.但要是雙方都在NAT后就會失敗.NAT也和一些隧道協議(如ipsec)沖突,因為NAT會修改ip或port,從而會使協議的完整 性校驗失敗.
Hosts behind NAT-enabled routers do not have end-to-end connectivity and cannot participate in some Internet protocols. Services that require the initiation of TCP connections from the outside network, or stateless protocols such as those using UDP, can be disrupted. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination. Some protocols can accommodate one instance of NAT between participating hosts ("passive mode" FTP, for example), sometimes with the assistance of an application-level gateway (see below), but fail when both systems are separated from the Internet by NAT. Use of NAT also complicates tunneling protocols such as IPsec because NAT modifies values in the headers which interfere with the integrity checks done by IPsec and other tunneling protocols.


端對端的連接是 internet設計時的一個重要的核心的基本原則.而NAT是違背這一原則的,但是NAT在設計的時候也充分地考慮到了這些問題.現在基于ipv6的 NAT已經被廣泛關注,但許多ipv6架構設計者認為ipv6應該摒棄NAT.
End-to-end connectivity has been a core principle of the Internet, supported for example by the Internet Architecture Board. Current Internet architectural documents observe that NAT is a violation of the End-to-End Principle, but that NAT does have a valid role in careful design. There is considerably more concern with the use of IPv6 NAT, and many IPv6 architects believe IPv6 was intended to remove the need for NAT.


由于NAT的連接追蹤具有短時效性.所以在特定的地址轉換關系會在一小段時間后失效, 除非遵守NAT的keep-alive機制,內網主機不時的去訪問外部主機.這至少會造成一些不必要的消耗,比如消耗手持設備的電量.
Because of the short-lived nature of the stateful translation tables in NAT routers, devices on the internal network lose IP connectivity typically within a very short period of time unless they implement NAT keep-alive mechanisms by frequently accessing outside hosts. This dramatically shortens the power reserves on battery-operated hand-held devices and has thwarted more widespread deployment of such IP-native Internet-enabled devices.


一些IPS會直接提供給用戶私網IP地址,這樣用戶就必須通過IPS的 NAT來和外部INTERNET通信.這樣,用戶實際上沒有實現端對端通信,中間加了一個IPS的NAT,這有悖于Internet Architecture Board列出的internal核心基本原則.
Some Internet service providers (ISPs) provide their customers only with "local" IP addresses.[citation needed]Thus, these customers must access services external to the ISP's network through NAT. As a result, the customers cannot achieve true end-to-end connectivity, in violation of the core principles of the Internet as laid out by the Internet Architecture Board.

NAT 最后的一個缺陷就是:NAT的推廣和使用,解決了ipv4下IP地址不夠用的問題,大大的推遲了IPV6的發展.
(說它是優點好呢,還是缺陷好 呢?)
it is possible that its [NAT] widespread use will significantly delay the need to deploy IPv6

Reference:
Network address translation

from:
http://blog.chinaunix.net/u2/86590/showart.php?id=2208148