Session Traversal Utilities for NAT

Session Traversal Utilities for NAT (STUN, englisch für „Werkzeuge zum Durchkreuzen von NATs“) ist ein einfaches Netzwerkprotokoll, um das Vorhandensein und die Art von Firewalls und NAT-Routern zu erkennen und direkte Verbindungen zwischen Geräten, welche sich hinter einer NAT-Firewall befinden, aufzubauen. Damit ist es Geräten, welche hinter bestimmten Typen von NAT-Firewalls betrieben werden, möglich direkte bidirektionale Verbindungen zwischen den Endknoten aufzubauen. Beispiele für die Anwendung von STUN sind SIP-Telefone und Computer-Programme in Heimnetzwerken.

Allgemeines

STUN dient dazu, die Informationen wie die öffentliche IP-Adresse und Port-Nummer für den direkten Kontaktaufbau zwischen zwei Endgeräten, den „Clients“, welche sich normalweise nicht direkt erreichen können, zu ermitteln um dann in Folge und unabhängig von STUN, den Clients mit diesen Informationen die direkte Kontaktaufnahme zu ermöglichen. STUN wird unter anderem bei der IP-Telefonie (v. a. im Zusammenhang mit SIP) und bei Online-Spielen von Spielekonsolen eingesetzt.

STUN wurde in RFC 3489^[1] definiert und stand damals noch für englisch Simple traversal of UDP through NATs. Aufgrund der gemachten Erfahrungen und neuen Definitionen aus anderen RFCs wurde STUN dann überarbeitet und in englisch Session Traversal Utilities for NAT umbenannt (RFC 5389^[2]). 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.

Ein in der Funktion ähnliches Protokoll stellt TURN dar, die Abkürzung steht für englisch Traversal Using Relays around NAT, welches im Gegensatz zu STUN sich eines externen, im öffentlichen Internet befindlichen Relay-Server bedient, um so eine Verbindung zwischen Clients mit einem direkten Kommunikationskanal aufzubauen. Dies erlaubt auch Kommunikationen, wo die direkte Verbindung von Endgeräten untereinander durch bestimmte, restriktive NAT-Firewalls blockiert werden. Der Nachteil ist, dass der normalerweise verschlüsselte Datentransfer über den TURN-Server laufen muss und diese Anbindung bei vielen Verbindungen einen Flaschenhals darstellt.

Funktionsweise

STUN ist ein auf dem User Datagram Protocol (UDP) basierendes Client-Server-Protokoll. Es dient zur Ermittlung einer externen IP-Adresse und zur Analyse der Verbindung eines Clients zum Internet. Es ermittelt ob NAT verwendet wird und welche NAT-Art vorliegt. Es dient nicht zur kompletten Durchdringung von Firewalls (hole punching). Für eine vollständige Analyse der Verbindungsarten (NAT-Arten) werden zwei STUN-Server mit unterschiedlichen IP-Adressen benötigt. RFC 3489^[1] ist mittlerweile als obsolet gekennzeichnet, RFC 5389^[2] und RFC 7350^[3] enthalten geänderte und erweiterte STUN Varianten.

Eine STUN-Anfrage (gemäß RFC 3489^[1]) besteht aus folgenden Parametern:

Transaktions-ID

Vom Client vergeben. Dient zur Unterscheidung mehrerer STUN Verbindungen.

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 Server an, die Antwort nicht vom gleichen UDP-Port zu beantworten, an den 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 Clients 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 antwortenden Servers gesendet.

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 der der Netzwerkkarte des Clients, so wird keine NAT verwendet und der Client ist direkt (z. B. ü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 IP-Telefonie 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 Client umleitet, sobald diese an die öffentliche IP-Port-Adresse des Clients gerichtet sind, die er in der Antwort des STUN-Servers im ersten Test empfangen hat. Die Full Cone-NAT weist dem Port des Clients im lokalen Netzwerk einen festen Port mit der öffentlichen IP-Adresse zu (Mapping), der dann nicht mehr geändert wird.

Erhält der Client keine Antwort, beginnt der dritte Test. Er sendet eine normale Anfrage ohne gesetzte Bits 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. Sind 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-Adressen 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 Client 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 bei, lässt aber 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 dazu 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 IP-Telefonie 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
• Stuntman: Open Source STUN Server

Weblinks

• RFC5389 – Session Traversal Utilities for NAT (STUN). (englisch).
• Entwurf für die NAT-Typerkennung
• VoIP und Firewalls – All About Security (Memento vom 3. Februar 2010 im Internet Archive)
• RFC7350 – Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). (englisch).
• RFC3489 – STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). (englisch).

Einzelnachweise

1. ↑ ^{a b c} RFC3489 – STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). (englisch).
2. ↑ ^{a b} RFC5389 – Session Traversal Utilities for NAT (STUN). (englisch).
3. ↑ RFC7350 – Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN). (englisch).