Traversal Using Relays around NAT
Traversal Using Relays around NAT (TURN) est un protocole réseau permet à deux application bloqué par un NAT ou un firewall de communiquer quand le protocole STUN ne suffit pas, ce protocole peut relayer de l'UDP et du TCP. De part la lourdeur du protocole les serveurs TURN procèdent à une authentification fondée sur celle de STUN.
Sa première spécification du protocole a été publié en 2010 dans la RFC 5766[1].
Le protocole TURN est documenté dans la RFC 8656[2] rendant obsolète les RFC 6156 et 5766.
Protocole
[modifier | modifier le code]Le processus commence lorsque deux ordinateurs clients souhaitent communiquer entre eux, mais ne peuvent pas parce qu'ils sont tous deux derrière leur NAT respectifs. Si le protocole STUN ne suffit pas parce que l'un des NAT est un NAT symétrique (un type de NAT connu pour être non compatible STUN), TURN doit être utilisé.
En premier lieu, le client contacte un serveur TURN avec une demande « Allocate ». La demande d'allocation demande au serveur TURN de réserver des ressources au client afin qu'il puisse établir une communication avec le second client (section 6 et 7 de la RFC). Le client est enregistré par son adresse ip publique et son port.
Si l'allocation est possible, le serveur alloue une adresse au client à utiliser comme relais et envoie au client une réponse « Allocation Successful », qui contient une adresse IP et un port auquel le premier client va pouvoir transmettre ses paquets à relayer au second client.
Deuxièmement, le client envoie une requête "CreatePermissions" (section 10 de la RFC) au serveur TURN pour demander une autorisation, les autorisation sont composé d'une adresse IP et d'un délai d'expiration.
Une fois les autorisations créées, le client a deux choix pour envoyer les données utiles : il peut soit utiliser le mécanisme d'envoi ou réserver un canal à l'aide de la requête ChannelBind.
Le mécanisme d'envoi est plus simple, mais contient un header plus grand (36 octets), qui peut augmenter considérablement la consommation de bande passante dans une communication relayée par TURN.
La méthode ChannelBind est plus légère : l'en-tête ne fait que 4 octets, mais nécessite de réserver un canal (section 3.5 de la RFC) qui doit être périodiquement rafraîchi pour fonctionner.
Quel que soit la méthode utilisée, le serveur TURN reçoit les données du client et les relaie au client pair à l'aide de paquets UDP, ayant pour adresse source l'adresse du serveur TURN utilisé pour relayer les paquets. Le client pair reçoit les données et répond, en utilisant à nouveau UDP comme protocole de transport, en envoyant les paquets UDP à l'adresse relais du serveur TURN.
Le serveur TURN reçoit les paquets UDP, vérifie les autorisations et, si elles sont valides, le transmet au client.
Ce processus peut contourner le problème des NAT symétriques parce que la pair de client peut au moins communiquer avec le serveur TURN, qui a attribué une adresse IP de relais pour la permettre communication.
Bien que le protocole TURN permettent de traverser plus de NAT que STUN, une communication TURN relaie l'intégralité de la communication via le serveur, une bande passante coté serveur bien plus importante que le protocole STUN, qui ne résout généralement que l'adresse IP publique pour transmetre les informations aux pairs de client pour qu'ils puissent communiquer en directe.
Ce pourquoi le protocole ICE privilégie l'utilisation de STUN en premier recours, et TURN uniquement pour les situations où STUN ne peut pas être utilisé.
Voir aussi
[modifier | modifier le code]Références
[modifier | modifier le code]- ↑ Philip Matthews, Jonathan Rosenberg et Rohan Mahy, « Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) », IETF, Internet Engineering Task Force, no RFC 5766, (lire en ligne, consulté le )
- ↑ Tirumaleswar Reddy.K, Alan Johnston, Philip Matthews et Jonathan Rosenberg, « Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) », IETF, Internet Engineering Task Force, no RFC 8656, (lire en ligne, consulté le )
