La traversée de NAT expliquée : comment le bureau à distance P2P passe à travers votre routeur.

Vous avez une seule adresse IP publique et une dizaine d’appareils derrière votre routeur. Votre iPad est sur le réseau cellulaire, à trois réseaux de distance. Pourtant, une application de bureau à distance ouvre une connexion directe de l’un à l’autre en moins d’une seconde — généralement sans aucun relais au milieu. Voici comment fonctionne réellement cette magie : ICE, STUN, TURN, le hole punching, et la vérité gênante sur le NAT symétrique.

Pourquoi c’est important

Imaginez un mardi matin. Votre Mac mini est à la maison, derrière un routeur doté d’une seule adresse IPv4 publique. Votre iPad est dans le train, sur le réseau mobile d’un opérateur, avec ses propres couches de traduction d’adresses. Au moins deux NAT, probablement trois, se dressent entre les deux appareils. Aucune des deux machines n’est joignable depuis l’internet extérieur par défaut.

Et pourtant, vous ouvrez Remio sur l’iPad, vous touchez le Mac, et une seconde plus tard vous regardez votre bureau. La vidéo et les saisies circulent directement entre les deux appareils — pas de relais dans le cloud, pas de proxy au milieu qui réencode votre écran.

La technique qui rend cela possible a un nom — la traversée de NAT — et s’appuie sur une famille de protocoles bien définis : STUN, TURN et ICE. Ce sont les mêmes protocoles que WebRTC utilise pour les appels vidéo dans le navigateur, et c’est pourquoi tout bureau à distance P2P moderne peut éviter de faire passer les images de votre écran par le datacenter d’un tiers. Cet article explique ce que fait chacun d’eux, pourquoi il existe, et comment ils se combinent pour trouver le chemin le plus rapide entre deux appareils cachés derrière des routeurs.

Le problème du NAT en 60 secondes

Internet a été conçu pour que chaque appareil dispose de sa propre adresse routable publiquement. L’espace IPv4 compte en tout environ 4,3 milliards d’adresses — largement suffisant en 1981, très clairement insuffisant à la fin des années 1990.

Le contournement a été la traduction d’adresses réseau (NAT). Votre routeur reçoit une adresse IPv4 publique de votre fournisseur d’accès. À l’intérieur de votre domicile, chaque appareil reçoit une adresse privée issue d’une plage réservée (généralement 192.168.x.x ou 10.x.x.x). Quand votre ordinateur portable envoie un paquet vers l’extérieur, le routeur réécrit l’adresse source avec sa propre IP publique, mémorise la correspondance et fait suivre le paquet. Quand la réponse revient, le routeur retrouve la correspondance et réécrit la destination pour l’adresser à votre ordinateur.

C’est exactement pourquoi les connexions entrantes ne fonctionnent pas par défaut. Vu de l’extérieur, votre ordinateur n’a pas d’adresse ; seul le routeur en a une. Le paquet d’un inconnu adressé à your-router-public-ip:5060 arrive sur un routeur qui n’a aucune correspondance pour lui, et il est abandonné.

Pour une application P2P, c’est tout l’enjeu. Les deux pairs sont derrière des routeurs qui ne font suivre un paquet que s’ils se souviennent d’avoir d’abord envoyé quelque chose vers l’extérieur. Aucun des deux côtés ne peut simplement « appeler » l’autre — il faut coopérer avec les routeurs pour ouvrir un chemin temporaire.

Hole punching : faire en sorte que le pare-feu vous laisse rentrer

Voici l’astuce. La table NAT de votre routeur est indexée sur un quintuplet : IP source, port source, IP de destination, port de destination et protocole. Quand votre appareil envoie un paquet UDP sortant vers 1.2.3.4:5678, le routeur crée une entrée temporaire qui dit : « si un paquet UDP revient de 1.2.3.4:5678 vers mon IP publique sur le port X, fais-le suivre à cet appareil sur le port Y. »

Cette entrée existe pendant une fenêtre de temps — généralement de 30 à 60 secondes — puis expire si rien ne la rafraîchit. Pendant cette fenêtre, tout paquet provenant de l’adresse de destination sera accepté.

C’est la serrure que les applications P2P utilisent. Si les deux pairs connaissent l’adresse publique de l’autre, chacun peut envoyer en même temps un unique paquet UDP sortant vers l’autre. Le routeur de chaque côté ouvre une correspondance sortante. Le premier paquet de chaque côté peut très bien être abandonné — l’autre routeur n’a pas encore ouvert la sienne — mais le deuxième paquet a un endroit où aller. À partir de là, les deux routeurs pensent faire suivre une conversation sortante ordinaire, et les deux appareils se parlent directement.

C’est ce qu’on appelle le hole punching UDP. C’est légèrement miraculeux, bien documenté (RFC 5128), et cela fonctionne pour l’immense majorité des NAT grand public dans la nature. Les cas restants — NAT symétrique, CGNAT, pare-feu d’entreprise — sont la raison d’être de TURN.

Le hole punching n’est pas un bricolage. C’est le contrat explicite autour duquel le NAT a été conçu : un paquet sortant crée une autorisation entrante. Les applications P2P se contentent d’envoyer le paquet sortant exprès.

STUN : « quelle est mon adresse publique ? »

Le hole punching exige une condition préalable : chaque pair doit connaître sa propre adresse côté public pour pouvoir dire à l’autre où envoyer les paquets. Cette adresse n’est pas visible depuis l’intérieur de l’appareil. Votre iPad voit son adresse Wi-Fi locale (192.168.1.42). Ce que voit le reste d’internet après la réécriture du paquet par le routeur est tout autre chose.

STUN — Session Traversal Utilities for NAT, RFC 5389 — est le minuscule protocole qui résout ce problème. Le déroulement est presque gênant de simplicité :

1. Le pair envoie un paquet UDP à un serveur STUN public. (Remio utilise à la fois les serveurs STUN publics de Cloudflare et de Google par souci de redondance.)
2. Le serveur STUN lit l’IP et le port source sur le fil — ce qui est, par définition, l’adresse publique du pair après traduction par le NAT.
3. Le serveur STUN répond avec cette adresse comme contenu : « D’après ce que je vois, vous êtes 203.0.113.42:48291. »
4. Le pair sait désormais quelle adresse annoncer à l’autre côté.

Cette adresse côté public s’appelle un candidat server-reflexive dans la terminologie ICE. Elle ne coûte pratiquement rien — un aller-retour pendant l’établissement de la connexion, et aucun surcoût de bande passante ni de latence une fois la connexion établie. Le seul rôle de STUN est de présenter deux pairs l’un à l’autre ; une fois qu’ils se parlent, le serveur STUN n’a plus aucun rôle.

TURN : quand le hole punching échoue

Le hole punching fonctionne pour la plupart des NAT, mais pas pour tous. Les cas d’échec sont réels, et une application P2P qui fait semblant qu’ils n’existent pas échouera simplement à se connecter pour une part non négligeable d’utilisateurs.

Les principaux coupables :

• Le NAT symétrique. Un NAT qui attribue un port public différent pour chaque destination distincte. STUN indique à votre pair que vous êtes sur le port 48291 (car c’est le port vu par le serveur STUN), mais quand vous envoyez un paquet à l’adresse de votre pair, votre routeur choisit un autre port — disons 48317. Le routeur de votre pair rejette le paquet parce qu’il vient d’un port inattendu. Le hole punching échoue.
• Le NAT de classe opérateur (CGNAT). Les réseaux cellulaires et de nombreux fournisseurs d’accès superposent un second NAT au niveau de l’opérateur. Vous pouvez être derrière deux NAT sans le savoir, et les deux doivent coopérer. Le CGNAT est souvent symétrique, et vous n’avez aucun accès administrateur dessus.
• Les pare-feu d’entreprise restrictifs. Certains réseaux d’entreprise bloquent tout l’UDP sortant, ou ne l’autorisent que vers des destinations précises. Le hole punching a besoin d’un chemin UDP ; s’il n’y en a pas, il n’a aucune chance.

Pour ces cas, la solution de repli est TURN — Traversal Using Relays around NAT, RFC 5766. Un serveur TURN est un relais que les deux pairs peuvent joindre, car il possède une adresse publique qui accepte toujours le trafic entrant. Chaque pair établit une connexion TLS sortante ordinaire vers le serveur TURN (ce que n’importe quel NAT autorise), et le serveur fait suivre les octets entre les deux côtés.

TURN a un vrai coût. Chaque paquet vidéo doit traverser un saut réseau supplémentaire. Sur un relais TURN régional, cela ajoute environ 30 à 80 millisecondes de latence aller-retour. Entre régions — disons un relais à Francfort pour un pair à Tokyo et un pair à São Paulo — cela peut atteindre 80 à 200 millisecondes. L’opérateur TURN paie aussi la bande passante : chaque bit de votre flux passe par ses tuyaux.

C’est pourquoi une application bien conçue n’utilise TURN que lorsque le hole punching a manifestement échoué. ICE prend cette décision automatiquement.

ICE : essayer tous les candidats en parallèle

Interactive Connectivity Establishment, RFC 8445, est la chorégraphie qui relie tout cela. ICE ne choisit pas de stratégie d’avance. Il rassemble toutes les adresses candidates possibles pour chaque pair, échange la liste complète avec l’autre côté, puis fait sonder par les deux piles chaque paire de candidats en parallèle — dans une course pour trouver la première qui fonctionne.

Pour chaque pair, ICE rassemble généralement :

• Les candidats host — chaque adresse IP locale sur chaque interface réseau (Ethernet, Wi-Fi, interfaces virtuelles, IPv4 et IPv6).
• Les candidats server-reflexive — les adresses publiques apprises auprès des serveurs STUN.
• Les candidats relay — les adresses allouées sur un serveur TURN.

Les deux pairs échangent ces listes via un canal de signalisation — pour Remio, une petite connexion WebSocket vers relay.remio.net qui transporte les candidats ICE et la description de session WebRTC (le SDP), puis n’a plus rien à faire une fois que le flux média circule.

Une fois les deux listes en main, ICE lance des vérifications de connectivité. Chaque pair envoie un paquet STUN Binding Request le long de chaque paire de candidats, par ordre de priorité. Les priorités sont conçues pour privilégier le chemin le plus rapide :

1. Host vers host — les deux pairs sont sur le même réseau local. C’est le cas idéal : quelques centaines de microsecondes de latence, aucun routeur impliqué.
2. Host vers server-reflexive, ou server-reflexive vers server-reflexive — les pairs sont sur des réseaux différents, reliés par hole punching à travers leurs NAT respectifs. C’est ce que signifie généralement « P2P sur internet » en pratique.
3. Tout ce qui passe par un relais — dernier recours, utilisé seulement quand tous les chemins de priorité supérieure échouent à leurs vérifications de connectivité.

La première paire de candidats dont les deux sens réussissent est désignée gagnante, et le flux média circule sur ce chemin. L’ensemble du processus se termine en général en bien moins d’une seconde.

ICE rassemble aussi des candidats en continu. Si un meilleur chemin apparaît en cours de session — par exemple, votre téléphone quitte le réseau cellulaire et rejoint le Wi-Fi — ICE peut basculer sur le nouveau chemin sans interrompre l’appel.

Pourquoi Remio privilégie fortement le P2P

Remio est une application de bureau à distance, pas un appel vidéo. Le budget de latence est impitoyable. Pour que la session donne l’impression d’être assis devant la machine hôte, toute la chaîne — capture, encodage, réseau, décodage, affichage — doit être minuscule : sur réseau local, elle coûte environ 8 ms, et le reste est la cadence de rafraîchissement 60 Hz de votre propre écran (environ 16,7 ms par image). Chaque saut supplémentaire est un péché.

Sur une connexion P2P directe en réseau local, la part réseau de ce budget est d’environ 1 à 5 millisecondes aller-retour. Il n’y a pas de relais ; les octets vont directement d’un appareil à l’autre. Avec la chaîne de Remio, cela donne environ 8 ms de traitement sur réseau local (mesuré en interne ; le reste est la cadence de rafraîchissement 60 Hz de votre propre écran) — votre saisie arrive avant que l’image suivante ne s’affiche. La machine distante ne se distingue pas d’une machine locale.

Sur une connexion relayée par TURN — même régionale — la part réseau grimpe à 30 à 80 millisecondes. La latence totale perçue par l’utilisateur est alors de 40 à 100 ms. Toujours utilisable pour la plupart des tâches, mais on la sent lors d’un glissement rapide ou d’une série de clics rapides. Le trackpad n’a plus tout à fait l’air d’être le vôtre.

Cet écart explique pourquoi nous nous donnons tant de mal pour garder les sessions en P2P. La pile WebRTC de Remio rassemble des candidats IPv4 et IPv6, dialogue avec plusieurs serveurs STUN en parallèle et privilégie vivement les chemins directs lors de la sélection de la paire de candidats par ICE. En interne, nous utilisons même le RTT mesuré de la connexion pour classer le réseau — sous 15 ms, nous savons que c’est un réseau local, donc l’encodeur démarre haut et a le droit d’utiliser beaucoup plus de bande passante. Tout ce qui est plus lent est traité comme du WAN et réglé plus prudemment.

Et — c’est la partie que les concurrents omettent souvent discrètement — la connexion est chiffrée de bout en bout quel que soit le chemin. Votre écran ne touche jamais nos serveurs, et même un relais TURN ne voit jamais que du texte chiffré : les clés sont négociées directement entre les deux pairs pendant la poignée de main, avant qu’un seul pixel ne bouge. Que les octets circulent en P2P ou via TURN, ni le serveur de signalisation de Remio ni l’opérateur TURN ne peuvent les lire. Le P2P signifie simplement qu’il n’y a aucun tiers sur le chemin des données.

Quand le relais est inévitable (et ce n’est pas grave)

Parfois, les dieux du réseau disent non. NAT symétrique aux deux extrémités, double CGNAT chez un opérateur mobile avec un fournisseur d’accès strict, pare-feu d’entreprise qui n’autorise que le TLS sortant vers des fournisseurs de cloud connus — ce sont des configurations réelles et courantes. Dans ces cas, la session doit simplement passer par un relais, sinon elle n’a pas lieu du tout.

Le backend TURN de Remio est Cloudflare Calls, qui nous donne un réseau mondial de relais proches de la plupart des utilisateurs. Quand ICE choisit un chemin relayé, l’expérience passe de « on dirait du local » à « on dirait Splashtop » — toujours très utilisable, mais ça se remarque. La latence ajoutée est de 30 à 80 ms pour un relais régional ; entre régions, elle peut atteindre 200 ms.

L’essentiel : les données restent chiffrées de bout en bout. Cloudflare voit des paquets UDP chiffrés dans un sens et des paquets UDP chiffrés dans l’autre. Il peut compter les octets pour la facturation. Il ne peut pas voir votre écran, vos frappes au clavier, ni quoi que ce soit du contenu de votre session. Il n’y a pas non plus de point de déchiffrement côté Remio, car il n’y a pas de cloud Remio dans la chaîne — nous exploitons le service TURN via Cloudflare et ne touchons jamais aux données.

C’est l’architecture que décrit plus en détail notre livre blanc sur la sécurité. En bref : en P2P ou en relais, le modèle de menaces est le même.

L’échappatoire IPv6

L’IPv6 compte 340 sextillions d’adresses (3,4 × 10³⁸) — de quoi donner à chaque grain de sable de la Terre sa propre IP publique, avec des milliers de milliards d’adresses en réserve. Dans un monde 100 % IPv6, le NAT est en grande partie inutile. Deux appareils compatibles IPv6 peuvent simplement s’envoyer des paquets à leurs adresses respectives, et le seul obstacle est le pare-feu de l’hôte à chaque extrémité.

Si vous avez de l’IPv6 chez vous et chez votre opérateur mobile, vous avez peut-être remarqué que certaines applications se connectent plus vite quand les deux extrémités sont en IPv6 — c’est parce que toute la danse « rassembler les candidats, sonder les paires » rencontre moins d’obstacles. Il n’y a aucune traduction NAT à découvrir, aucun aller-retour STUN nécessaire, juste des adresses directes.

Mais voici le hic : en 2026, le déploiement mondial est encore incomplet. De nombreux routeurs domestiques gèrent mal l’IPv6, voire pas du tout. De nombreux réseaux d’entreprise bloquent l’IPv6 entrant par défaut. Certains opérateurs proposent l’IPv6 côté radio mais font le pont vers l’IPv4 ailleurs. Des chemins purement IPv6 vers IPv6 existent, mais on ne peut pas s’y fier comme unique mécanisme.

Remio — comme toute pile P2P sérieuse — rassemble donc des candidats IPv4 et IPv6, et laisse ICE les mettre en concurrence. Si un chemin IPv6 direct existe et fonctionne, il gagne généralement sur la latence. Sinon, l’IPv4 avec hole punching prend le relais. Si les deux échouent, relais. L’utilisateur ne voit rien de tout cela ; la connexion s’établit, tout simplement.

Comment savoir quel chemin utilise votre session

Curieux de savoir sur quel chemin votre session a fini ? L’indicateur de connexion de Remio affiche le type en langage clair — « Direct » pour le P2P, « Relais » pour TURN. Le panneau de statistiques développeur expose l’état WebRTC complet, y compris les types de candidats de la paire désignée (host, srflx, relay) et le RTT mesuré.

Quelques interprétations rapides :

• RTT sous 5 ms, Direct — vous êtes sur le même réseau local que l’hôte. Le meilleur cas. Environ 8 ms de traitement (le reste étant la cadence de rafraîchissement 60 Hz de votre propre écran) sont atteignables.
• RTT de 5 à 15 ms, Direct — même réseau Wi-Fi, mais avec un saut supplémentaire par point d’accès ou maillage. Toujours excellent.
• RTT de 15 à 80 ms, Direct — vous êtes sur un autre réseau que l’hôte, le hole punching a réussi. Le P2P sur internet fonctionne.
• RTT de 30 à 80 ms, Relais (régional) — un NAT symétrique ou un NAT de classe opérateur a fait échouer le hole punching. Le TURN de Cloudflare proche a pris le relais.
• RTT de 80 à 200 ms, Relais — TURN sur une plus longue distance géographique, ou bien vous et l’hôte êtes dans des régions très différentes.

Si vous retombez systématiquement sur le relais, même chez vous, les suspects habituels sont un modem de fournisseur d’accès qui fait du NAT symétrique, du CGNAT IPv4 sur votre connexion domestique (plus courant qu’on ne le croit chez les revendeurs de fibre) ou un pare-feu trop zélé qui bloque l’UDP entrant. Notre guide pour réduire la latence du bureau à distance passe en revue les coupables habituels, et la page connexion directe en réseau local est le chemin rapide si les deux appareils sont sur votre réseau.

Des chiffres de performance en conditions réelles

Pour résumer, voici les chiffres de latence que nous mesurons en production sur les différents chemins qu’une session Remio peut emprunter :

• P2P direct en réseau local : 1–5 ms de RTT réseau. De bout en bout (événement de saisie jusqu’à la mise à jour du pixel) : environ 8 ms de traitement (le reste étant la cadence de rafraîchissement 60 Hz de votre propre écran), le reste de la chaîne coopérant.
• Wi-Fi sur le même réseau avec sauts supplémentaires : 5–10 ms de RTT réseau.
• Relais TURN, régional : 30–80 ms de RTT réseau.
• Relais TURN, entre régions : 80–200 ms de RTT réseau.
• Cellulaire 4G/5G, P2P par hole punching : 40–100 ms de RTT réseau.

Ces valeurs correspondent à celles des benchmarks de Remio et expliquent pourquoi nous fixons le seuil réseau local/WAN à 15 ms de RTT — il sépare nettement les chemins directs de tout relais (30 ms minimum) ou chemin cellulaire (40 ms minimum), avec très peu de faux positifs.

La traversée de NAT est l’un de ces sujets où les protocoles sont simples pris isolément, mais où la combinatoire est épineuse. La plupart des utilisateurs n’auront jamais besoin de savoir qu’ICE, STUN et TURN existent — ils vivront simplement une application qui se connecte vite de n’importe où à n’importe où. Les protocoles font leur travail quand on ne les remarque pas. Quand vous les remarquez — une session met un instant de trop, ou « Direct » devient « Relais » — vous disposez maintenant du modèle mental.

Pour en savoir plus sur la chaîne native de Remio et les choix qui transforment 1–5 ms de latence réseau en environ 8 ms de traitement (le reste étant la cadence de rafraîchissement 60 Hz de votre propre écran), lisez pourquoi le natif compte. Pour le modèle de menaces sur les chemins relayés, consultez le livre blanc sur la sécurité. Ou parcourez simplement les fonctionnalités et téléchargez Remio pour le sentir fonctionner.