TURN
Traversal Using Relays around NAT (TURN) ist ein Protokoll, das die Überwindung von Network Address Translators (NAT) oder Firewalls für Multimedia-Anwendungen unterstützt.
Beschreibung
Es kann mit dem Transmission Control Protocol (TCP) und dem User Datagram Protocol (UDP) verwendet werden.
- Es ist besonders nützlich für Clients in Netzwerken, die durch symmetrische NAT-Geräte maskiert sind.
- TURN hilft nicht beim Betrieb von Servern auf bekannten Ports im privaten Netz durch ein NAT hindurch; es unterstützt die Verbindung eines Benutzers hinter einem NAT zu nur einer einzigen Gegenstelle, wie z.B.
- bei der Telefonie.
Installation
Anwendungen
Syntax
Optionen
Parameter
Umgebungsvariablen
Exit-Status
Konfiguration
Dateien
Sicherheit
Dokumentation
RFC
- TURN wird durch RFC 8656 spezifiziert
- Das TURN-URI-Schema ist in RFC 7065 dokumentiert
Man-Pages
Info-Pages
Siehe auch
Links
Projekt-Homepage
Weblinks
Einzelnachweise
Testfragen
Testfrage 1
Testfrage 2
Testfrage 3
Testfrage 4
Testfrage 5
TMP
Protokoll
Der Prozess beginnt, wenn ein Client-Computer einen Peer-Computer für eine Datentransaktion kontaktieren möchte, dies aber nicht tun kann, weil sich sowohl Client als auch Peer hinter jeweiligen NATs befinden.
- Wenn STUN keine Option ist, weil eines der NATs ein symmetrisches NAT ist (eine Art von NAT, die bekanntermaßen nicht STUN-kompatibel ist), muss TURN verwendet werden.
Zunächst kontaktiert der Client einen TURN-Server mit einer "Allocate"-Anfrage.
- Die "Allocate"-Anfrage bittet den TURN-Server, einige seiner Ressourcen für den Client zuzuteilen, damit dieser einen Peer kontaktieren kann.
- Wenn eine Zuweisung möglich ist, weist der Server dem Client eine Adresse zu, die er als Relay verwenden kann, und sendet dem Client eine "Allocation Successful"-Antwort, die eine "allocated relayed transport address" enthält, die sich auf dem TURN-Server befindet.
Zweitens sendet der Client eine CreatePermissions-Anfrage an den TURN-Server, um ein Berechtigungsprüfungssystem für die Peer-Server-Kommunikation zu erstellen.
- Mit anderen Worten, wenn ein Peer schließlich kontaktiert wird und Informationen an den TURN-Server zurücksendet, um sie an den Client weiterzuleiten, verwendet der TURN-Server die Berechtigungen, um zu überprüfen, ob die Peer-to-TURN-Server-Kommunikation gültig ist.
Nachdem die Berechtigungen erstellt wurden, hat der Client zwei Möglichkeiten, die eigentlichen Daten zu senden, (1) er kann den Sendemechanismus verwenden, oder (2) er kann einen Kanal mit der ChannelBind-Anfrage reservieren.
- Der Send-Mechanismus ist unkomplizierter, enthält aber einen größeren Header (36 Bytes), der die Bandbreite in einer TURN-vermittelten Konversation erheblich erhöhen kann.
- Im Gegensatz dazu ist die ChannelBind-Methode leichter: der Header ist nur 4 Byte groß, aber es muss ein Kanal reserviert werden, der unter anderem regelmäßig aktualisiert werden muss.
Bei beiden Methoden, Senden oder Kanalbindung, empfängt der TURN-Server die Daten vom Client und leitet sie an den Peer weiter, indem er UDP-Datagramme verwendet, die als Quelladresse die "Allocated Relayed Transport Address" enthalten.
- Der Peer empfängt die Daten und antwortet, wiederum mit einem UDP-Datagramm als Transportprotokoll, indem er das UDP-Datagramm an die Relay-Adresse des TURN-Servers sendet.
- Der TURN-Server empfängt das UDP-Datagramm der Gegenstelle, prüft die Berechtigungen und leitet es, wenn sie gültig sind, an den Client weiter.
- Dieses Verfahren umgeht sogar symmetrische NATs, da sowohl der Client als auch die Gegenstelle zumindest mit dem TURN-Server sprechen können der eine Relay-IP-Adresse für die Kommunikation zugewiesen hat.
- TURN ist zwar robuster als STUN
- da es bei der Überwindung von mehr Arten von NATs hilft, aber eine TURN-Kommunikation leitet die gesamte Kommunikation über den Server weiter
- was weitaus mehr Server-Bandbreite erfordert als das STUN-Protokoll
- das in der Regel nur die öffentliche IP-Adresse auflöst und die Informationen an Client und Peer weiterleitet
- damit diese sie für die direkte Kommunikation verwenden können.
Aus diesem Grund schreibt das ICE-Protokoll die Verwendung von STUN als ersten Ausweg vor und die Verwendung von TURN nur bei symmetrischen NATs oder anderen Situationen, in denen STUN nicht verwendet werden kann.