SIP och NAT, Brandväggar och STUN

Transkript

1 SIP och NAT, Brandväggar och STUN BAKGRUND Många kämpar med att ringa med SIP genom routers. Många av oss får problem och anledningen är enkel, SIP är inte avsett att användas genom brandvägg och NAT. Har nedan utgått från en egen inloggning till registreringsservern och ett efterföljande samtal. Har i loggen från dessa lagt in förklaringar och kommentarer. Det är inte så svårt att lära sig vad som sker och vet man detta kan sedan enklare veta vart man skall leta efter lösningen på problemen. Har inte kollat alla detaljer fullt ut och det kan finnas felaktigheter i detaljerna. Jag har använt ett program i datorn för att ringa och loggat vad som sker. Programmet heter X-Lite och är vanligt. Om ni inte upptäckt det kan man få fram en logg genom att högerklicka i programmets fönster och sedan välja loggen. Loggen försvinner när ni stänger programmet. INLOGGNINGEN När man startar X-Lite, eller sin telefon av annan typ, så sker en inloggning till operatörens så kallade registrarserver. En vanlig telefon är ju låst till en fysisk position vilket inte VoIP är. Man måste börja med att tala om för operatörens server var man finns = vilken IP-adress man finns på. Det är detta som sker vid registreringen Xten Networks, Inc. All rights reserved. sipgate X-Lite release 1105c build stamp License key: CEFA25348AD84D8293D7506 Established SIP protocol listen on: :5060 På raden ovanför framgår att X-Lite nu börjat lyssna på min internadress, den bakom routern alltså. Delen innan kolon är själva adressen, delen efter kolon är portnumret som man lyssnar på. X-Tunnels is disabled since an X-Tunnels server could not be located. Discovered Full Cone NAT Firewall För att kunna veta ovanstående krävs att X-Lite använder STUN. För att helt kunna fastställa vilken typ av NAT man använder krävs två olika STUN servers. Mer om STUN nedan. För övrigt tror jag att jag har restricted port cone NAT. Mer om detta nedan. SIP: :5060 RTP: :8000 RTP är protokollet för överföring av ljud, sker här på port 8000 NAT: Min externa adress på Internet PROXY#0: :5060 Operatörens serveradress, lyssnar på port 5060 SEND TIME: Tidsangivelse, man kan se tiden mellan olika händelser Visar vilket håll paketet gått, i detta fall ut från mig till servern REGISTER sip:sipgate.co.uk SIP/2.0 Första ordet innebär att jag begär att få registrera mig :5060;rport;branch=z9hG4bK3EA72F D48B0674FBA127C9DE7 From: Kalle Anka <sip: @sipgate.co.uk>;tag= min benämning hos operatören To: Kalle Anka <sip: @sipgate.co.uk> Contact: "Kalle Anka" <sip: @ :5060> Min IP-adress och vilken port jag lyssnar på CSeq: 9580 REGISTER Expires:

2 RECEIVE TIME: Avsändare för detta paket är servern SIP/ Unauthorized Av någon anledning blev jag inte godkänd, troligtvis för att jag inte gett användare/lösen :37639;rport=5060;branch=z9hG4bK3EA72F D48B0674FBA127C9DE7 From: Kalle Anka To: Kalle Anka CSeq: 9580 REGISTER WWW-Authenticate: Digest realm="sipgate.co.uk", nonce="4587ac758bfbfd95e19fafec50dee344bf02da64" SEND TIME: Så lätt ger jag mig inte, ett försök till! Paket från mig till servern REGISTER sip:sipgate.co.uk SIP/ :5060;rport;branch=z9hG4bKD4B75047C3AD46879CBB BF From: Kalle Anka To: Kalle Anka Contact: "Kalle Anka" CSeq: 9581 REGISTER Expires: 1800 Authorization: Digest username=" ",realm="sipgate.co.uk",nonce="4587ac758bfbfd95e19fafec50dee344bf02da64",response= "b5ac3ae590ea bc9fdcc8cfc18",uri="sip:sipgate.co.uk" RECEIVE TIME: SIP/ OK Denna gång gick det att registrera :37639;rport=5060;branch=z9hG4bKD4B75047C3AD46879CBB BF From: Kalle Anka To: Kalle Anka CSeq: 9581 REGISTER Date: Tue, 19 Dec :05:14 GMT Contact: Registreringen är nu klar. Servern vet var jag kan nås och så här blir det tills jag ringer ut eller någon ringer mig. Observera ovan att port UDP 5060 användes både för att sända och för att ta emot. När man skickar ett UDP paket hålls den port man använt öppen ett tag även för inkommande paket. Kan vara upp till några minuter. Här har vi en felkälla som kan verka mystisk: Eftersom registreringen normalt går fort och kommunikationen sker på samma port så är port 5060, i detta fall, öppen för mottagning utan speciella åtgärder. Det kan gå att registrera sig men när någon senare försöker ringa till mig går inte detta. Efter några minuter stängs port När någon försöker ringa mig finns ingen öppen port och jag upptäcker inte ens att någon försöker ringa mig. Ovan har hela proceduren försiggått på vad jag kallar signalkanalen, själva överföringen av ljud går alltid på en annan port

3 NAT OCH BRANDVÄGG I ROUTERN Det normala för en hemanvändare är att man får en adress ut mot Internet men man har flera datorer som samtidigt skall ut på nätet. I dessa fall använder man en router med NAT. Varje intern enhet får en egen unik internadress, t.ex som min dator har i exemplet ovan. Dessa interna adresser finns i ett fåtal unika nummerserier och är därmed igenkända som interna. Hur gör man då för att kunna hålla isär trafiken till ett antal interna datorer som mot Internet skall samsas om en adress? Ett exempel: :5060 vill till :5060. En annan intern dator : 1732 vill till :80. Lösningen blir att båda ut på internet får samma IP-adress men olika portnummer. NAT håller sedan koll på vem som är vem i en tabell och kan sedan skicka paket utifrån till rätt intern dator. Kommer inte ihåg vad N står för i NAT. AT står dock för Address Table. Det finns olika typer av NAT, det finns olika typer av brandväggar. Det går att skriva många sidor om bara det men nedan kommer jag att anta att vi har vad som finns i en typisk hyfsad modern router: Port restricted NAT and Stateful firewall. I praktiken innebär detta att för att en extern dator skall kunna kontakta en av mina interna, så måste den interna först ha kontaktat den externa datorn på den port den skickar tillbaks information på. Lång mening: Vi kan jämföra det med att ingen någonsin skulle kunna ringa oss om vi inte först ringt dem, kanske inte en så dum idee när man tänker på det! Kontakterna från yttervärlden måste alltså ner till portnivå vara initierade inifrån först. Detta är väsentligt men blir enklare med exempel på problem nedan. En varning här om definitionen; jag är inte säker på en sak, kan kanske definieras på olika sätt av olika tillverkare: Definitionen jag har ovan stämmer för TCP i allmänt bruk. Är dock inte lika säker på att man alltid för UDP kräver att det kommer från en redan initierad full adress (IP-adress och port) som man skickat till tidigare. Det kan vara så att man tillåter trafik in för UDP bara IP-adressen redan är känd. JAG RINGER ETT NUMMER Nedanstående är vad som sker på signalkanalen när jag ringer ett samtal. Själva ljudöverföringen kopplas sedan upp på helt andra portar än 5060 som används för att etablera och avsluta samtalet. Det är heller inte helt säkert att detta samtal är helt typiskt. Jag ringde ett nummer som är till för att testa, här föregås samtalet inte av någon ringsignal som man kan höra. Kan vara väsentligt vid felsökning, tror nämligen inte att vi får höra ringsignalen från andra sidan, den genereras på annat sätt tills man svarar i andra änden. Jag menar med detta att exemplet nedan kanske inte är helt typiskt för när signaleringen är klar och själva samtalet börjar. X-Lite är ju vanlig, prova själv om ni behöver kolla. SEND TIME: Paket från mig till servern INVITE sip:50000@sipgate.co.uk SIP/ är numret jag ringer, jag INVITE till en session :5060;rport;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk> Här känner X-Lite till min externa adress, via STUN antar jag. CSeq: INVITE Content-Type: application/sdp Content-Length: 318 v=0 o= IN IP s=sipgate X-Lite c=in IP t=0 0 m=audio 8000 RTP/AVP a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/

4 a=rtpmap:98 ilbc/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=sendrecv Raderna ovan är värda en egen mässa, de är centrala för de problem vi får. Raden ovan, m=audio 8000 RTP/AVP , innebär följande; jag talar om att jag kommer att ta emot ljudet från andra parten på port 8000, förväntar mig protokollet RTP. Siffrorna mot slutet av raden, Är en uppräkning av de codecs jag klarar. Raden ger även en prioritering avseende vilket codec jag helst vill använda, codec nummer 8 står först och det är det jag föredrar, prioriteringarna sedan i ordning nedåt. Det finns varianter av codecs. I raderna som följer specar jag vilka varianter jag menar, exempel a=rtpmap:0 pcmu/8000 innebär att codec 0 använder samplingfrekvensen 8000 Hz. Den codec som väljs är den som finns på bådas listor och ligger högst upp. RECEIVE TIME: SIP/ Proxy Authentication Required Svaret jag får är att jag måste autenticera mig innan vi kör :37639;rport=5060;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.132c CSeq: INVITE Proxy-Authenticate: Digest realm="sipgate.co.uk", nonce="4587ae ec725dff797fd bb48b2" SEND TIME: ACK sip:50000@sipgate.co.uk SIP/ :5060;rport;branch=z9hG4bKA0D358034E0541FB9B5AAE944A0AE92F To: <sip:50000@sipgate.co.uk>;tag=968ada9c3ffba887db8ff01d701887bd.132c CSeq: ACK SEND TIME: Nu är jag kollad och kör samma information som ovan igen INVITE sip:50000@sipgate.co.uk SIP/ :5060;rport;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 To: <sip:50000@sipgate.co.uk> CSeq: INVITE Proxy-Authorization: Digest username=" ",realm="sipgate.co.uk",nonce="4587ae ec725dff797fd bb48b2",response ="340ede16bbde27220d172137a6ebbe16",uri="sip:50000@sipgate.co.uk" Content-Type: application/sdp Content-Length: 318 v=

5 o= IN IP s=sipgate X-Lite c=in IP t=0 0 m=audio 8000 RTP/AVP a=rtpmap:0 pcmu/8000 a=rtpmap:8 pcma/8000 a=rtpmap:3 gsm/8000 a=rtpmap:98 ilbc/8000 a=rtpmap:97 speex/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=sendrecv RECEIVE TIME: SIP/ trying -- your call is important to us Jag är godkänd och trying till vänster är att nu försöker vi ringa :37639;rport=5060;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 To: <sip:50000@sipgate.co.uk> CSeq: INVITE RECEIVE TIME: SIP/ OK OK, vi kör, nu etablerar vi förbindelsen :37639;rport=5060;branch=z9hG4bKF381F4C56D154382A7843B19DF505BE9 Record-Route: <sip: ;lr=on> CSeq: INVITE User-Agent: sipgate asterisk Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:50000@ > Content-Type: application/sdp Content-Length: 289 v=0 o=root IN IP s=session c=in IP t=0 0 m=audio RTP/AVP Här talar servern om vilken port den kommer att använda, a=rtpmap:8 PCMA/8000 Här har vi ett problem, jag kommer inte att höra den andra a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:98 ilbc/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=silencesupp:off SEND TIME: ACK sip:50000@ SIP/

6 :5060;rport;branch=z9hG4bK1E3CA7981E9A436B8CC5FB21757A9959 Route: <sip: ;lr=on> CSeq: ACK SEND TIME: Det här paketet kommer några sekunder senare, jag har avslutat samtalet BYE SIP/ :5060;rport;branch=z9hG4bK78BF59A0872F49EDA77A9CE641B218E8 Route: <sip: ;lr=on> CSeq: BYE RECEIVE TIME: SIP/ OK Uppfattat, klart slut från servern :37639;rport=5060;branch=z9hG4bK78BF59A0872F49EDA77A9CE641B218E8 Record-Route: <sip: ;lr=on> CSeq: BYE User-Agent: sipgate asterisk Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: Ovan har jag markerat med grönt ett problem som är typiskt orsakat av NAT/brandvägg. Servern talar om, som information i ett paket, att den kommer att sända ljudet till mig på port Problemet är att NAT/brandvägg vet inte att något förväntas komma här och släpper inte igenom något! För att paketen som sänds till mig på port skall kunna nå fram måste jag initiera, öppna, porten genom att skicka något ut på denna port. Det har jag inte gjort. Resultatet i detta fall skulle ha blivit att den i andra änden kunde höra mig men jag inte dem. De hör dock mig, trafiken ut på port 8000 initieras ju innifrån. Man kan lösa detta genom att i routern köra port forwarding för vissa portar till en given intern IP-adress. Vilka portar skall man då öppna upp? Vill minnas att normen säger att man kan välja vilken port som helst mellan 1024 och Ofta begränsar de som gjort programmet/produkten detta område. Det finns ofta rekommendationer från operatören om vilka portar man behöver öppna i brandväggen/port forwarding. Dessa stämmer så länge man bara har kommunikation mellan deras grejer. Om man dock direkt via SIP skulle ringa en annan person så bestämmer hans enhet vilka portar som blir aktuella. Inte säkert det fungerar då. SIP ALG ALG står för Application Layer Gateway. I de senaste routers har det blivit vanligt att lägga in en SIP ALG i brandväggen. Denna läser då innehållet i paket som den bedömer har med SIP att göra. I exemplet ovan kan

7 den alltså läsa inne i paketet att port skall öppnas och kan göra detta. SIP ALG kan även hålla port 5060, eller vad man valt signalkanalsporten till, att vara öppen. Är denna inte öppen går det inte att ringa till dig. Generellt sett är nog SIP ALG bra. I min router var det inbyggt utan ett ord om det i bruksanvisningen. Den kan dock också ge problem: I och med att man bara kan ha en port 5060 t.ex. öppen ut mot Internet går det inte att ha två SIP program i gång samtidigt, d.v.s. så länge de båda använder port 5060 för signalkanalen. I exemplet ovan kunde jag inte ta emot något ljud från mottagaren. I routerns log kunde jag hitta att SIP ALG stoppat paket ut från min dator. I min router är SIP ALG gjord för att man skall ansluta telefonen trådlöst via WLAN. Detta fungerar bra, jag har inte behövt gjöra något för att ringa ut via WLAN. Det kan dock ge andra svårdiagnostiserade problem. STUN Stun är ett sätt att hjälpa till att komma igenom NAT/brandväggar. STUN kräver kontakt med en, helst två, speciella servers. Genom att kontakta två olika servers kan STUN fastställa vilken typ av NAT man använder. Från servern kan NAT även få reda på vilken extern IP-adress som man har, skickas tillbaka till STUN klienten i datorn/telefonen. En annan viktig funktion för STUN är att hålla signalkanalen öppen. När man registrerar sig öppnar man ju port 5060 inifrån och den hålls öppen kanske några minuter därefter. Görs inget stängs den dock sedan och ingen kan ringa till mig. STUN anropar en server med jämna mellanrum för med hjälp av servern hela tiden hålla signalkanalen öppen. Är lite osäker på detaljerna här, STUN-serverns port är normalt annorlunda än signalportens. Skulle gissa att det finns olika implementeringar av STUN. Med hjälp av den information man får via sitt SIP program och det man får via STUN så finns möjligheterna att se till att man får föbindelse. För att ta exemplet ovan skulle man kunna låta STUN, eller själva SIP-programmet skicka ett paket till port hos servern. Gör man det så är ju sedan denna port öppen ett tag. Det finns dock routers som fungerar på ett sätt så att det inte går att lösa det med STUN. TYPISKA SYMPTOM NÄR DET ÄR NAT/BRANDVÄGG SOM GER PROBLEM - Det händer ingenting när man försöker registrera sig. Får man kontakt med servern men har fel inloggningsdata får man normalt besked om detta inom några sekunder. Man får dock samma symptom om man angivit fel adress till någon server. - Man får inga inkommande samtal men det går att ringa ut. - Det går inte att ringa ut. - Intermitenta problem, det fungerar ibland, ibland inte. - Man har ett program igång i datorn, typ X-Lite samtidigt som man kör en telefon. Täcker det mesta, eller hur! HUR LÖSER MAN ENKLAST PROBLEMEN DÅ? Har man ingen router och har en internetanslutning med flera IP-adresser så köper man ingen router, man köper en accesspunkt. Av någon anledning kallas de för accesspunkt och inte switch när man talar om WLAN. Telefonen får då direktkontakt med Internet vilket den är gjord för. Allt annan är halvmessyrer som ger bieffekter eller kostar pengar (det finns speciella brandväggar/routers som löser problemet, har inte kollat priserna men antar att de är dyrare än de massproducerade routers vi normal köper.) Har man bara en IP-adress mot nätet och måste ha en router så köp en avsedd för SIP. Skulle tro att de flesta moderna är det. Har man redan en router så går det säkert att få den att fungera. Försök dock hitta någon annan accesspunkt och prova därifrån. Helst en som man vet av någon annan att den fungerar. Det är det enklaste sättet att hitta felaktiga inställningar i telefonen. Ibland är det svårt att hitta beskrivningar över inställningarna. Fråga operatören, man kan inte få mer än nej