TURN

Traversal Using Relays around NAT (TURN) - Protokoll für Multimedia-Anwendungen zur Überwindung von NAT oder Firewalls

Beschreibung

TURN-Protokoll ermöglicht, UDP-Kommunikation wie WebRTC, NAT oder Firewalls zu umgehen

Stellt dem Client eine Verbindung zum TURN-Server bereit
Ein TURN-Server stell dann in seinem Namen eine Verbindung zum Ziel her

Motivation

TURN-Server ermöglichen es Clients hinter restriktiven Firewalls eine Verbindung zu Servern aufzunehmen

Beispiel

Für BigBlueButton muss eine Vielzahl von UDP-Ports für die WebRTC-Kommunikation verfügbar sein
In einigen netzwerkbeschränkten Sites oder Entwicklungsumgebungen, z. B. hinter NAT oder einer Firewall, die ausgehende UDP-Verbindungen einschränkt, können Benutzer möglicherweise keine ausgehenden UDP-Verbindungen zu Ihrem BigBlueButton-Server herstellen.

STUN-Protokoll

Weiterhin implementiert der TURN-Server auch das STUN-Protokoll
- mit dem direkte UDP-Verbindungen über bestimmte Arten von Firewalls ermöglicht werden, die andernfalls möglicherweise nicht funktionieren.

Die Verwendung eines eigenen TURN-Servers

verbessert den Erfolg von Verbindungen zu BigBlueButton
verbessert die Privatsphäre der Benutzer
- da keine IP-Adressinformationen an einen öffentlichen STUN-Server gesendet werden

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.

Vor- und Nachteile von NAT

Lästigster Nachteil

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.

Anforderungen

Hardware

TURN-Protokoll ist nicht CPU- oder speicherintensiv

da es nur während des Verbindungsaufbaus (für STUN) und als Ersatz für Benutzer verwendet wird, die sonst keine Verbindung herstellen könnten, sind die Bandbreitenanforderungen nicht besonders hoch.

Kleiner VPS ausreichend

Für eine moderate Anzahl von Servern
Mehrerer IP-Adressen können die Ergebnisse verbessern
- wenn STUN mit bestimmten Arten von Firewalls verwendet wird
- normalerweise nicht erforderlich

Server hinter NAT (z. B. Amazon EC2)

ALLE eingehenden UDP- und TCP-Verbindungen an einem beliebigen Port dürfen nicht durch eine Firewall blockiert sein

Anhang

Siehe auch

TURN

Sicherheit

Dokumentation

RFC

RFC	Beschreibung	Datum
8656	TURN
7065	TURN-URI-Schema

Man-Pages

Info-Pages

Links

Projekt

Weblinks