Here is some generic info on NAT that may help your situation …
Přináším několik obecných informací o NAT, které mohou pomoci ve vaší situaci …
Network Address Translation (NAT) is a common practice used in networks, and it doesn’t play well with VoIP. Solving this problem requires an understanding of NAT, VoIP and your VoIP setup. The following focuses on the SIP protocol for VoIP using Asterisk, but problems and solutions are applicable to most other situations.
Network Address Translation (NAT) je běžná praxe používaná v sítích a s VoIP si příliš nerozumí. Řešení tohoto problému vyžaduje pochopení NAT, VoIP a vašeho VoIP nastavení. Následující text se zaměřuje na protokol SIP pro VoIP s použitím Asterisku, ale popisované problémy a řešení jsou použitelné ve většině ostatních situací.
NAT can cause problems in several places. If one of the PBXes is behind a NAT gateway, the other PBX will not be able to contact it without some additional network setup. If one or more of the phones are behind a NAT gateway, the other phone will be trying to send audio to a non-routable address. This results in failed calls or missing audio.
NAT může způsobovat problémy na několika místech. Pokud je jedna z ústředen (PBX) za NAT bránou, druhá ústředna ji nebude schopna kontaktovat bez dodatečného síťového nastavení. Pokud je jeden nebo více telefonů za NAT bránou, druhý telefon se bude snažit posílat zvuk na nesměrovatelnou adresu. To vede k neúspěšným hovorům nebo chybějícímu zvuku.
The alternative to a re-invite is to have the PBX relay the voice packets between the two endpoints.
Alternativou k re-invite je nechat PBX přeposílat (relayovat) hlasové pakety mezi oběma koncovými body.
SIP client is behind a NAT gateway connecting to a server on the Internet
SIP klient je za NAT bránou a připojuje se k serveru na Internetu
The client creates the translation entry for the SIP traffic when it first registers. As long as there is frequent communication between the two hosts, such as one packet per minute, the channel will stay open. The only configuration needed is to have the client use its external address in all SDP packets. On clients that support it, enable STUN (Simple Traversal of UDP through NAT), so the client can determine the external address dynamically, or enter it manually. Asterisk doesn’t support STUN at this time, so all NAT configuration must be done manually. The following commands in /etc/asterisk/sip.conf set up the NAT properly:
Klient při prvotní registraci vytvoří překladovou položku pro SIP provoz. Dokud mezi oběma hostiteli probíhá častá komunikace, například jeden paket za minutu, kanál zůstane otevřený. Jedinou potřebnou konfigurací je nastavit klienta tak, aby ve všech SDP paketech používal svou externí adresu. U klientů, kteří to podporují, povolte STUN (Simple Traversal of UDP through NAT), aby si klient mohl externí adresu dynamicky zjistit, nebo ji zadejte ručně. Asterisk v současné době STUN nepodporuje, takže veškerá NAT konfigurace musí být provedena ručně. Následující příkazy v /etc/asterisk/sip.conf nastaví NAT správně:
[general]
localnet=192.168.0.0/255.255.0.0 // nebo vaše podsíť
externip=x.x.x.x // použijte svou adresu
[YOURREMOTEPEER] // jméno vašeho peeru
nat=yes
qualify=yes // vynutit keepalive pakety
With this configuration, Asterisk uses the address defined by externip for all calls to the peers configured with nat=yes. The addition of qualify=yes causes Asterisk to test the connection frequently so that the NAT translations are not removed from the firewall. With these two commands, there always will be a communications channel between Asterisk and the peer, and Asterisk will use the outside address when sending SDP messages.
S touto konfigurací Asterisk používá adresu definovanou v externip pro všechny hovory k peerům, kteří mají nastaveno nat=yes. Přidání qualify=yes způsobí, že Asterisk často testuje spojení, aby překladové záznamy NAT nebyly z firewallu odstraněny. Díky těmto dvěma příkazům bude mezi Asteriskem a peerem vždy existovat komunikační kanál a Asterisk bude při odesílání SDP zpráv používat vnější adresu.
Multiple SIP phones and an Asterisk server behind a NAT gateway
Více SIP telefonů a Asterisk server za NAT bránou
Calls between the phones will work fine because NAT is not needed. For calls between you and other systems on the Internet there will be problems. Unless you register to the remote side as a client (as done in the previous example), you will not be able to receive SIP messages, so you will not be able to accept calls. Second, the address information in the call setup will point to the internal address of the phone, and the one-way audio problems mentioned previously will crop up.
Hovory mezi telefony budou fungovat bez problémů, protože NAT není potřeba. U hovorů mezi vámi a jinými systémy na Internetu však nastanou problémy. Pokud se na vzdálené straně nezaregistrujete jako klient (jako v předchozím příkladu), nebudete schopni přijímat SIP zprávy, a tedy ani hovory. Za druhé, adresní informace v nastavení hovoru budou ukazovat na interní adresu telefonu a objeví se dříve zmíněné problémy s jednosměrným zvukem.
The easiest solution to this is to avoid NAT entirely. If you have a public IP address available for your call server, use it. If your Asterisk server is connected to both the Internet and the internal network, the SIP port is reachable from both the inside and the outside, and the only problem is ensuring RTP flows properly. The PBX server does not need to be configured to route between the interfaces or provide masquerading; it simply needs to bridge the inbound and outbound voice calls.
Nejjednodušším řešením je NAT úplně obejít. Pokud máte pro svůj call server k dispozici veřejnou IP adresu, použijte ji. Pokud je váš Asterisk server připojen jak k Internetu, tak k interní síti, je SIP port dosažitelný z vnitřní i vnější strany a jediným problémem je zajistit správný tok RTP. PBX server nemusí být konfigurován pro routování mezi rozhraními ani pro masquerading; stačí, aby přemosťoval příchozí a odchozí hlasové hovory.
As I mentioned earlier, the PBX either can stay in the voice path or get out of the way. In the latter case, the PBX tells both endpoints about each other after which the endpoints talk directly. However, Asterisk could have a call setup with both endpoints and relay the RTP packets on behalf of each endpoint. The inside host would be talking to the inside address, and the outside host would be talking to the outside address. The only configuration required to achieve this in sip.conf is to disable re-invites:
Jak jsem zmínil dříve, PBX může buď zůstat v hlasové cestě, nebo z ní „ustoupit“. V druhém případě PBX předá oběma koncovým bodům informace o tom druhém a poté spolu koncové body komunikují přímo. Asterisk však může mít navázané hovory s oběma koncovými body a RTP pakety přeposílat jejich jménem. Vnitřní host bude komunikovat s vnitřní adresou a vnější host s vnější adresou. Jedinou konfigurací potřebnou k dosažení tohoto chování v sip.conf je zakázat re-invite:
[general]
canreinvite=no // vynutit relayování
This configuration works well because the Asterisk server can speak freely to the Internet to send and receive calls. It also can talk to the internal phones, and by some simple bridging, completely ignore NAT.
Tato konfigurace funguje dobře, protože Asterisk server může volně komunikovat s Internetem pro odesílání a přijímání hovorů. Zároveň může komunikovat s interními telefony a pomocí jednoduchého přemostění NAT zcela ignorovat.
As it turns out, this relaying behavior also is required when the Asterisk server has only a private address. The RTP ports will have to be forwarded on the firewall too. RTP chooses random port numbers based on configured limits. Before the ports can be configured, they should be limited in range. Configuring the firewall rules is much easier if the range of ports is known beforehand.
Jak se ukazuje, toto relayovací chování je vyžadováno i tehdy, když má Asterisk server pouze privátní adresu. RTP porty bude také nutné přesměrovat na firewallu. RTP vybírá náhodná čísla portů na základě nakonfigurovaných limitů. Než mohou být porty nakonfigurovány, měly by být omezeny do určitého rozsahu. Konfigurace pravidel firewallu je mnohem jednodušší, pokud je rozsah portů předem znám.
The range of ports to be used for RTP is defined in rtp.conf. The following configuration will limit Asterisk’s choice of RTP ports from 10000 to 20000:
Rozsah portů používaných pro RTP je definován v rtp.conf. Následující konfigurace omezí výběr RTP portů v Asterisku na rozsah od 10000 do 20000:
[general]
rtpstart=10000 // první port, který se použije
rtpend=20000 // poslední port, zaokrouhlený nahoru, pokud je lichý
Asterisk will need several RTP ports to operate properly. Only even ports are actually used, and disabling of re-invites causes two connections to be built per call. These ports and the SIP port must then be forwarded in by the firewall. The iptables syntax is:
Asterisk bude pro správný provoz potřebovat několik RTP portů. Ve skutečnosti se používají pouze sudé porty a vypnutí re-invite způsobí, že se pro každý hovor vytvoří dvě spojení. Tyto porty a SIP port pak musí být na firewallu přesměrovány dovnitř. Syntaxe iptables je:
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 10000:10100 -j DNAT \
–to-destination 192.168.1.10
iptables -t nat -A PREROUTING -i eth0 -p udp \
-m udp --dport 5060 -j DNAT \
–to-destination 192.168.1.10
Replace eth0 with the outside interface of your firewall and 192.168.1.10 with the address of your Asterisk server. These rules tell the Linux kernel to translate the destination address of any UDP packets in the given range that are entering the outside interface. This must happen at the PREROUTING stage as opposed to the POSTROUTING stage, because the destination address is being translated. At this point, any SIP or RTP packet from the Internet will be forwarded to the internal Asterisk server for processing.
Nahraďte eth0 názvem vnějšího rozhraní vašeho firewallu a 192.168.1.10 adresou vašeho Asterisk serveru. Tato pravidla říkají jádru Linuxu, aby překládalo cílovou adresu všech UDP paketů v daném rozsahu, které vstupují přes vnější rozhraní. To musí proběhnout ve fázi PREROUTING, nikoli POSTROUTING, protože se překládá cílová adresa. V tomto bodě bude jakýkoli SIP nebo RTP paket z Internetu přeposlán na interní Asterisk server ke zpracování.
When a remote station makes a call to Asterisk, the SIP packet will be forwarded in because of the iptables rules. Asterisk will stay in the media stream because of the canreinvite=no command and it will use the external address of the firewall in any SDP packets because of the NAT commands. Finally, the media stream will be forwarded to the Asterisk server because of the combination of iptables RTP forwarding and port ranges defined in rtp.conf.
Když vzdálená stanice uskuteční hovor na Asterisk, SIP paket bude díky pravidlům iptables přeposlán dovnitř. Asterisk zůstane v mediálním toku díky příkazu canreinvite=no a v SDP paketech bude používat externí adresu firewallu díky NAT příkazům. Nakonec bude mediální tok přeposlán na Asterisk server díky kombinaci přesměrování RTP v iptables a rozsahů portů definovaných v rtp.conf.
Up to this point, the configuration has focused on getting Asterisk working behind a NAT gateway, with some extra details to make the phones relay through Asterisk. There are, of course, more general solutions.
Až doposud se konfigurace soustředila na zprovoznění Asterisku za NAT bránou s několika doplňujícími detaily, aby telefony relayovaly přes Asterisk. Existují samozřejmě i obecnější řešení.
If you can avoid NAT in the first place, it is in your best interests to do so because it avoids all the problems encountered so far.
Pokud se můžete NATu vyhnout už na začátku, je to ve vašem nejlepším zájmu, protože tím předejdete všem dosud popsaným problémům.
The Asterisk gateway can have a very restrictive firewall policy applied to it – you just need to allow UDP 5060 for SIP and whatever port range is defined in rtp.conf. In this configuration, Asterisk can contact both the internal phones and the rest of the Internet.
Na Asterisk bránu může být aplikována velmi restriktivní firewallová politika – stačí povolit UDP 5060 pro SIP a jakýkoli rozsah portů definovaný v rtp.conf. V této konfiguraci může Asterisk kontaktovat jak interní telefony, tak zbytek Internetu.
If SIP is not a requirement, and you are using Asterisk, consider using the IAX protocol. IAX tunnels both the control traffic and the voice traffic over a single UDP conversation that can be port-forwarded, filtered or translated easily. This method is limited to a static set of tunnels, which is sufficient if you are connecting some PBXes over the Internet or connecting to a long-distance provider.
Pokud SIP není nutnou podmínkou a používáte Asterisk, zvažte použití protokolu IAX. IAX tuneluje jak řídicí provoz, tak hlasový provoz přes jedinou UDP konverzaci, kterou lze snadno port-forwardovat, filtrovat nebo překládat. Tato metoda je omezena na statickou sadu tunelů, což je dostačující, pokud propojujete několik PBX přes Internet nebo se připojujete k poskytovateli dálkových hovorů.
Sometimes the above solutions are not available to you. In that case, it might be advisable to move to a full-featured SIP proxy and use Asterisk only for voice applications, such as voice mail. SIP Express Router (SER) is a powerful SIP server that handles NAT well and is used by several high-volume services, including Free World Dialup. SER’s job is only in setting up calls between endpoints, so it must rely on other applications, such as specialized media proxies, to handle RTP streams if needed.
Někdy pro vás výše uvedená řešení nemusí být dostupná. V takovém případě může být vhodné přejít na plnohodnotný SIP proxy server a Asterisk používat pouze pro hlasové aplikace, jako je hlasová schránka. SIP Express Router (SER) je výkonný SIP server, který si dobře poradí s NAT a je používán několika vysoce zatíženými službami, včetně Free World Dialup. Úkolem SER je pouze nastavovat hovory mezi koncovými body, takže se musí spoléhat na jiné aplikace, například specializované media proxy, které v případě potřeby zpracují RTP streamy.
The step beyond a SIP proxy is a Session Border Controller (SBC), which is like a VoIP firewall. The SBC can intercede in either the signaling or RTP paths to add extra features, such as signaling protocol or codec translation, all while enforcing security policies. These are almost exclusively commercial products.
Krokem nad rámec SIP proxy je Session Border Controller (SBC), což je něco jako VoIP firewall. SBC může zasahovat buď do signalizační, nebo do RTP cesty, aby přidal další funkce, jako je překlad signalizačních protokolů nebo kodeků, a zároveň prosazoval bezpečnostní politiky. Jedná se téměř výhradně o komerční produkty.