STUN ( Session Traversal Utilities for NAT ; ursprünglich Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators ) ist ein standardisierter Satz von Methoden, einschließlich eines Netzwerkprotokolls, zum Traversieren von Network Address Translator (NAT)-Gateways in Anwendungen für Echtzeit-Sprach-, Video-, Messaging- und andere interaktive Kommunikationsarten.

STUN ist ein Werkzeug, das von anderen Protokollen wie Interactive Connectivity Establishment (ICE), Session Initiation Protocol (SIP) und WebRTC verwendet wird . Es ermöglicht Hosts, die Anwesenheit eines Netzwerkadressübersetzers (NAT) zu erkennen und die zugeordnete, üblicherweise öffentliche IP-Adresse und Portnummer zu ermitteln, die der NAT für die UDP-Datenströme ( User Datagram Protocol ) der Anwendung zu entfernten Hosts zugewiesen hat. Das Protokoll benötigt die Unterstützung eines externen Netzwerkservers (STUN-Server), der sich auf der gegenüberliegenden (öffentlichen) Seite des NAT befindet, üblicherweise im öffentlichen Internet .

STUN wurde erstmals 2003 in RFC 3489 angekündigt; [ 1 ] der Titel wurde in einer Spezifikation eines aktualisierten Methodensatzes, die 2008 als RFC 5389 veröffentlicht wurde, geändert, wobei das Akronym beibehalten wurde. [ 2 ]

Geschichte

Ursprünglicher NAT-Charakterisierungsalgorithmus von RFC 3489

STUN wurde erstmals 2003 in RFC 3489 angekündigt. [ 1 ] Die ursprüngliche Spezifikation beschrieb einen Algorithmus zur Charakterisierung des NAT-Verhaltens anhand der Adress- und Portzuordnung. Dieser Algorithmus ist jedoch nicht zuverlässig und nur für einen Teil der eingesetzten NAT-Geräte anwendbar. Er besteht aus einer Reihe von Tests, die von einer Anwendung durchgeführt werden. Endet der Pfad im Diagramm in einem roten Feld, ist keine UDP-Kommunikation möglich; endet er in einem gelben oder grünen Feld, ist die Kommunikation möglich. Die Methoden von RFC 3489 erwiesen sich als zu unzuverlässig für die Vielzahl unterschiedlicher NAT-Implementierungen und Anwendungsszenarien in Produktionsnetzwerken. Das STUN-Protokoll und die zugehörigen Methoden wurden in RFC 5389 aktualisiert. Dabei wurden viele der ursprünglichen Spezifikationen als Teilmenge der Methoden beibehalten, andere jedoch entfernt.

Der Titel wurde in einer Spezifikation eines aktualisierten Methodensatzes, die 2008 als RFC 5389 veröffentlicht wurde, geändert, wobei das Akronym beibehalten wurde. [ 2 ]

Design

STUN ist ein Werkzeug für Kommunikationsprotokolle, um Netzwerkadressübersetzer (NAT) auf dem Kommunikationspfad zwischen zwei Endpunkten zu erkennen und zu umgehen. Es ist als schlankes Client-Server- Protokoll implementiert und benötigt lediglich einfache Abfrage- und Antwortkomponenten. Der Server eines Drittanbieters befindet sich im allgemein zugänglichen Netzwerk, typischerweise dem Internet . Die Client-Seite ist in der Kommunikationsanwendung des Benutzers implementiert, beispielsweise in einem VoIP -Telefon oder einem Instant-Messaging-Client.

Das Basisprotokoll funktioniert im Wesentlichen wie folgt: Der Client, typischerweise in einem privaten Netzwerk , sendet eine Bindungsanfrage an einen STUN-Server im öffentlichen Internet. Der STUN-Server antwortet mit einer Erfolgsmeldung , die die IP-Adresse und Portnummer des Clients aus Serversicht enthält. Das Ergebnis wird durch eine XOR-Verknüpfung ( Exclusive-Oder ) verschleiert, um zu verhindern, dass Anwendungsschicht-Gateways (ALGs) den Paketinhalt übersetzen, die eine Deep Packet Inspection durchführen , um alternative NAT-Traversal-Methoden anzuwenden.

STUN-Nachrichten werden in UDP-Paketen ( User Datagram Protocol ) gesendet . Da UDP keine zuverlässige Übertragung gewährleistet, wird die Zuverlässigkeit durch anwendungsgesteuerte Wiederholungsübertragungen der STUN-Anfragen erreicht. STUN-Server implementieren keinen Mechanismus zur Gewährleistung der Zuverlässigkeit ihrer Antworten. [ 2 ] Wenn Zuverlässigkeit zwingend erforderlich ist, kann das TCP (Transmission Control Protocol) verwendet werden, was jedoch zusätzlichen Netzwerk-Overhead verursacht. In sicherheitskritischen Anwendungen können STUN-Nachrichten per TLS ( Transport Layer Security ) übertragen und verschlüsselt werden.

Eine Anwendung kann automatisch einen geeigneten STUN-Server für die Kommunikation mit einem bestimmten Peer ermitteln, indem sie das Domain Name System (DNS) nach dem Server -Ressourceneintrag ( SRV ) „ stun“ (für UDP) bzw. „ stuns“ (für TCP/TLS) abfragt, z. B. „stun.udp.example.com“ . Der Standard-Port für einen STUN-Server ist 3478 für UDP und TCP und 5349 für TLS. Alternativ kann TLS auch über den TCP-Port laufen, sofern die Serverimplementierung TLS- und STUN-Pakete demultiplexen kann. Falls kein STUN-Server per DNS-Abfrage gefunden wird, empfiehlt der Standard, den Zieldomainnamen nach Adressdatensätzen (A oder AAAA) abzufragen, die mit den Standard-Portnummern verwendet werden. [ 2 ]

Zusätzlich zur Protokollverschlüsselung mit TLS verfügt STUN über integrierte Authentifizierungs- und Nachrichtenintegritätsmechanismen mittels spezieller STUN-Pakettypen.

Sobald ein Client seine externe Adresse ausgewertet hat, kann er diese als Kandidaten für die Kommunikation mit anderen Clients verwenden, indem er die externe NAT-Adresse anstelle der privaten Adresse weitergibt, die von anderen Clients im öffentlichen Netzwerk nicht erreichbar ist.

Befinden sich die Kommunikationspartner in unterschiedlichen privaten Netzwerken hinter einem NAT, müssen sie sich abstimmen, um den optimalen Kommunikationspfad zu ermitteln. Bestimmte NAT-Verhaltensweisen können die Konnektivität einschränken, selbst wenn die öffentliche Bindung bekannt ist. Das Interactive Connectivity Establishment (ICE)-Protokoll bietet einen strukturierten Mechanismus zur Bestimmung des optimalen Kommunikationspfads zwischen zwei Kommunikationspartnern. SIP-Erweiterungen ( Session Initiation Protocol ) ermöglichen die Verwendung von ICE beim Verbindungsaufbau zwischen zwei Hosts.

Einschränkungen

Die Netzwerkadressübersetzung wird über eine Reihe unterschiedlicher Adress- und Portzuordnungsschemata implementiert, von denen keines standardisiert ist.

STUN ist keine eigenständige NAT-Traversal-Lösung, die in allen NAT- Bereitstellungsszenarien anwendbar ist und nicht in allen korrekt funktioniert. Es ist ein Werkzeug unter anderen Methoden und dient anderen Protokollen zur NAT-Traversal-Bewältigung, insbesondere Traversal Using Relay NAT (TURN) und Interactive Connectivity Establishment (ICE).

STUN ist mit drei NAT-Typen kompatibel: Full Cone NAT , Restricted Cone NAT und Port Restricted Cone NAT . Bei Restricted Cone oder Port Restricted Cone NAT muss der Client ein Paket an den Endpunkt senden, bevor der NAT Pakete vom Endpunkt zum Client durchlässt. STUN ist nicht mit symmetrischem NAT (auch bidirektionales NAT genannt) kompatibel, das häufig in den Netzwerken großer Unternehmen anzutreffen ist. Da die IP-Adresse des STUN-Servers sich von der des Endpunkts unterscheidet, ist die NAT-Zuordnung bei symmetrischem NAT für den STUN-Server anders als für einen Endpunkt. STUN erzielt mit symmetrischem NAT bessere Ergebnisse.

Siehe auch

Referenzen