NAT-Erkennung dank STUN

NAT-Typen

Die IETF hat in RFC 3489 Abschnitt 5 vier NAT-Typen beschrieben, auf welche ich nachfolgend noch im Detail eingehe. Mittlerweile wurde es zwar abgelöst durch RFC 5389, bis das sich überall durchgesetzt hat wird aber wohl noch ein wenig Zeit vergehen.
NAT-Typen nach RFC 3489 (vom am wenigsten restriktiven zum restriktivsten) sind:

Full Cone NAT

Alle Anfragen mit derselben internen IP und demselben Port werden auf dieselbe externe IP mit demselben Port abgebildet. Außerdem kann ein externer Host ein Paket an den internen Host senden, indem er es an die entsprechend zugewiesene externe Adresse sendet.

Restricted Cone NAT

Der Unterschied zum Full Cone NAT besteht darin, dass ein externer Host X nur dann ein Paket an den internen Rechner senden kann, wenn letzterer vorher bereits ein Paket an die IP-Adresse X gesendet hat.

Port Restricted Cone NAT

Entspricht einem „Restricted Cone NAT“ mit der Einschränkung, dass hier zusätzlich die Ports übereinstimmen müssen. Ein externer Host mit IP X und Port P kann also nur dann an den internen Host Pakete senden, wenn dieser zuvor bereits ein Paket zu X:P gesendet hat.

Symmetric NAT

Das symmetrische NAT ist das restriktivste NAT und hat nutzt im Unterschied zu den anderen NAT-Typen bei Nutzung des selben Ports auf demselben Client unterschiedliche ausgehende Ports (und womöglich auch IPs), wenn der Client sein Paket an ein anderes Ziel sendet – auch wenn er dazu denselben Source-Port verwendet. Und jeder externe Host kann nur an genau dieses externe IP/Port-Paar seine Antworten senden. Ein Client kann somit auch unter Zuhilfenahme von STUN nicht vorhersagen, welchen externen Port sein Router bzw. seine Firewall nutzen wird.

Wo STUN helfen kann

Bei allen erwähnten NAT-Typen mit Ausnahme des symmetrischen NAT kann ein SIP-Client unter Zuhilfenahme von STUN sowohl in die SIP-Header als auch in den SDP-Body korrekte IP- und Port-Angaben schreiben. Somit ist es trotz NAT möglich, den RTP-Stream direkt zwischen den beteiligten Clients zu schalten.

Erkennt STUN ein symmetrisches NAT, so darf der Client keine Annahmen bzgl. IP und Port treffen – denn er würde mit hoher Wahrscheinlichkeit immer falsch liegen. In diesem Fall finden sich im Normalfall private IP-Adressen im SIP-Paket und im SDP. Idealerweise sollte man bei einer symmetrischen Firewall STUN auf dem Client komplett deaktivieren – das spart Zeit und verhindert, dass ein fehlerhafter Client falsche Angaben in seine Pakete schreibt.

Was tun, wenn STUN versagt

Wenn der Client selbst imstande ist, sein NAT korrekt zu überqueren, dann ist das sowohl für den SIP-Provider als auch für den Client die beste Lösung. Der RTP-Stream wird den kürzesten Weg durchs Internet finden – von Client zu Client. Diese Variante nennt man eine "Near-End NAT Solution", sie skaliert am Besten und kostet den Betreiber keine zusätzliche Rechenpower und Bandbreite.

Wie wir gelernt haben kann dies bei symmetrischem NAT aber nicht funktionieren. Auch hierfür gibt es jedoch eine Antwort, sie nennt sich "Far-End NAT Solution". Der SIP-Proxy muss dabei Clients mit NAT-Problemen automatisch erkennen – für solche werden dann sowohl die SIP-Header also auch der SDP-Inhalt entsprechend umgeschrieben, der RTP-Stream über spezielle Media-Proxies bei uns umgeleitet.

Wie genau man so etwas umsetzen kann erkläre ich (wenn ich mal ein wenig Luft dafür habe) ein andermal.

Application Layer Gateways (ALG)

Immer mehr aktuelle Router und Firewalls bieten einen sogenannten SIP-ALG (also ein Gateways auf der Anwendungsebene des OSI-Modells), welcher dank seiner Unterstützung für das SIP-Protokoll seinen Clients die Nutzung von SIP vollkommen transparent ermöglichen soll.

Während das auf den ersten Blick sehr gut klingt, sieht es in der Praxis meist so aus, dass diese ALGs mehr Schaden als Nutzen verursachen – und wenn der Client zudem noch STUN aktiviert hat, geht meist gar nichts mehr. Viele Hersteller sind längst dazu übergegangen, das Ausschalten dieser (oft per default aktivierten) ALGs zu empfehlen - darunter auch namhafte wie Nokia/Checkpoint oder Juniper/Netscreen.