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. 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.

TURN wird durch RFC 8656 spezifiziert. Das TURN-URI-Schema ist in RFC 7065 dokumentiert.

Bescheibung

NATs bieten zwar Vorteile, haben aber auch Nachteile. Der lästigste dieser Nachteile ist die Tatsache, dass sie viele bestehende IP-Anwendungen unterbrechen und den Einsatz neuer Anwendungen erschweren. Es wurden Richtlinien entwickelt, die beschreiben, wie "NAT-freundliche" Protokolle zu erstellen sind, aber viele Protokolle können einfach nicht nach diesen Richtlinien konstruiert werden. Beispiele für solche Protokolle sind Multimedia-Anwendungen und File-Sharing.

Session Traversal Utilities for NAT (STUN) bietet eine Möglichkeit für eine Anwendung, ein NAT zu überwinden. STUN ermöglicht es einem Client, eine Transportadresse (eine IP-Adresse und einen Port) zu erhalten, die für den Empfang von Paketen von einer Gegenstelle nützlich sein kann. Die durch STUN erhaltenen Adressen können jedoch nicht von allen Peers verwendet werden. Diese Adressen funktionieren je nach den topologischen Bedingungen des Netzes. Daher kann STUN allein keine vollständige Lösung für die Umgehung von NAT bieten.

Eine vollständige Lösung erfordert ein Mittel, mit dem ein Client eine Transportadresse erhalten kann, von der er Medien von jedem Peer empfangen kann, der Pakete in das öffentliche Internet senden kann. Dies kann nur durch die Weiterleitung von Daten über einen Server erreicht werden, der sich im öffentlichen Internet befindet. Traversal Using Relay NAT (TURN) ist ein Protokoll, das es einem Client ermöglicht, IP-Adressen und Ports von einem solchen Relay zu erhalten.

Obwohl TURN fast immer eine Verbindung zu einem Client herstellt, ist es für den Anbieter des TURN-Servers ressourcenintensiv. Es ist daher wünschenswert, TURN nur als letzten Ausweg zu verwenden und andere Mechanismen (wie STUN oder direkte Konnektivität) vorzuziehen, wenn dies möglich ist. Um dies zu erreichen, kann die ICE-Methode (Interactive Connectivity Establishment) verwendet werden, um die optimale Art der Konnektivität zu ermitteln.

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.