Riešenie NAT pre SIP OpenSER server
Testovaná topológia:
Použitý SIP server pri testovaní: OpenSER
Použitý softphone: X-lite 4
Použitý router pre testovanie SIP NAT Traversal: Cisco 1841, IOS 12.4
Možné situácie
-
UA(NAT) => UA (PUBLIC)
-
klient za NAT volá klienta, ktorý ma verejnú IP adresu
-
Bez STUN
-
SIP NAT service zapnutá:
-
Beží – na Cisco routeri sa využíva službu sip nat service, ktorá defaultne beží po spustení routera (spustenie/vypnutie služby – (no) ip nat service sip udp port 5060). Pre UDP testované na verzii IOS 12.4. Pre TCP je potrebný ale až IOS verzie 15.0.
-
-
SIP NAT service vypnutá:
-
Nebude fungovať. Natovaný klient posiela na seba iba privátny kontakt a všetky pokusy o založenie RTP streamu, ako aj signalizácia zo strany public klienta pôjdu na privátnu IP, nepôjdu.
-
So STUN
-
SIP NAT service zapnutá:
-
Nebude v poriadku. Služba SIP NAT service invertuje všetky adresy v SIP správe. To znamená, že invertuje aj adresy v hlavičke via. Klienti sú ale schopní založiť RTP stream, pretože volaný public klient si dokáže prečítať verejnú adresu NATovaného klienta z hlavičky via. Server preposiela signalizáciu na NATovaného klienta aj keď má na neho lokálny kontakt, pretože si tiež pomôže hlavičkou via. Ak ale public klient do hlavičky via nedá verejnú IP NATovaného klienta signalizácia neprejde – napr. pri správe BYE, pri ukončení spojenia. Je to nevyspytateľné, a preto nepoužiteľné.
-
-
SIP NAT service vypnutá:
-
Bude fungovať. Je potrebné nastaviť na klientovi využívanie STUN servera a posielanie KeepAlive správ môže byť vypnuté alebo zapnuté (port na NAT sa otvorí poslaním SIP INVITE)
-
UA(PUBLIC) => UA(NAT)
-
klient s verejnou IP adresou volá klienta, ktorý je za NAT. Je potrebné, aby vo všetkých prípadoch bol na natovanom klientovi zapnutý keepalive, aby bol dosiahnuteľný na otvorenom porte.
-
Bez STUN
-
SIP NAT service zapnutá:
-
Situácia bez problémov. Sip nat service preloží privátne IP na verejné a signalizácia aj RTP stream pôjde bez problémov.
-
-
SIP NAT service vypnutá:
-
Nedá sa dovolať. Neprebehne ani signalizácia keďže SIP server má len privátnu IP adresu klienta za NAT a pri preposielaní INVITE správy je táto použitá.
-
So STUN
-
SIP NAT service zapnutá:
-
Nedá sa dovolať. NATovaný klient si síce vypýta svoju verejnú IP adresu od STUN už pri registrácii na SIP server, ale SIP NAT service ju pri prechode cez router invertuje späť na lokálnu. Server má teda na NATovaného klienta lokálny kontakt a v prípade INVITE správy na tohto klienta ju preposiela na lokálnu IP adresu čo nebude fungovať. Nie je teda možné mať zapnuté obidve testované riešenia súčasne.
-
-
SIP NAT service vypnutá:
-
Všetko v poriadku. NATovaný klient musí mať zapnuté keep-alive posielanie paketov a nastavený STUN server. Ak je volaný, vypýta si svoju verejnú IP adresu a tú pošle ako contact, aby public klient mohol založiť RTP stream smerom k NATovanému klientovi.
-
UA(NAT1) => UA(NAT2)
– vo všetkých prípadoch je potrebné mať zapnuté keepalive správy.
-
Bez STUN
-
SIP NAT service vypnutá:
-
– nepôjde pretože v kontakte budú mať privátne IP
-
-
SIP NAT service zapnutá:
-
– bude fungovať. Router prepíše privátnu adresu z poľa contact na verejnú. Aby však SIP server bol schopný dosiahnuť volaného klienta, klient musí mať nastavené posielanie keepalive paketov aby sa neuzavrel port v NAT.
-
So STUN
-
SIP NAT service vypnutá:
-
– všetko v poriadku. Klienti si vypýtajú od STUN servera svoje verejné IP a v poli contact uvádzajú tie. Posielanie keepalive paketov musí byť na klientoch zapnuté aby boli dosiahnuteľní serverom. Táto situácia je bezproblémová.
-
-
SIP NAT service zapnutá:
-
– nefunguje správne, pretože router získanú verejnú IP adresu od STUN servera invertuje naspäť na lokálnu IP.
-
UA(NAT1) => UA(NAT1)
– vo všetkých prípadoch je potrebné mať zapnuté keepalive správy.
-
Bez STUN
-
SIP NAT service vypnutá:
-
– nepôjde pretože v kontakte budú mať privátne IP. Čo by bolo fajn pre založenie RTP streamu, ale signalizácia na privátnych IP nie je možná.
-
-
SIP NAT service zapnutá:
-
– jediný prípad, ktorému bude fungovať aj signalizácia aj RTP stream. Router prepíše privátnu adresu z poľa contact na verejnú a následne naopak verejnú na privátnu, keď server pošle INVITE volanému klientovi. Signalizácia tak prebehne bez problémov. Klienti musia mať zapnuté posielanie keepalive. RTP stream pôjde na privátne IP.
-
So STUN
-
-
SIP NAT service vypnutá:
-
– signalizácia bude fungovať vďaka zapnutému STUN a keepalive. Problém nastáva s RTP streamom, ktorý ide na verejné adresy – teda na router a ten by ho mal poslať tým istým interfacesom späť, čo mu nedovolí NAT. Pretože NAT-u nedovolí prekladať inside na inside interface.
-
-
SIP NAT service zapnutá:
-
– nebude fungovať, pretože service preloží contact už v správe register na privátny, ten si server uloží a v prípade, že ho bude chcieť niekto kontaktovať, tak to bude posielať na privátnu adresa, čo samozrejme nie je funkčné.
Flow diagram pre prípad NAT -> Public
Flow diagram pre prípad Public -> NAT
Autori:
-
Ladislav Jurák
-
Michal Paulus
-
Ľubomír Troják