imported>Matthäus Wander: /* Allgemeines */ link

2025-07-11T09:15:04Z

Allgemeines: link

Neue Seite

'''Session Traversal Utilities for NAT''' ('''STUN''', {{enS}} für „Werkzeuge zum Durchkreuzen von [[Network Address Translation|NATs]]“) ist ein einfaches [[Netzwerkprotokoll]], um das Vorhandensein und die Art von [[Firewall]]s 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-Telefon]]e und Computer-Programme in Heimnetzwerken.

== Allgemeines ==
STUN dient dazu, die Informationen wie die öffentliche [[IP-Adresse]] und [[Port (Protokoll)|Port-Nummer]] für den direkten Kontaktaufbau zwischen zwei Endgeräten, den „[[Client]]s“, welche sich normalerweise 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 [[Session Initiation Protocol|SIP]]) und bei Online-Spielen von Spielekonsolen eingesetzt.

STUN wurde in <nowiki>RFC 3489</nowiki><ref name="RFC3489" /> definiert und stand damals noch für {{EnS|''Simple traversal of UDP through NATs''}}. Aufgrund der gemachten Erfahrungen und neuen Definitionen aus anderen RFCs wurde STUN dann überarbeitet und in {{EnS|''Session Traversal Utilities for NAT''}} umbenannt (<nowiki>RFC 5389</nowiki><ref name="RFC5389" />). 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 {{EnS|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-Modell|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 (Rechnernetz)|hole punching]]). Für eine vollständige Analyse der Verbindungsarten (NAT-Arten) werden zwei STUN-Server mit unterschiedlichen IP-Adressen benötigt. <nowiki>RFC 3489</nowiki><ref name="RFC3489" /> ist mittlerweile als obsolet gekennzeichnet, <nowiki>RFC 5389</nowiki><ref name="RFC5389" /> und <nowiki>RFC 7350</nowiki><ref>{{RFC-Internet |RFC=7350 |Titel=Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) |Datum=}}</ref> enthalten geänderte und erweiterte STUN-Varianten.

Eine STUN-Anfrage (gemäß <nowiki>RFC 3489</nowiki><ref name="RFC3489" />) 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 [[Kontravalenz|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 ===
[[Datei:STUN Algorithm3.svg|mini|hochkant=2|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 [[Local Area Network|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 ==
* [https://sourceforge.net/projects/stun/ STUN Client and Server library]
* [https://github.com/tking/JSTUN JSTUN – Java-Implementierung]
* [https://www.stunprotocol.org/ Stuntman]: Open Source STUN Server

== Weblinks ==
* {{RFC-Internet |RFC=3489 |Titel=STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |Datum=}}
* {{RFC-Internet |RFC=5389 |Titel=Session Traversal Utilities for NAT (STUN) |Datum=}}
* {{RFC-Internet |RFC=7350 |Titel=Datagram Transport Layer Security (DTLS) as Transport for Session Traversal Utilities for NAT (STUN) |Datum=}}
* [https://datatracker.ietf.org/doc/html/draft-ietf-behave-nat-behavior-discovery Entwurf für die NAT-Typerkennung]
* {{Webarchiv | url=http://www.all-about-security.de/security-artikel/applikations-host-sicherheit/voice-over-ip-unified-communication/artikel/525-voip-und-firewalls | wayback=20100203143013 | text=VoIP und Firewalls – All About Security}}

== Einzelnachweise ==
<references>
<ref name="RFC3489">
{{RFC-Internet |RFC=3489 |Titel=STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |Datum=}}
</ref>
<ref name="RFC5389">
{{RFC-Internet |RFC=5389 |Titel=Session Traversal Utilities for NAT (STUN) |Datum=}}
</ref>
</references>

{{SORTIERUNG:STUN}}
[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:VoIP-Software]]
[[Kategorie:Netzwerkadressübersetzung]]

Session Traversal Utilities for NAT - Versionsgeschichte

imported>Matthäus Wander: /* Allgemeines */ link