Session Traversal Utilities for NAT

Zweck und Bedeutung

Session Traversal Utilities for NAT (STUN) ist ein Netzwerkprotokoll, mit dem sich erkennen lässt, ob ein Gerät hinter einer Firewall oder einem NAT-Router (Network Address Translation) betrieben wird und welche Art von NAT vorliegt. Außerdem ermittelt STUN die öffentliche IP-Adresse und UDP-Portnummer eines Clients. Mit diesen Informationen können zwei normalerweise nicht direkt erreichbare Endgeräte anschließend unabhängig von STUN eine direkte, bidirektionale Verbindung aufbauen.

STUN wird unter anderem bei der IP-Telefonie, besonders im Zusammenhang mit SIP, sowie bei Online-Spielen von Spielekonsolen und in Heimnetzwerken eingesetzt. Das Protokoll ermöglicht jedoch nicht grundsätzlich die vollständige Durchdringung von Firewalls (Hole Punching).

Für eine Verbindung, die wegen einer restriktiven NAT-Firewall nicht direkt möglich ist, kann stattdessen TURN (Traversal Using Relays around NAT) verwendet werden. TURN vermittelt die Verbindung über einen externen Relay-Server im öffentlichen Internet. Dadurch werden auch blockierte Verbindungen möglich, allerdings läuft der normalerweise verschlüsselte Datentransfer über diesen Server. Bei vielen Verbindungen kann der Relay-Server deshalb einen Flaschenhals bilden.

Grundprinzip und Nachrichten

STUN arbeitet als Client-Server-Protokoll auf Grundlage des User Datagram Protocol (UDP). Ein Client sendet eine Anfrage an einen STUN-Server. Dieser sieht die öffentliche IP-Port-Adresse, unter der die Anfrage bei ihm ankommt, und teilt sie dem Client mit. Gemeint ist die Kombination aus der öffentlichen IP-Adresse und dem Absender-UDP-Port des Clients. Die Adresse wird mit einer XOR-Maske kodiert, damit sie nicht vom NAT-Router übersetzt wird.

Für die vollständige Analyse der NAT-Art werden zwei STUN-Server mit unterschiedlichen IP-Adressen benötigt. Eine STUN-Anfrage nach RFC 3489 enthält insbesondere:

• eine vom Client vergebene Transaktions-ID zur Unterscheidung mehrerer Verbindungen,
• eine Antwortadresse aus IP-Adresse und UDP-Port; ist sie leer, antwortet der Server an die Absenderadresse,
• ein Bit für die alternative IP, das eine Antwort des zweiten STUN-Servers verlangt,
• ein Bit für den alternativen Port, das eine Antwort von einem anderen UDP-Port verlangt.

Die Antwort enthält neben der vom Server ermittelten öffentlichen IP-Port-Adresse auch die alternative IP-Adresse des zweiten Servers und die Adresse des antwortenden Servers. STUN wurde zunächst in RFC 3489 beschrieben. Die dortige Fassung ist inzwischen obsolet; RFC 5389 und RFC 7350 enthalten geänderte und erweiterte Varianten. In RFC 5389 wurde STUN als erweiterbares Framework neu definiert, während nur die Basisfunktionalität erhalten blieb.

STUN-Algorithmus zur NAT-Erkennung

Der Algorithmus untersucht schrittweise, ob UDP-Kommunikation möglich ist, ob eine NAT verwendet wird und welche NAT-Art vorliegt. Antwortet der Server auch nach mehrmaligem Wiederholen nicht, werden UDP-Pakete wahrscheinlich blockiert und die Anfrage abgebrochen.

Zunächst vergleicht der Client die IP-Adresse aus der Antwort mit der Adresse seiner Netzwerkkarte. Sind beide identisch, wird keine NAT verwendet; der Client ist direkt, beispielsweise über ein Modem, mit dem Internet verbunden. Dann wird noch die Firewall geprüft: Der Client sendet erneut an den ersten Server, diesmal mit gesetztem Alternativen-IP- und Alternativen-Port-Bit. Antwortet der zweite Server, sind eingehende Verbindungen uneingeschränkt möglich. Bleibt die Antwort aus, gibt es eine Firewall, die eingehende Pakete nur von Absendern zulässt, zu denen zuvor ein Paket gesendet wurde. Eine solche Firewall verhindert eingehende Verbindungen und ist für IP-Telefonie ungeeignet.

Wird eine NAT erkannt, sendet der Client dieselbe Anfrage mit gesetztem Alternativen-IP- und Alternativen-Port-Bit an den ersten Server. Lässt der NAT-Router die Antwort des zweiten Servers durch, liegt eine Full Cone-NAT vor. Eingehende Verbindungen werden dann uneingeschränkt an den Client weitergeleitet, wenn sie an die öffentliche IP-Port-Adresse aus dem ersten Test gerichtet sind. Die Zuordnung (Mapping) zwischen dem lokalen Client-Port und einem festen öffentlichen Port mit öffentlicher IP-Adresse bleibt bestehen.

Kommt keine Antwort, sendet der Client eine normale Anfrage ohne gesetzte Bits an den zweiten Server. Liefert dieser eine andere öffentliche IP-Port-Adresse als der erste Server, liegt eine symmetrische NAT vor. Sie verwendet für jede Ziel-IP-Adresse des Servers eine eigene Portzuweisung. Eingehende Verbindungen an eine festgelegte IP-Port-Adresse sind dadurch nicht möglich.

Sind die beiden öffentlichen IP-Port-Adressen identisch, folgt ein vierter Test: Der Client setzt ausschließlich das Alternativer-Port-Bit. Wird die Antwort vom anderen Port an den Client weitergeleitet, handelt es sich um eine Restricted NAT. Diese behält die Portzuweisung unabhängig von der Zieladresse bei, lässt eingehende Pakete aber nur zu, wenn zuvor ein Paket an deren Quelle gesendet wurde.

Bleibt auch diese Antwort aus, liegt eine Port Restricted NAT vor. Sie ähnelt der Restricted NAT, verlangt zusätzlich aber, dass die Ziel-Portnummer des vorher ausgehenden Pakets mit der Quell-Portnummer des eintreffenden Pakets übereinstimmt. Andernfalls wird das Paket verworfen. Bei Restricted NAT und Port Restricted NAT ist IP-Telefonie weiterhin möglich, wenn der Client zuvor ein Paket an die Gegenstelle sendet und dadurch den Port für sie freischaltet.

Implementierungen

Im Artikel werden folgende STUN-Implementierungen genannt:

• STUN Client and Server library
• JSTUN als Java-Implementierung
• Stuntman als Open-Source-STUN-Server