NAT的四種類型
基於UDP的P2P應用需要考慮NAT的類型，因為不同的NAT組合的穿透的方式並不一致，有的能通， 有的不能通。
一般來講， NAT可以分為四種類型，分別是:
- 全錐型(Full Cone)
- 受限錐型(Restricted Cone)， 或者說是IP受限錐型
- 端口受限錐型(Port Restricted Cone), 或者說是IP + PORT受限錐型
- 對稱型(Symmetric)
其中1,2,3屬於同一種類型，都是錐型，區別只是路由器的不同的安全策略。還有些NAT不屬於這四種中的任何一種，就不在本文的討論范圍了。
為什么有四種類型的NAT
NAT緩解了IPV4地址不夠用的問題，同時也也帶了限制，那就是NAT外部的主機無法主動跟位於NAT內部的主機通信，NAT內部主機想要通信，必須主動和公網的一個IP通信，路由器負責建立一個映射關系，從而實現數據的轉發， 這就是NAT的工作原理。
假定
公網server1 ip是1.1.1.1， 監聽端口是1111
公網server2 ip是2.2.2.2， 監聽端口是2222
NAT router ip是8.8.8.8
NAT內部client是192.168.0.3
client發送數據的時候，不管是tcp還是udp必須本地綁定一個端口，一般來講，這個過程都是自動的。
假定client(192.168.0.3, 100)給 server(1.1.1.1, 1111)發送報文，報文到達路由器，路由器在自己的公網ip上開辟一個端口800，從而建立了一個隱射關系(8.8.8.8, 800)<--->(192.168.0.3, 100), 建立映射關系后，所以(192.168.0.3, 100)和(1.1.1.1, 1111)之間的報文都通過這個映射關系進行轉發。
NAT之間主要的區別分兩種情況討論
1:client(192.168.0.3, 100)和server(1.1.1.1, 1111)在路由器上建立好映射關系后，如果client(192.168.0.3, 100)又給(2.2.2.2, 2222)發送數據，路由器該怎么處理呢?
1, 復用舊的映射關系(8.8.8.8, 800)<--->(192.168.0.3, 100)和(2.2.2.2, 2222)通信, 這就是錐型(Cone) NAT
2, 創建新的映射關系(8.8.8.8, 801)<--->(192.168.0.3, 100)和(2.2.2.2, 2222)通信, 這就是對稱型NAT
注: (8.8.8.8, 801)只是舉例，到底用什么端口取決於路由器的端口管理策略，總之是另外的一個端口，有的路由器有多個公網IP，不同的IP也會參與到這個映射關系中。
2:client(192.168.0.3, 100)和server(1.1.1.1, 1111)在路由器上建立好映射關系后，如果這個時候路由器(8.8.8.8)在800端口上收到從另外一台server(2.2.2.2, 2222)發來的數據，是不是應該轉發給(192.168.0.3, 100)呢？
有四種情況:
1, 無條件轉發給(192.168.0.3, 100)， 這就是全錐型(Full Cone)NAT。
2, 如果(192.168.0.3, 100)之前給(2.2.2.2)發送過數據，則轉發， 這就是受限錐型(Restricted Cone)。
3, 如果(192.168.0.3, 100)之前給(2.2.2.2, 2222)發送過數據，則轉發， 這就是端口受限錐型(Port Restricted Cone)。
4, 丟棄報文，拒絕轉發, 這就是對稱型NAT。
從上面也描述也可以看出，安全性系數, 對稱型 > 端口受限錐型 > 受限錐型 > 全錐型
不同NAT的穿透性
NAT有10種組合
| 全錐型 | 全錐型 | ✓ |
| 全錐型 | 受限錐型 | ✓ |
| 全錐型 | 端口受限錐型 | ✓ |
| 全錐型 | 對稱型 | ✓ |
| 受限錐型 | 受限錐型 | ✓ |
| 受限錐型 | 端口受限錐型 | ✓ |
| 受限錐型 | 對稱型 | ✓ |
| 端口受限錐型 | 端口受限錐型 | ✓ |
| 端口受限錐型 | 對稱型 | ✘, 無法打通 |
| 對稱型 | 對稱型 | ✘, 無法打通 |
FreeSWITCH幫助終端穿越NAT的解決方案：
SIP穿越
FreeSWITCH默認使用ACL來判斷對方是否處於NAT環境中，配置：
<param name="apply-nat-acl" value="nat.auto"/>
nat.auto是一個ACL，包含了RFC1918規定的私網地址，並去掉了本地網絡的地址。當SIP終端注冊時，通過比較contact地址是否包含在此ACL中來判定該終端是否處於
NAT背后，如果是那么它就把contact地址自動替換為SIP包的來源地址，后邊的呼叫就可以正常抵達。
RTP穿越
NAT環境的SIP終端SDP信息中的IP地址是私網地址，FreeSWITCH無法直接發送RTP包，而NAT設備基本都只允許內網主機曾經接觸過的外網主機發送的UDP數據包
進入。FreeSWITCH使用了一個名為RTP自動調整的特性，在SIP協商時給對方一個可用的公網RTP地址，然后等待客戶端發送RTP包，一旦FreeSWITCH收到RTP包后，
就可以根據對方發包的地址給它發RTP包了。此類情況發生時，Log中可看到類似信息：
[INFO] switch_rtp.c:4753 Auto Changeing port from 192.168.1.100:50496 to 1.2.3.4:50496
注意：此辦法存在安全性問題，如某黑客向隨機的RTP端口發數據包，FreeSWITCH收到后將遠端地址調整到黑客的IP和端口，進而RTP數據全部跑歪了。所以為了防止
這個問題，FreeSWITCH規定這種端口調整只能在電話開始的時候進行，且僅支持一次調整。
自動調整的功能默認是開啟的，可在Profile中禁用：
<param name="disable-rtp-auto-adjust" value="true"/>
或者僅針對個別的呼叫來禁用自動調整，在呼叫時設置通道變量"rtp_auto_adjust=false"來禁止。
SIP終端自己的解決方案
1、STUN服務
STUN的原理是：在公網上部署一個STUN服務器，位於NAT后面的客戶端設備向它發送一系列的UDP包先在NAT設備上“打洞”，STUN服務器取到UDP包的來源地址后，
回送相關的消息告訴該客戶端它被映射的外網地址。
大多數的SIP話機及軟電話均可以選擇是否啟用STUN服務。使用STUN后，SIP消息的contact頭域中就可以直接填入外網地址。
注意：STUN服務對於錐形NAT是有效的，但對於對稱型NAT就無能為力了。簡單講就是SIP終端從STUN服務學習到的IP及端口會失效，如果兩個SIP終端分別處於兩個
對稱型NAT之后，則它們是無法進行通信的。
2、ICE
綜合利用STUN和TURN（使用轉發方式進行穿越的NAT，主要用來解決對稱型NAT的問題，FreeSWITCH不支持該技術，但支持與TURN的SIP客戶端配合工作）等技術，
使之在最合適的情況下工作。比如，如果兩個SIP終端處於相同的NAT后面，則他們可以直接用內網地址進行通信；如果位於不同的NAT后面，並且是錐型NAT，則選擇從
STUN服務器獲得外網地址進行通信；如果是對稱型NAT，則只能通過TURN來通信。
FreeSWITCH處於NAT后面的解決方案
1、uPnp
FreeSWITCH支持通過uPnP或NAT-PMP協議在路由器上“打洞”，打洞完成后就知道自己將要映射的外網地址了，前提是路由器支持uPnp功能並開通。FreeSWITCH
檢測到NAT以后，設置Profile的外網SIP和RTP的IP，通過命令 freeswitch@sword>sofia status profile external 可查詢Ext-SIP-IP和Ext-RTP-IP的值。
自動檢測NAT的配置在external.xml中：
<param name="ext-rtp-ip" value="auto-nat"/>
<param name="ext-sip-ip" value="auto-nat"/>
2、STUN服務
如果路由器不支持uPnp及NAT-PMP協議，那么可將上述配置改為：
<param name="ext-rtp-ip" value="stun:stunserver.org"/>
<param name="ext-sip-ip" value="stun:stunserver.org"/>
使用命令 freeswitch>stun stunserver.org 可檢測該服務是否有效。
3、手動設置
手動找出路由器的外網IP地址后，以下兩種方法都可設置：
<param name="ext-sip-ip" value="autonat:1.2.3.4"/>
<param name="ext-rtp-ip" value="autonat:1.2.3.4"/>
或者
<param name="ext-sip-ip" value="1.2.3.4"/>
<param name="ext-rtp-ip" value="1.2.3.4"/>
4、DNS服務器
部署DNS服務器，如host:sip.sword.com，通過域名解析獲得外網的IP地址。
此方法的好處是，外網和內網的SIP終端用戶都可以通過域名注冊，如果有移動辦公的用戶，就不用經常更換內網地址或外網地址注冊了。
原文地址：
http://www.360doc.com/content/15/1222/16/15077656_522312189.shtml