當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

asterisk的NAT配置

發布時間：2023/12/10 编程问答 36 豆豆

生活随笔收集整理的這篇文章主要介紹了 asterisk的NAT配置小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

【轉】asterisk的NAT配置

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

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

1. sip.conf:

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

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

a） nat=route

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

b） nat=no

默認配置，根據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規定的一種NAT穿透方式，它采用輔助的方法探測NAT的IP和端口。毫無疑問的，它對穿越早期的NAT起了巨大的作用，并且還將繼續在ANT穿透中占有一席之地。

STUN的探測過程需要有一個公網IP的STUN server，在NAT后面的UAC必須和此server配合，互相之間發送若干個UDP數據包。UDP包中包含有UAC需要了解的信息，比如NAT外網 IP，PORT等等。UAC通過是否得到這個UDP包和包中的數據判斷自己的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端口發送一個UDP 包。C收到這個包后，會把它收到包的源IP和port寫到UDP包中，然后把此包通過IP1和port1發還給B。這個IP和port也就是NAT的外網 IP和port（如果你不理解，那么請你去看我的BLOG里面的NAT的原理和分類），也就是說你在STEP1中就得到了NAT的外網IP。

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

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

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

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

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

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

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

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

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

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

（2）SIP怎么使用STUN

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

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

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

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

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

3、Full Cone 完全圓錐體NAT
因特網上的任何PC，可以發送數據包到IP:port對；而NAT將這個IP:port對（公網上的）映射到內網的IP:port對（私有網絡的）。

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

補充說明：
如果我也聯系過pc(b)，則pc(b)也可以進來了。
10.1.1.1:123 —NAT —> 202.70.65.78:10000 ——pc(b)
如果pc(b)也發送數據到202.70.65.78:10000，則數據送到 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來的數據，讓進入到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的消息正文內，有UA能夠成功通信所需要的一些信息。這種消息正文，就叫做SDP消息。

問題在于，SIP終端（UA）可能對NAT一無所知。因而在SDP中包含的IP地址，通常使用內部的IP地址，也就是SIP終端知道的IP。這樣，當通信的對方想與SIP終端通信時，就查看SDP消息中的IP地址，但是什么也沒有得到，因為這里使用的是內部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代理服務器是聰明的，它知道這個消息是從哪里發過來的，它添加了rport和接收到的標志：
Via: SIP/2.0/UDP
192.168.20.3;rport=1024;received=223.178.140.109;branch=z9hG4bK34efcab2403aa20d.

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

但是，可憐的老式的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數據，而這個192.168.20.3:38660，就是通信的對方試圖發RTP數據的目的地址。

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

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

并將公網的IP地址：端口放到SDP消息中。這樣，SIP終端就問NAT….?；蛘呤菃柟W的某個服務器，NAT分配給自己的映射是什么。

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

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

產生的問題因為NAT的端口分配是動態的，因而有可能會改變。這樣，在發送了NAT探測消息后，要很快地發送出SIP消息。而且，SIP終端發送數據的端口和接收數據的端口要是一樣的。

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

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

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

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

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

將對稱的NAT，通過端口轉發的方式，變為完全圓錐體的NAT，是解決NAT問題的最好辦法。首先應當用這種辦法來解決。沒有辦法映射端口，再想其它的辦法。當然，建議大家不要買那種不能夠映射端口的寬帶路由器，那樣的路由器太差了。

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

2. 案例

2.1. asterisk作為服務器，在nat之外，voip電話在nat之內。

????? 2.1.1. 呼叫來自nat后面的電話終端，asterisk把媒體發到私網ip

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

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

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

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

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

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

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

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

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

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

好慢～～～好累～～～

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎