Traversée NAT

Traversée

NAT est l'ensemble de techniques qui permettent à deux appareils derrière des NAT distincts d'établir des connexions directes. Sans cela, les protocoles peer-to-peer dépendent entièrement des serveurs relais, ce qui ajoute du coût et de la latence. Grâce à lui, deux téléphones derrière des routeurs domestiques peuvent communiquer directement sur Internet pendant la majeure partie de la durée de vie de la connexion.

Le problème de base

NAT (voir notre article NAT) traduit les connexions sortantes d'adresses IP privées vers une adresse IP publique partagée. Les connexions entrantes sans mappage existant n'ont pas de destination : le NAT ne sait pas vers quel périphérique interne transférer. Deux appareils NAT ne peuvent pas établir de connexions entre eux ; les deux doivent être l'auteur.

STUN : "à quoi ressemble mon adresse IP publique ?"

STUN (Session Traversal Utilities for NAT), RFC 5389, est un protocole simple qui permet à un appareil de découvrir son mappage IP/port public. L'appareil envoie une requête STUN à un serveur STUN public ; le serveur répond avec l'adresse source qu'il a observée (qui est le mappage externe du NAT). Les serveurs

STUN sont sans état et libres d'exécution. Google exploite stun.l.google.com:19302 ; il en existe bien d’autres. Le coût d'exécution d'un tel système est négligeable car l'échange de protocole est minuscule.

Le modèle de parcours NAT le plus simple

Pour deux appareils A et B derrière les NAT :

1. A interroge STUN et apprend que son mappage public est X.
2. B interroge STUN et apprend que son mappage public est X. Y.
3. A et B échangent ces adresses via un canal de signalisation (hors bande, comme un websocket via le serveur de l'application).
4. A commence à envoyer des paquets à Y ; B commence à envoyer à X.
5. Les deux NAT voient les paquets sortants vers l'adresse de l'autre, créent les mappages nécessaires, et à partir de là, les paquets entrants vers ces mappages sont transmis en interne.
6. Le chemin direct A vers B fonctionne désormais.

Il s'agit de hole punching. Cela fonctionne lorsque les deux NAT sont raisonnablement permissifs (à cône plein ou à cône restreint). La perforation fonctionne facilement.

NAT. à cône restreint Seuls les hôtes externes précédemment contactés peuvent envoyer. La perforation fonctionne une fois que les deux côtés ont envoyé au moins un paquet.

Port-restricted-cone NAT. Restreint par l'hôte ET le port. La perforation fonctionne toujours, mais nécessite que les deux côtés envoient vers le port exact.

NAT symétrique. Le plus restrictif : le port externe diffère pour chaque destination, de sorte que le mappage vu par STUN ne prédit pas le mappage pour le trafic homologue direct. La perforation échoue généralement.

Les NAT symétriques sont courants dans les déploiements NAT de niveau opérateur et dans certains pare-feu d'entreprise. Les homologues derrière des NAT symétriques ne peuvent souvent pas se connecter directement ; ils ont besoin d'un relais.

TURN : lorsque la perforation échoue

TURN (Traversal Using Relays around NAT), RFC 5766, est la solution de secours. Lorsqu'une connexion directe n'est pas possible, les deux homologues se connectent à un serveur TURN, qui relaie le trafic entre eux. Les serveurs TURN voient tout le trafic multimédia – un coût de bande passante nettement plus élevé que STUN.

Pour les services d'appel vidéo (Zoom, Google Meet), l'exécution de serveurs TURN représente une dépense opérationnelle majeure. Les estimations suggèrent que 15 à 30 % des appels utilisent des relais TURN malgré les efforts visant à maximiser les connexions directes.

ICE : combinant tout

ICE (établissement de connectivité interactive), RFC 8445, est le cadre qui utilise STUN, TURN et la connectivité directe ensemble. Le processus : 

1. Chaque homologue rassemble toutes les adresses candidates : interfaces locales, mappages publics découverts par STUN, réservations de relais TURN.
2. Les pairs échangent des listes de candidats complètes via la signalisation.
3. Chaque homologue tente de se connecter à toutes les combinaisons de candidats distants.
4. La première combinaison de travail devient la connexion active. Le direct est préféré au relayé ; latence inférieure par rapport à supérieure.
5. La connexion peut être réévaluée en cours d'appel si les conditions changent.

WebRTC utilise ICE pour les connexions de navigateur peer-to-peer. Consultez notre article WebRTC. La plupart des protocoles P2P modernes utilisent ICE ou quelque chose de similaire.

Perforation UDP vs perforation TCP

XPLZ1La perforation UDP est simple (et est la valeur par défaut pour la plupart des cas d'utilisation de traversée NAT). La perforation TCP est beaucoup plus difficile car TCP nécessite une négociation synchronisée ; les deux côtés doivent établir des connexions simultanément et les NAT doivent autoriser l'état résultant. Certains NAT le prennent en charge ; beaucoup ne le font pas. La plupart du trafic P2P nécessitant un transport fiable utilise des protocoles basés sur UDP (QUIC, couches de fiabilité UDP personnalisées) plutôt que TCP.

NAT64 et IPv6

IPv6 n'ont pas besoin de NAT : chaque appareil possède une adresse routable globalement. Théoriquement, IPv6 élimine la traversée NAT. En pratique, un déploiement IPv6 partiel signifie que certains points de terminaison sont uniquement IPv4 derrière NAT, d'autres sont directement accessibles en IPv6 et NAT64/DNS64 effectue la traduction entre eux. Le résultat est des décisions de routage plus complexes, mais des connexions directes généralement plus faciles pour les points de terminaison compatibles IPv6.

Ce que cela signifie pour les utilisateurs

Vous ne pensez généralement pas à la traversée NAT : les applications le gèrent. Les effets visibles :

• Les appels vidéo fonctionnent correctement sur les réseaux domestiques (généralement directs ou quasi-directs)
• Les appels derrière les pare-feu d'entreprise se dégradent parfois parce que le trafic passe par TURN
• Les appels sur les réseaux mobiles ont parfois des problèmes car les NAT des opérateurs sont souvent symétriques
• Le matchmaking de jeux P2P est plus fiable sur certains réseaux que autres

Pour les utilisateurs exécutant leurs propres services : l'évolution vers IPv6 et la réduction progressive du déploiement NAT symétrique ont rendu la traversée NAT moins pénible au cours de la dernière décennie.