Session Traversal Utilities for NAT

Session Traversal Utilities for NAT (STUN, dt. „Werkzeuge zum Durchqueren von NATs“) ist ein einfaches Netzwerkprotokoll, um das Vorhandensein und die Art von Firewalls und NAT-Routern zu erkennen und letztere zu durchdringen. Es soll den unkomplizierten Einsatz von Geräten (z. B. SIP-Telefone) und Computer-Programmen in Heimnetzwerken ermöglichen, welche Daten aus dem Internet empfangen möchten.

Mit Hilfe von STUN lässt sich die derzeit öffentliche IP-Adresse des Anschlusses ermitteln. So kann z. B. ein SIP-Telefon seine derzeit gültige IP-Adresse ermitteln und mitteilen. Dies ist nötig, damit die Gegenstelle ihre Gesprächsdaten korrekt adressieren kann. Derzeit wird STUN wohl am meisten im VoIP-Bereich eingesetzt (v.a. im Zusammenhang mit SIP).

STUN wurde in RFC 3489 definiert und stand damals noch für Simple traversal of UDP through NATs. Aufgrund der gemachten Erfahrungen und neuen Definitionen aus anderen RFCs wurde STUN dann überarbeitet und in Session Traversal Utilities for NAT umbenannt (RFC 5389). Dabei wurde STUN als Framework neu definiert, und alle Funktionen bis auf die Basisfunktionalität verschwanden; dafür wurde allerdings definiert, wie Erweiterungen möglich sind.

Funktionsweise

STUN ist ein auf UDP basierendes Client-Server-Protokoll. Für eine Anfrage werden zwei STUN-Server mit unterschiedlichen IP-Adressen benötigt. Eine STUN-Anfrage besteht aus folgenden Parametern:

• Antwortadresse: Der STUN-Server soll seine Antwort an diese Adresse senden, die aus IP-Adresse und UDP-Port besteht. Ist das Feld leer, so sendet er die Antwort an die Absenderadresse der Anfrage.
• Alternative IP: Ist dieses Bit gesetzt, so wird die Antwort von dem zweiten STUN-Server beantwortet.
• Alternativer Port: Dieses Bit weist den Servern an, die Antwort nicht vom gleichen UDP-Port zu beantworten, an dem auch die Anfrage gesendet wurde.

Die Antwort beinhaltet die öffentliche IP-Port-Adresse, die der STUN-Server sieht. Mit IP-Port-Adresse ist die Kombination aus IP-Adresse und dem Absender-UDP-Port des Clienten gemeint. Diese Adresse ist mit einer XOR-Maske kodiert, damit sie nicht vom NAT-Router übersetzt wird. Außerdem wird die alternative IP-Adresse des zweiten STUN-Servers und die Adresse des antworteten Servers gesendet.

STUN Algorithmus

STUN Algorithmus

Bekommt der Client nach mehrmaligem Wiederholen keine Antwort, werden UDP-Pakete wahrscheinlich blockiert und die Anfrage wird abgebrochen. Entspricht die IP-Adresse in der STUN-Antwort die der Netzwerkkarte, so wird keine NAT verwendet und der Client ist direkt über ein Modem mit dem Internet verbunden. Anderenfalls muss der Typ der NAT genauer untersucht werden. Dazu sind weitere Tests erforderlich.

Im Fall der direkten Verbindung muss nur noch die Firewall getestet werden. Dazu wird wieder eine Anfrage an den ersten STUN-Server gesendet, aber mit gesetztem Alternativen IP und Alternativen Port Bit. Damit wird die Antwort vom zweiten Server gesendet und nicht vom ersten. Empfängt der Client eine Antwort, so sind eingehende Verbindungen uneingeschränkt möglich. Wird keine Antwort empfangen, so wird eine Firewall eingesetzt. Diese lässt nur eingehende Pakete von Absendern durch, wenn vorher ein Paket an diesen Absender gesendet wurde. Die Firewall verhindert also eingehende Verbindungen und ist für VoIP ungeeignet.

Falls eine NAT erkannt wird, wird genau die gleiche Anfrage mit gesetztem Alternativen IP und Alternativen Port Bit an den ersten Server gesendet. Lässt der NAT-Router die Antwort des zweiten STUN-Servers durch, so handelt es sich um eine Full Cone-NAT. Eingehende Verbindungen werden uneingeschränkt an den Clienten umleitet, sobald diese an die öffentlich IP-Port-Adresse des Clienten gerichtet sind, die er in der Antwort des STUN-Servers im ersten Test empfangen hat. Die Full Cone-NAT weist dem Port des Clienten im lokalen Netzwerk einen festen Port mit der öffentlichen IP-Adresse zu (Mapping), der dann nicht mehr geändert wird.

Erhält der keine Antwort beginnt der dritte Test. Er sendet eine normale Anfrage ohne gesetzte Bit an den zweiten STUN-Server. Anschließend vergleicht er die öffentliche IP-Port-Adresse, die der zweite Server ermittelt hat, mit der aus der ersten Antwort. Ist diese unterschiedlich, weil der UDP-Port unterschiedlich ist, so wird eine symmetrische NAT eingesetzt. Diese nutzt für jede IP-Adresse des Ziel-Servers eine andere Portzuweisung (Mapping). Eingehende Verbindungen an eine festgelegte IP-Port-Adresse sind somit nicht möglich.

Sind die IP-Port-Adresse dagegen identisch wird ein vierter Test ausgeführt. Der Client sendet wieder eine Anfrage, in der ausschließlich das Alternativer Port Bit gesetzt ist. Der Server antwortet von einem anderen Port, aber an die gleiche öffentliche IP-Port-Adresse. Wird die Antwort an den Clienten durchgereicht, so handelt es sich um eine Restricted NAT. Diese behält zwar die gleiche Portzuweisung (Mapping) unabhängig von der Ziel-Adresse des Paketes, lässt eingehende Pakete nur durch, wenn vorher ein Paket an dessen Quelle gesendet wurde.

Erhält der Client dagegen keine Antwort, ist eine Port Restricted NAT im Einsatz. Diese verhält sich ähnlich der Restricted NAT. Im Gegensatz muss die Ziel-Portnummer des vorher ausgehenden Paketes mit der Quell-Portnummer des nun eintreffenden Paketes übereinstimmen, sonst wird es verworfen. In den beiden letzten Fällen ist VoIP ebenfalls möglich, nur dass der Client vorher ein Paket an die Gegenstelle senden muss, damit der Port für sie freigeschaltet wird.

Implementierungen

• STUN Client and Server library
• JSTUN – Java-Implementierung

Weblinks

• RFC 3489, STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)
• RFC 5389, Session Traversal Utilities for NAT (STUN)
• Entwurf für die NAT-Typerkennung
• VoIP und Firewalls, All About SECURITY