【轉】asterisk的NAT配置

?? http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html

這篇文章已經(jīng)把該說的都說了，能理解多少是多少！

?

1. sip.conf:

Externip:在[general] context配置的屬性，配置你的公網(wǎng)地址，這樣發(fā)送sip消息時就會用該地址替換消息頭的主機地址，對端解析消息后就會往這個地址發(fā)送應答消息。

Nat：該屬性決定asterisk如何處理用戶的連接。個人理解就是配置astersik處理收到消息的方式。

a） nat=route

asterisk 從收到的rtp包得到目地地址，把rtp包發(fā)往該地址而不是SDP中協(xié)商的每媒體地址。

b） nat=no

默認配置，根據(jù)rfc3581，asterisk會把rport和received字段添加到via域，作為應答接受地址。

http://hi.baidu.com/caoyaping/blog/item/18f15c6e724e6fd781cb4ad8.html

c） nat=never

asterisk不把rport加入via域，也不會按照route的方式處理。？

d） nat=yes

======================================轉一篇關于nat的文章，原地址打不開了==============

STUN是RFC3489規(guī)定的一種NAT穿透方式，它采用輔助的方法探測NAT的IP和端口。毫無疑問的，它對穿越早期的NAT起了巨大的作用，并且還 將繼續(xù)在ANT穿透中占有一席之地。

STUN的探測過程需要有一個公網(wǎng)IP的STUN server，在NAT后面的UAC必須和此server配合，互相之間發(fā)送若干個UDP數(shù)據(jù)包。UDP包中包含有UAC需要了解的信息，比如NAT外網(wǎng) IP，PORT等等。UAC通過是否得到這個UDP包和包中的數(shù)據(jù)判斷自己的NAT類型。

假設有如下UAC（B），NAT（A），SERVER（C），UAC的IP為IPB，NAT的IP為 IPA ，SERVER的 IP為IPC1 、IPC2。請注意，服務器C有兩個IP，后面你會理解為什么需要兩個IP。?

（1）NAT的探測過程：

STEP1：B向C的IP1的pot1端口發(fā)送一個UDP 包。C收到這個包后，會把它收到包的源IP和port寫到UDP包中，然后把此包通過IP1和port1發(fā)還給B。這個IP和port也就是NAT的外網(wǎng) IP和port（如果你不理解，那么請你去看我的BLOG里面的NAT的原理和分類），也就是說你在STEP1中就得到了NAT的外網(wǎng)IP。

?熟悉NAT工作原理的朋友可以知道，C返回給B的這個UDP包B一定收到（如果你不知道，去讀下我的其它文章）。如果在你的應用中，向一個STUN服務器 發(fā)送數(shù)據(jù)包后，你沒有收到STUN的任何回應包，那只有兩種可能：1、STUN服務器不存在，或者你弄錯了port。2、你的NAT拒絕一切UDP包從外 部向內(nèi)部通過（我們公司的NAT就是）。

?當B收到此UDP后，把此UDP中的IP和自己的IP做比較，如果是一樣的，就說明自己是在公網(wǎng)，下步NAT將去探測防火墻類型，我不想多說。如果不一 樣，說明有NAT的存在，系統(tǒng)進行STEP2的操作。

STEP2：B向C的IP1發(fā)送一個UDP包，請求C通過另外一個 IP2和PORT（不同與SETP1的IP1）向B返回一個UDP數(shù)據(jù)包（現(xiàn)在知道為什么C要有兩個IP了吧，雖然還不理解為什么，呵呵）。

我們來分析一下，如果B收到了這個數(shù)據(jù)包，那說明什么？說明NAT來著不拒，不對數(shù)據(jù)包進行任何過濾，這也就是STUN標準中的full coneNAT。遺憾的是，full cone nat太少了，這也意味著你能收到這個數(shù)據(jù)包的可能性不大。如果沒收到，那么系統(tǒng)進行STEP3的操作。

STEP3：B向C的IP2的port2發(fā)送一個數(shù)據(jù)包，C收到數(shù)據(jù)包 后，把它收到包的源IP和port寫到UDP包中，然后通過自己的IP2和port2把此包發(fā)還給B。

和step1一樣，B肯定能收到這個回應UDP包。此包中的port是我們最關心的數(shù)據(jù)，下面我們來分析：

如果這個port和step1中的port一樣，那么可以肯定這個NAT是個CONE NAT，否則是對稱NAT。道理很簡單：根據(jù)對稱NAT的規(guī)則，當目的地址的IP和port有任何一個改變，那么NAT都會重新分配一個port使用，而 在step3中，和step1對應，我們改變了IP和port。因此，如果是對稱NAT,那這兩個port肯定是不同的。

如果在你的應用中，到此步的時候PORT是不同的，恭喜你，你的STUN已經(jīng)死了。如果不同，那么只剩下了restrict cone 和port restrict cone。系統(tǒng)用step4探測是是那一種。

STEP4：B向C的IP2的一個端口PD發(fā)送一個數(shù)據(jù)請求包，要求C 用IP2和不同于PD的port返回一個數(shù)據(jù)包給B。

我們來分析結果：如果B收到了，那也就意味著只要IP相同，即使port不同，NAT也允許UDP包通過。顯然這是restrict coneNAT。如果沒收到，沒別的好說，port restrict? NAT.

（2）SIP怎么使用STUN

個人認為這是個很不值得提的問題，不過有許多人問我，還是簡要提一下。其實這是個很簡單的問題，SIP通過STUN得到NAT的外網(wǎng)IP和SIP的信令監(jiān) 聽端口的外網(wǎng)port，替換SIP注冊包中的contact頭中的IP和port，然后注冊。這樣就可以確保當有人呼叫你的的時候注冊服務器能找到你。需 要提醒你的是，NAT發(fā)現(xiàn)一個連接超過一段時間后沒有活動，它就會關閉這個影射，因此你必須間隔一端時間發(fā)送一個數(shù)據(jù)包出去以keep alive。

另外，當你要和別人建立RTP通訊的時候，不要忘記把你的SDP中的IP和PORT改成公網(wǎng)IP和PORT。

?

================================================================================================

?

下面對SIP協(xié)議產(chǎn)生NAT穿透問題，作一些解釋；及提出解決的辦法。
1、大致有4種類型的NAT。
a) Full Cone 完全圓錐體
b) restricted cone 受限制的圓錐體
c) port restricted 端口受限制的圓錐體
d) symmetric 對稱的
其中a,b,c 也稱作非對稱的NAT。

2、SIP終端在NAT后面，其工作有可能出現(xiàn)問題。原因是SIP信令走的路徑，和媒體流走的路徑不一樣。

3、Full Cone 完全圓錐體NAT
因特網(wǎng)上的任何PC，可以發(fā)送數(shù)據(jù)包到IP:port對；而NAT將這個IP:port對（公網(wǎng) 上的）映射到內(nèi)網(wǎng)的IP:port對（私有網(wǎng)絡的）。

4、restricted cone 受限制的圓錐體NAT
NAT外面的PC，只有那些內(nèi)網(wǎng)中已有PC與之聯(lián)系過的PC，才能通過這個映射 進來。例如，我通過內(nèi)網(wǎng)的一臺機器，IP 地址是10.1.1.1:123，與PC(a)聯(lián)系，則PC(a)也可以通過這個NAT的映射，聯(lián)系到我。而PC(b)則不行。
10.1.1.1:123 —NAT —> 202.70.65.78:10000 ——pc(a)
如果pc(b)也發(fā)送數(shù)據(jù)到 202.70.65.78:10000，則不會有數(shù)據(jù)送到10.1.1.1:123。

補充說明：
如果我也聯(lián)系過pc(b)，則pc(b)也可以進來了。
10.1.1.1:123 —NAT —> 202.70.65.78:10000 ——pc(b)
如果pc(b)也發(fā)送數(shù)據(jù)到202.70.65.78:10000，則數(shù)據(jù)送到 10.1.1.1:123。

5、port restricted 端口受限制的圓錐體NAT
除了4的條件外，即不但要檢測pc(a)的源IP地址，還要檢測其端口是否 與前面也一樣。
10.1.1.1:123 —>NAT—->202.70.65.78:10000 —–> pc(a)[213.123.324.34:8000]

這個NAT只會接收從IP地址 213.123.324.34 且端口為 8000來的數(shù)據(jù)，讓進入到10.1.1.1:123。

6、對稱的NAT 這是關系描述最簡單的一個
10.1.1.1:1000 —-NAT —–> 200.123.123.34:1234 —-pc(a)
10.1.1.1:1000 —-NAT —–> 200.123.123.34:2222—-pc(b)
這種NAT的IP:port對，對每個外部的程序，都是不同的。因而每一個外部的程 序，都有自己的映射（NAT分配的IP:port對）。而前面的三種，多個外部程序，可能共用一個NAT的IP:port對。

7、RTP的問題
在RTP的消息正文內(nèi)，有UA能夠成功通信所需要的一些信息。這種消息正文，就叫做SDP消息。

問題在于，SIP終端（UA）可能對NAT一無所知。因而在SDP中包含的IP地址，通常使用內(nèi)部的IP地址，也就是SIP終端知道的IP。這樣， 當通信的對方想與SIP終端通信時，就查看SDP消息中的IP地址，但是什么也沒有得到，因為這里使用的是內(nèi)部IP地址。

下面舉個例子說明：

INVITE sip:040600@192.168.20.2:5060 SIP/2.0.
Record-Route: <sip:143.248.130.35;ftag=3a7ceb24a6ac50c4;lr=on>.
Via: SIP/2.0/UDP 143.248.130.35;branch=z9hG4bK758e.976609c7.0.
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.
From: "Iqbal" <sip:040618@sip.dom.com>;tag=3a7ceb24a6ac50c4.
To: <sip:040600@sip.dom.com>.
Contact: <sip:040618@223.178.140.109:1024>.
Supported: replaces.
Call-ID: 7f2c327896a5b0e1@192.168.20.3.
CSeq: 8717 INVITE.
User-Agent: Grandstream HT487 1.0.5.18.
Max-Forwards: 16.
Allow: IN
VITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Type: application/sdp.
Content-Length: 343.
.
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP消息的標題頭，類似于郵件的標題頭。從后往前看，從From行開始，看到第一個Via行，這是SIP終端自己認為的IP地址，例如 192.168.20.3。但是SIP代理服務器是聰明的，它知道這個消息是從哪里發(fā)過來的，它添加了rport和接收到的標志：
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.

也就是說，SIP代理服務器，知道發(fā)消息的SIP終端的公網(wǎng)地址是223.178.140.109:1024。
這樣，SIP代理服務器是可 以與SIP終端通信的，因為它知道SIP終端的公網(wǎng)地址。

但是，可憐的老式的RTP被阻塞了，因為它的標題頭如下：
v=0.
o=040618 8000 1 IN IP4 192.168.20.3.
s=SIP Call.
c=IN IP4 192.168.20.3.
t=0 0.
m=audio 38660 RTP/AVP 0 8 4 18 2 15 99.
a=sendrecv.
a=rtpmap:0 PCMU/8000/3.
a=rtpmap:8 PCMA/8000/3.

SIP終端期望從端口 port m=38660 且IP地址IP c= 192.168.20.3來接收RTP數(shù)據(jù)，而這個192.168.20.3:38660，就是通信的對方試圖發(fā)RTP數(shù)據(jù)的目的地址。

這就是SIP電話振鈴總是能夠聽到，而接起來卻沒有聲音的原因。

8 解決辦法 告訴SIP終端，不要如此傻地工作，而要想辦法知道NAT分配給自己的端口映射。

并將公網(wǎng)的IP地址：端口放到SDP消息中。這樣，SIP終端就問NAT….。或者是問公網(wǎng)的某個服務器，NAT分配給自己的映射是什么。

9 問NAT。 這種辦法就是使用UPnP協(xié)議，另外去參見UPnP的資料。

10 問公網(wǎng)上的某個服務器。 如STUN服務器。
SIP終端發(fā)送一個探測數(shù)據(jù)包，到公網(wǎng)上的服務器。公網(wǎng)上的服務器會發(fā)回數(shù)據(jù)包，會包含 有關NAT的詳細信息。有了這些信息，SIP終端就會知道它是否在NAT后面。這種探測方法，可以用于上面4種NAT，都有效。例如SIP終端從 10.1.1.1:1000發(fā)送一個數(shù)據(jù)包，則SDP消息中包含的是m=1000 and c=10.1.1.1。但是，如果SIP終端先進行NAT探測，則會知道NAT會分配公網(wǎng)的IP:端口是212.134.123.23:12345。則 SIP終端直接在SDP消息寫m=12345，c=212.134.123.23。

產(chǎn)生的問題 因為NAT的端口分配是動態(tài)的，因而有可能會改變。這樣，在發(fā)送了NAT探測消息后，要很快地發(fā)送出SIP消息。而且，SIP終端發(fā)送數(shù)據(jù)的端口和接收數(shù) 據(jù)的端口要是一樣的。

注意受限制的圓錐體（包括端口受限制的圓錐體）NAT，它不讓回來的消息進來，除非SIP終端先發(fā)了一個數(shù)據(jù)包給它。因而，SIP終端需要先發(fā)一個 數(shù)據(jù)包給對方。這樣以后對方來的數(shù)據(jù)，就可以進入NAT內(nèi)部了（不過，不需要為這個操作擔心，有辦法的）。

上面的辦法在對稱的NAT后面，不能夠工作。因為，對稱的NAT，它在分配給SIP終端外部的IP:port時，每次都變化（不同的對方不一樣）。 也就是SIP終端在探測NAT時，得到的IP:port，與它后來發(fā)SIP消息時，分配的IP:port不一樣。這樣，對方來的語音數(shù)據(jù)就進不來，因為對 方得不到正確的IP:port。

11、上面描述的過程，其實就是采用STUN協(xié)議時，解決問題的過程。就是SIP終端向STUN服務器發(fā)探測NAT的數(shù)據(jù)包。

12、對稱的NAT 解決辦法 就是在公網(wǎng)上放一個中轉語音流的服務器。這個中轉語音流的服務器有時就是一個Out Bound proxy。注意，這個中轉語音流的服務器，可能會成為瓶頸。由于語音要經(jīng)過中轉語音流的服務器，所以路徑增長了，音質會變差。所以，對稱的NAT，要 SIP能夠工作，總之是個麻煩。

不過，目前大多數(shù)的NAT，都可以做“虛擬服務器的端口轉發(fā)”，即將SIP工作需要的端口轉發(fā)到SIP終端上去。如果在NAT設備上，做了“虛擬服 務器的端口轉發(fā)”，則NAT會保留SIP工作需要的端口，專用于SIP終端，這樣SIP終端就相當于是在一個Full Cone完全圓錐體的NAT后面，SIP用STUN工作沒有問題。SIP終端需要的端口數(shù)是這樣確定的，一個端口用于SIP信令，比如5060。RTP端 口的數(shù)量，取決于通話的路數(shù)。一路通話需要2個RTP端口。每增加一路通話，則需要多2個端口。
只支持一路通話的SIP話機，需要NAT映射3個 端口。
前面三種的NAT，可統(tǒng)稱為非對稱的NAT。非對稱的NAT，都可以用STUN協(xié)議穿過NAT。

將對稱的NAT，通過端口轉發(fā)的方式，變?yōu)橥耆珗A錐體的NAT，是解決NAT問題的最好辦法。首先應當用這種辦法來解決。沒有辦法映射端口，再想其 它的辦法。當然，建議大家不要買那種不能夠映射端口的寬帶路由器，那樣的路由器太差了。

===================================================================================

2. 案例

2.1. asterisk作為服務器，在nat之外，voip電話在nat之內(nèi)。

????? 2.1.1. 呼叫來自nat后面的電話終端，asterisk把媒體發(fā)到私網(wǎng)ip

?

如果voip電話沒有使用stun或其他機制來獲取它的公網(wǎng)地址（并把公網(wǎng)地址寫入invite消息），asterisk就把媒體發(fā)到私網(wǎng)地址，被路由器丟棄導致單通。

這種情況發(fā)生在sip.conf中主叫用戶配置了nat=never，或nat=no，或nat=rfc3581。與nat的類型無關。

那就只有nat=route可以了，即主叫發(fā)送媒體到asterisk后，asterisk再按原路返回rtp.(asterisk如何獲得rtp的路由?)

??? 2.1.2. 呼叫來自nat后面的電話，asterisk發(fā)送媒體到錯誤端口

voip電話能檢測到自己的公網(wǎng)ip并寫入invite頭，asterisk知道rtp的ip地址。

如果nat類型是Cone（full cone，restricted cone）,nat轉發(fā)rtp到asterisk的端口不是原來voip電話的媒體端口，asterisk按照原端口發(fā)送rtp。這時nat就不知道把從asterisk收到的rtp包轉給誰（cone是內(nèi)網(wǎng)ip：port對應外網(wǎng)ip：port，一一對應）。

?nat=route或nat=yes可以解決這個問題。

?如果只有一個電話在nat后面，可以做端口映射，把該電話使用的rtp端口都做內(nèi)外網(wǎng)映射。

如果有多個電話在nat后面，則可以把rtp端口范圍不重疊的分派給每個電話，然后分別做端口映射。（？）

?

使用symmetric nat或stun服務器也可以解決這個問題

?

好慢～～～好累～～～

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結

以上是生活随笔為你收集整理的asterisk的NAT配置的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。