Page History

Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example.

TURN is specified by RFC 5766 . An update to TURN for IPv6 is specified in RFC 6156. The TURN URI scheme is documented in RFC 7065.

The process begins when a client computer wants to contact a peer computer for a data transaction, but cannot do so due to both, client and peer, being behind respective NATs. If STUN is not an option because one of the NATs is a symmetric NAT (a type of NAT known to be non-STUN compatible), TURN must be used.

First, the client contacts a TURN server with an "Allocate" request. The Allocate request asks the TURN server to allocate some of its resources for the client so that it may contact a peer. If allocation is possible, the server allocates an address for the client to use as a relay, and sends the client an "Allocation Successful" response, which contains an "allocated relayed transport address" located at the TURN server.

Second, the client sends in a CreatePermissions request to the TURN server to create a permissions check system for peer-server communications. In other words, when a peer is finally contacted and sends information back to the TURN server to be relayed to client, the TURN server uses the permissions to verify that the peer-to-TURN server communication is valid.

After permissions have been created, the client has two choices for sending the actual data, (1) it can use the Send mechanism, or (2) it can reserve a channel using the ChannelBind request. The Send mechanism is more straightforward, but contains a larger header, 36 bytes, that can substantially increase the bandwidth in a TURN relayed conversation. By contrast, the ChannelBind method is lighter: the header is only 4 bytes, but it requires a channel to be reserved which needs to be periodically refreshed, among other considerations.

Using either method, Send or channel binding, the TURN server receives the data from the client and relays it to the peer using UDP datagrams, which contain as their Source Address the "Allocated Relayed Transport Address". The peer receives the data and responds, again using a UDP datagram as the transport protocol, sending the UDP datagram to the relay address at the TURN server.

The TURN server receives the peer UDP datagram, checks the permissions and if they are valid, forwards it to the client.

This process gets around even symmetric NATs because both the client and peer can at least talk to the TURN server, which has allocated a relay IP address for communication.

While TURN is more robust than STUN in that it assist in traversal of more types of NATs, a TURN communication relays the entire communication through the server requiring far more server bandwidth than the STUN protocol, which typically only resolves the public facing IP address and relays the information to client and peer for them to use in direct communication. For this reason, the ICE protocol mandates STUN usage as a first resort, and TURN usage only when dealing with symmetric NATs or other situations where STUN cannot be used.

Source: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT

Traversal Using Relays around NAT (TURN) ist ein Protokoll, das beim Durchlaufen von Netzwerkadressübersetzern (NAT) oder Firewalls für Multimedia-Anwendungen hilft. 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 von symmetrischen NAT-Geräten maskiert werden. TURN hilft nicht dabei, Server auf bekannten Ports im privaten Netzwerk über ein NAT zu betreiben; es unterstützt die Verbindung eines Benutzers hinter einem NAT zu nur einem einzigen Peer, wie zum Beispiel in der Telefonie.

TURN wird durch RFC 5766 spezifiziert. Ein Update auf TURN für IPv6 ist in RFC 6156 festgelegt. Das TURN-URI-Schema ist in RFC 7065 dokumentiert.

Der Prozess beginnt, wenn ein Client-Computer einen Peer-Computer für eine Datentransaktion kontaktieren möchte, dies aber nicht tun kann, da sowohl der Client als auch der Peer hinter den jeweiligen NATs stehen. Wenn  STUN keine Option ist, weil eines der NATs ein symmetrisches NAT ist (ein Typ von NAT, von dem bekannt ist, dass er nicht STUN-kompatibel ist), muss TURN verwendet werden.

Zunächst kontaktiert der Client einen TURN-Server mit einer "Allocate"-Anfrage. Die Allocate-Anfrage fordert den TURN-Server auf, einige seiner Ressourcen für den Client bereitzustellen, damit er sich mit einem Kollegen in Verbindung setzen kann. Wenn eine Zuordnung 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" auf dem TURN-Server enthält.

Zweitens sendet der Client eine CreatePermissions-Anfrage an den TURN-Server, um ein Berechtigungsprüfsystem 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ückschickt, um an den Client weitergeleitet zu werden, 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 zum Senden der eigentlichen Daten, (1) er kann den Send-Mechanismus verwenden oder (2) er kann einen Kanal über die ChannelBind-Anfrage reservieren. Der Send-Mechanismus ist einfacher, enthält aber einen größeren Header, 36 Bytes, der die Bandbreite in einem TURN-geleiteten Gespräch 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 periodisch aktualisiert werden muss.

Der TURN-Server empfängt die Daten vom Client und leitet sie über UDP-Datagramme an den Peer weiter, die als Quelladresse die "Allocated Relayed Transport Address" enthalten. Der Peer empfängt die Daten und antwortet, wiederum unter Verwendung eines UDP-Datagramms als Transportprotokoll, indem er das UDP-Datagramm an die Relay-Adresse am TURN-Server sendet.

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

Dieser Prozess kommt auch um symmetrische NATs herum, da sowohl der Client als auch der Peer zumindest mit dem TURN-Server sprechen können, der eine Relay-IP-Adresse für die Kommunikation zugewiesen hat.

Während TURN robuster als STUN ist, da es bei der Durchquerung von mehr Arten von NATs hilft, leitet eine TURN-Kommunikation die gesamte Kommunikation über den Server weiter, die weitaus mehr Server-Bandbreite erfordert als das STUN-Protokoll, das normalerweise nur die öffentliche IP-Adresse auflöst und die Informationen an Client und Peer weiterleitet, damit sie in der direkten Kommunikation verwendet werden können. Aus diesem Grund schreibt das ICE-Protokoll die Verwendung von STUN als erstes Mittel vor und die Verwendung von TURN nur, wenn es sich um symmetrische NATs oder andere Situationen handelt, in denen STUN nicht verwendet werden kann.

Quelle: https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT