In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

NAT - Network address translation - ist das wichtigste und störendste Protokoll im Zusammenhang mit IP-Telefonie. Hätten wir alle ausreichend IP-Adressen (wie z.B. bei IPv6), dann wäre jedes Endgerät unter einer eindeutigen IP-Adresse erreichbar, prima.

Weil das aber bei IPv4 knapp ist, kommt NAT zum Einsatz:

• Die Endgeräte haben ein lokales IP-Netz, meist 192.168.irgendwas

• Der z.B. DSL-Router (z.B. die FritzBox) hängt auch mit 192.168.irgendwas in diesem IP-Netz (meistens spielt er auch den DHCP, d.h. er verteilt die IP-Adressen sogar selbst an seine User)

• Gleichzeitig hängt er an der DSL-Leitung und hat da eine öffentliche IP-Adresse (89.90.91.92) seines Providers, z.B. Telekom

Wenn jetzt ein PC des Users mit einem Server www.vollzeitnerd.de Kontakt aufnimmt, dann geht das wie folgt:

1. Zuerst findet der PC per DNS raus, dass www.vollzeitnerd.de die IP-Adresse 80.237.226.3 hat

2. Der PC des Users Absender: 192.168.178.123 kontaktiert seinen Router, beispielweise eine FritzBox unter 192.168.178.1

3. Wäre es nur ein Router (ohne NAT), dann würde der das Paket weiterleiten an den Provider und der Absender wäre immer noch 192.168.178.123. Am Ende würde dieses Paket dann beim Server 80.237.226.3 ankommen mit Absender 192.168.178.123. Die Antwort des Servers ginge dann an 192.168.178.123, und weil das keine eindeutige IP-Adresse ist, landet das Ergebnis auch nicht beim Provider Telekom, sondern würde das Rechenzentrum meines Webseiten-Providers nie verlassen (denn deren Router wüsste nicht, wohin damit)

4. Also ändert die FritzBox das Paket ab, sie übersetzt die 192.168.178.123-Absender-IP in seine eigene öffentliche (89.90.91.92) und schickt das Paket damit ab. Mein Server beantwortet die Anfrage und schickt die Antwort an 89.90.91.92, die Antwort findet ihren Weg zur Telekom und von dort zum DSL-Router des Kunden

5. Der (also die Fritzbox) bekommt eine Antwort, guckt in seine NAT-Tabelle rein, von wem die Antwort eigentlich war (ach ja: 192.168.178.123), übersetzt das wieder zurück, d.h. ändert das Ziel auf 192.168.178.123 und schickt das Paket intern los.

Bei TCP-Verbindungen (verbindungsgebunden) sieht das so aus, dass Alice ja sozusagen zu Bob hingeht, um ihm ins Gesicht zu gucken. Und auf dem Weg dahin lässt sie im NAT-Router (FritzBox) sozusagen „den Fuß in der Tür“, damit die nicht zufällt. Wenn sie die Antwort bekommen hat, dann geht sie selbst den Weg zurück. Und darum gibt es keine NAT-Probleme bei TCP-Verbindungen.

Bei UDP ist das ja anders, Alice ruft nur in Richtung Bob, bewegt sich aber sozusagen nicht. Und wenn irgendwann die Antwort kommt, dann landet die erstmal beim NAT-Router (der FritzBox) und der muss anhand seiner NAT-Tabelle entscheiden/erraten, an welches Gerät er sie weiter„brüllt“.

Konkret im Zusammenhang mit IP-Telefonie, speziell SIP, kann das zu folgenden Fehlerbildern führen:

• Nach dem Start des Endgerätes registriert sich das am Server, und der NAT-Router merkt sich dass Endgerät+Server miteinander gesprochen haben. Irgendwann nach ein paar Minuten vergisst der NAT-Router diese Zuordnung. Wenn dann nach 5 Minuten ein Anruf kommt, schickt der Server den in Richtung 89.90.91.92, aber der NAT-Router weiß nicht, an welches Endgerät er dieses Paket weiterleiten soll und verwirft es. Effekt: Nach ein paar Minuten Betriebszeit bekommt das Telefon keine Anrufe (und auch nicht anderes, z.B. keine Besetzlampen-Status-Änderungen) mehr mit. Raustelefonieren kann man aber, und nach einem ausgehenden Gespräch ist man auch (erstmal) wieder ankommend erreichbar, weil der NAT-Router ja erstmal wieder eine Zuordnung gemerkt hat.

• Oder: Beim Telefonat hätte das Endgerät den Ton gerne an Port 12345. Der SIP-Verkehr lief aber bisher über 5060. Die SIP-Nachrichten (und damit der Rufaufbau) geht klar. Kommt aber der Ton beim NAT-Router auf Port 12345 an, versteht dieser nicht, dass der zu dieser Kommunikation gehört und leitet ihn nicht an das Endgerät weiter. Effekt: Einseitige Sprachverbindung, das Telefon kann raussenden (an den Gesprächspartner), aber es wird nichts hören.

• Das gleiche Problem kann auftreten, wenn vom SIP-Provider der Ton von einer anderen IP-Adresse geschickt wird als die Signalisierung - der NAT-Router findet zu dieser Absender-IP keine passende vorangegangene Kommunikation und weiss nicht, dass er ihn ans Telefon weiterleiten soll.

• Kombination der o.g. Effekte: Anfangs funktioniert es, aber nach exakt immer der gleichen Zeit (meist 2-5 Minuten) vergisst der NAT-Router die Zuordnung und obwohl das Gespräch noch läuft, leitet er dann keinen Ton mehr weiter.

• Ein SIP-Telefon funktioniert wunderbar. Sobald man ein zweites einsteckt, nutzen die beiden den Port 5060 für ihre SIP-Nachrichten und der NAT-Router kommt durcheinander und schickt Pakete, die eigentlich an das eine Telefon hätten gehen sollen, versehentlich intern an das andere. Gerade bei der im Beispiel genannten FritzBox kommt noch erschwerend hinzu, dass die ja selbst auch IP-Telefonanlage spielt (d.h. auch die konkurriert selbst um den Port 5060).

DS-lite ist eine Technik, die gerne bei Kabelanschlüssen (Vodafone/ehem. UnifyMedia), seltener auch bei anderen Internet-Zugängen geschaltet wird. Bei DS-lite bekommt man als Kunde nur noch einen IPv6-Anschluss und hat keine „eigene“ IPv4-Adresse, sondern man teilt sich diese IPv4-Adresse mit anderen Kunden des gleichen Anbieters. Teilen heißt: NAT.

Und damit macht DS-lite einen solchen Anschluss für SIP nahezu unbrauchbar. Zum einen kommt je nach Konfiguration dann Doppel-NAT zum Einsatz: Einmal auf dem lokalen Router, der das 192.168er Netz in eine IPv6-Adresse NATtet, und dann nochmal beim Provider, der die verschiedenen IPv6-Kunden dann über die geteilte IPv4-Adresse ausleitet und dabei selbst NAT macht.

Und zum anderen haben die anderen Kunden (hinter der gleichen IPv4-Adresse) ja u.U. auch SIP-Geräte im Einsatz, und (siehe oben) je mehr SIP-Geräte hinter einem NAT-Router hängen, desto schwieriger kommt er u.U. damit klar.

Darum ist DS-lite quasi der Todesstoß für stabile SIP-Verbindungen.

Abhilfe:

• Produkte, die über TCP arbeiten
• Telefonie-Anbieter/Produkte, die mit IPv6 arbeiten. Denn bei DSlite bekommt man eine vollwertige IPv6-Adresse, das DSlite ist quasi nur die Krücke für IPv4. 
• Umstieg auf einen Internet-Tarif mit "fester IPv4-Adresse". Die müsste technisch gar nicht fest sein, aber sie ist dann exklusiv, und damit auch kein DSlite.

Konkret für die "bessere" Funktionalität von SIP (Internet-Telefonie) über NAT gibt es eine Reihe von Gegenmaßnahmen:

• Gut gemeint, schlecht gemacht: SIP ALGs. Insbesondere einige Firewalls haben eine zuschaltbare Funktion namens SIP ALG („SIP Application Layer Gateway“), d.h. sie versuchen SIP-Nachrichten zu verstehen und zu verbessern. Was erstmal gut klingt, geht leider meistens schief, die Firewalls, die (deutlich schlimmer als „normale“ NAT-Router) sowieso schon Mist machen, machen beim SIP ALGen noch mehr Mist. Darum ist meistens der umgekehrte Weg (Fehlerbild klingt nach NAT? Dann mal gucken, ob man ein SIP ALG abschalten kann) sinnvoll.

• STUN: Simple Traversal of NAT over UDP ist ein Hilfsprotokoll, mit dem das Endgerät über verschiedene Tests rausfinden kann, welcher NAT-Typ (es gibt unterschiedliche) zum Einsatz kommt und welche öffentliche IP-Adresse es hat. Ersteres hilft für die Art und Weise, wie mit regelmäßigen SIP-Nachrichten (z.B. OPTIONS) der NAT-Router „erinnert“ werden kann, dass da eine Kommunikation stattfindet. Und letztere ist wichtig für die Frage, an welche IP der Ton geschickt werden soll. STUN kann helfen, manchmal kann es aber auch besser sein, auf STUN zu verzichten.

• Hilfsmaßnahmen serverseitig: Viele Serversysteme und Anbieter versuchen selbständig, den NAT-Typ zu erkennen und zu „beherrschen“. Die von mir gerne beruflich betreute SwyxWare kann das z.B. nicht selbst, darum ist sie ohne Hilfsmittel wie VPN oder SessionBorderController für Rechenzentrums-Einsatz ungeeignet bzw. darum baue ich beruflich eben noch ein paar mehr Systeme um so einen SwyxServer drum herum. Die recht beliebte Linux-"Telefonanlagen"-Software asterisk z.B. kennt in der sip.conf bei einem peer (=Teilnehmer) die Einstellung nat = force_rport, damit erzwingt man eine Erkennung der öffentlichen IP-Adresse des Gegenübers.

• Verlagern des Ports 5060. Wie in den TCP-/UDP-Grundlagen erklärt muss ja eigentlich nur der Serverdienst (Provider-Seite) verbindlich auf dem Standard-Port 5060 arbeiten, beim Anwender (Client-Seite) bzw. auf seinem Telefon darf i.d.R. auch ein anderer Port zum Einsatz kommen. Zwar muss auch der Provider das Endgerät erreichen können (bei einem Anruf), aber da das Endgerät ja sowieso irgendwo im Internet steht (und sich registrieren muss, damit der Server weiß, unter welcher IP er es findet), kann sich der Server bei der Gelegenheit den Kommunikationsport merken. Also kann es helfen, wenn man den lokalen SIP-Port am Gerät auf irgend etwas anderes stellt (und insbesondere, wenn man mehrere Geräte im gleichen NAT-Netzwerk nutzt, dann eben jedes Telefon woanders hin).