Traversal über Relays um NAT herum

Traversal Using Relays around NAT ( TURN ) ist ein Protokoll , das Multimedia-Anwendungen beim Umgehen von Netzwerkadressübersetzern (NAT) oder Firewalls unterstützt. Es kann mit dem Transmission Control Protocol (TCP) und dem User Datagram Protocol (UDP) verwendet werden. Besonders nützlich ist es für Clients in Netzwerken, die durch symmetrische NAT- Geräte maskiert werden. TURN ermöglicht nicht den Betrieb von Servern auf bekannten Ports im privaten Netzwerk über ein NAT; es unterstützt lediglich die Verbindung eines Benutzers hinter einem NAT zu einem einzigen Peer, wie beispielsweise in der Telefonie.

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

Die Netzwerkadressübersetzung (NAT), ein Mechanismus zur Abmilderung des Problems der IPv4-Adressknappheit beim Übergang zu IPv6 , weist verschiedene Einschränkungen auf. Die gravierendste ist, dass NAT viele bestehende IP-Anwendungen beeinträchtigt und die Entwicklung neuer Anwendungen erschwert. ^{[ 1 ]} Es wurden zwar Richtlinien für die Erstellung „NAT-freundlicher“ Protokolle entwickelt, doch viele Protokolle lassen sich diesen Richtlinien nicht entsprechend umsetzen. Beispiele hierfür sind Multimedia-Anwendungen und Filesharing-Protokolle.

Session Traversal Utilities for NAT (STUN) bietet eine Möglichkeit für Anwendungen, ein NAT-Netzwerk zu überwinden. STUN ermöglicht es einem Client, eine Transportadresse ( IP-Adresse und Port) zu beziehen, die zum Empfangen von Paketen von einem Peer nützlich sein kann. Allerdings sind die von STUN bezogene Adresse möglicherweise nicht für alle Peers nutzbar. Ihre Funktion hängt von den topologischen Gegebenheiten des Netzwerks ab. Daher kann STUN allein keine vollständige Lösung für die NAT-Traversal bieten .

Eine vollständige Lösung erfordert ein Verfahren, mit dem ein Client eine Transportadresse beziehen kann, über die er Mediendaten von jedem Peer empfangen kann, der Pakete an das öffentliche Internet senden kann. Dies ist nur möglich, indem Daten über einen Server im öffentlichen Internet weitergeleitet werden. Das Protokoll TURN (Traversal Using Relays around NAT) ermöglicht es einem Client, IP-Adressen und Ports von einem solchen Relay zu beziehen.

Obwohl TURN fast immer eine Verbindung zum Client herstellt, ist es für den TURN-Serveranbieter ressourcenintensiv. Daher sollte TURN nur im äußersten Notfall eingesetzt und nach Möglichkeit andere Mechanismen (wie STUN oder direkte Verbindungen) bevorzugt werden. Um dies zu erreichen, kann die ICE-Methode ( Interactive Connectivity Establishment ) verwendet werden, um die optimale Verbindungsmethode zu ermitteln.

Der Prozess beginnt, wenn ein Client-Computer einen Peer-Computer für eine Datentransaktion kontaktieren möchte, dies aber aufgrund unterschiedlicher NAT-Router beider Computer nicht möglich ist. Steht STUN nicht zur Verfügung, weil einer der NAT-Router ein symmetrischer NAT-Router ist (ein NAT-Typ, der bekanntermaßen nicht mit STUN kompatibel ist), muss TURN verwendet werden.

Zunächst kontaktiert der Client einen TURN-Server mit einer „Allocate“-Anfrage. Diese Anfrage fordert den TURN-Server auf, Ressourcen für den Client bereitzustellen, damit dieser einen Peer kontaktieren kann. Ist eine Zuweisung möglich, weist der Server dem Client eine Adresse als Relay zu und sendet ihm eine „Allocation Successful“-Antwort, die die zugewiesene Relay-Transportadresse des TURN-Servers enthält.

Zweitens sendet der Client eine CreatePermissions-Anfrage an den TURN-Server, um ein Berechtigungsprüfungssystem für die Peer-Server-Kommunikation einzurichten. Mit anderen Worten: Wenn ein Peer schließlich kontaktiert wird und Informationen an den TURN-Server zurücksendet, die dann an den Client weitergeleitet werden, überprüft der TURN-Server anhand der Berechtigungen, ob die Peer-zu-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 Send-Mechanismus verwenden oder (2) einen Kanal mithilfe der ChannelBind-Anfrage reservieren. Der Send-Mechanismus ist einfacher, erzeugt aber einen größeren Header (36 Byte), was die Bandbreite einer TURN-basierten Kommunikation erheblich erhöhen kann. Die ChannelBind-Methode hingegen ist schlanker: Der Header ist nur 4 Byte groß, erfordert aber unter anderem die Reservierung eines Kanals, der regelmäßig aktualisiert werden muss.

Bei beiden Methoden, Senden oder Kanalbindung, empfängt der TURN-Server die Daten vom Client und leitet sie mittels UDP-Datagrammen an den Peer weiter. Die Quelladresse dieser Datagramme enthält die „Zugewiesene Weiterleitungsadresse“. Der Peer empfängt die Daten und antwortet ebenfalls mit einem UDP-Datagramm als Transportprotokoll, das er an die Weiterleitungsadresse des TURN-Servers sendet.

Der TURN-Server empfängt das Peer-UDP-Datagramm, prüft die Berechtigungen und leitet es, falls diese gültig sind, an den Client weiter.

Dieses Verfahren umgeht sogar symmetrische NATs, da sowohl der Client als auch der Peer zumindest mit dem TURN-Server kommunizieren können, der eine Relay-IP-Adresse für die Kommunikation zugewiesen hat.

TURN ist zwar robuster als STUN, da es die Überwindung mehrerer NAT-Typen unterstützt, jedoch leitet eine TURN-Kommunikation die gesamte Kommunikation über den Server und benötigt dadurch deutlich mehr Serverbandbreite als das STUN-Protokoll. Dieses löst typischerweise nur die öffentliche IP-Adresse auf und leitet die Information an Client und Peer zur direkten Kommunikation weiter. Aus diesem Grund schreibt das ICE-Protokoll die Verwendung von STUN als primäre Option vor und TURN nur dann, wenn symmetrische NATs oder andere Situationen vorliegen, in denen STUN nicht verwendet werden kann.

• Interaktive Verbindungsherstellung (ICE)
• Session Traversal Utilities for NAT (STUN)