Aux premiers temps d'Internet, établir une liaison directe entre deux machines consistait simplement à envoyer des paquets vers une adresse IP publique. Dans l'écosystème IPv4 actuel, cette accessibilité directe de bout en bout a presque entièrement disparu. La généralisation de la traduction d'adresses réseau (NAT), du CGNAT opérateur (Carrier-Grade NAT, RFC 6598) et des pare-feu avec suivi d'état isole la majorité des postes de travail, téléphones mobiles et réseaux locaux derrière de multiples couches d'adresses privées.

Lorsque deux équipements situés derrière des passerelles NAT distinctes tentent d'établir un canal chiffré direct—que ce soit pour le partage de fichiers en pair-à-pair (P2P), la voix sur IP ou les réseaux maillés VPN—ils ne peuvent pas simplement se mettre en écoute et attendre les connexions entrantes. Les paquets reçus sans correspondance dans la table d'état locale sont immédiatement rejetés par les pare-feu intermédiaires.

Pour surmonter cet obstacle, l'ingénierie réseau a conçu les techniques de traversée NAT (NAT Traversal), articulant la découverte d'adresses publiques, le poinçonnage UDP (UDP hole punching) et le relais de secours au moyen des protocoles STUN (RFC 8489), TURN (RFC 8656) et ICE (RFC 8445).

+--------------------------------------------------------------------------+
|                 LE DILEMME DE LA TRAVERSÉE NAT ET DU POINÇONNAGE         |
|                                                                          |
|  [ Pair A ]                                                   [ Pair B ] |
|  192.168.1.50                                                 10.0.0.85  |
|      |                                                            |      |
|      v                                                            v      |
| [ Passerelle NAT A ]                                      [ Passerelle B]|
| IP WAN: 203.0.113.10                                      IP WAN: 198.51 |
|      |                                                            |      |
|      |    Paquet entrant non sollicité (REJETÉ : aucun état NAT)  |      |
|      +------------------------- X <-------------------------------+      |
|                                                                          |
|      |                 Signalisation sortante coordonnée          |      |
|      +----------> [ Serveur de coordination STUN public ] <-------+      |
|                                                                          |
|      |               Transmission sortante simultanée             |      |
|      +=========================> [ DIRECT ] <=====================+      |
|                        Tunnel UDP direct établi                          |
+--------------------------------------------------------------------------+

Les quatre variantes de NAT et leur filtrage de paquets

Comprendre pourquoi les connexions directes échouent exige d'analyser la façon dont les passerelles associent les adresses IP privées et ports locaux aux points de terminaison publics (RFC 4787) :

1. NAT à cône plein (Full Cone NAT)

Dès qu'un hôte interne (192.168.1.50:5000) émet un paquet vers l'extérieur, la passerelle lui associe un port public constant (203.0.113.10:45000). N'importe quel hôte distant sur Internet peut alors transmettre des paquets vers cette adresse, et la passerelle les redirigera vers la machine interne. Bien qu'idéale pour le P2P, cette configuration est rarement adoptée pour des motifs de sécurité.

2. NAT à cône restreint en adresse (Restricted Cone NAT)

La passerelle maintient l'association de port externe, mais n'autorise l'entrée des paquets que s'ils proviennent d'une adresse IP vers laquelle l'hôte interne a déjà envoyé un paquet. Si le pair A a envoyé des données au pair B (198.51.100.25), le pair B peut répondre depuis n'importe quel port. Les paquets émanant d'autres adresses IP sont écartés.

3. NAT à cône restreint en port (Port-Restricted Cone NAT)

Le filtre impose une correspondance stricte à la fois sur l'adresse IP et sur le port distant. Si le pair A a contacté 198.51.100.25:51820, la passerelle n'acceptera que les paquets retour provenant rigoureusement de 198.51.100.25:51820. Tout paquet issu du port 51821 sera rejeté.

4. NAT symétrique (Symmetric NAT)

Le NAT symétrique constitue le défi technique le plus complexe pour les liaisons directes. Contrairement aux modèles à cône, il attribue un port externe totalement différent pour chaque couple IP:port de destination unique.

Si le pair A interroge un serveur STUN (1.1.1.1:3478), la passerelle ouvre le port externe 45000. Mais dès que le pair A tente d'émettre vers le pair B (198.51.100.25:51820), la passerelle lui assigne un nouveau port aléatoire (par exemple 45001 ou 58291). En raison de cette variation perpétuelle, le pair B ne peut pas déduire le port réel du pair A d'après la réponse STUN.

La suite de protocoles de traversée : STUN, TURN et ICE

Les architectures réseau s'appuient sur trois protocoles standardisés pour cartographier les liaisons et établir des canaux de communication :

+-------------------------------------------------------------------------+
|                  PROCESSUS DE DÉCOUVERTE DES CANDIDATS ICE              |
|                                                                         |
|  [ Interface locale ] -------> Candidat hôte : 192.168.1.50:51820       |
|                                                                         |
|  [ Requête STUN ] -----------> Candidat réflexif : 203.0.113.10:45000   |
|                                (Découvert via XOR-MAPPED-ADDRESS)       |
|                                                                         |
|  [ Allocation TURN ] --------> Candidat relais : 198.51.100.1:60000     |
|                                (Serveur de secours garanti)             |
|                                                                         |
|  Échange des candidats via canal de contrôle -> Classement par priorité |
|  Contrôles bidirectionnels STUN -> Établissement du canal direct        |
+-------------------------------------------------------------------------+

1. STUN : Outils de traversée pour NAT (RFC 8489)

Le protocole STUN fonctionne selon un modèle simple de requête-réponse. Un terminal situé dans un réseau privé transmet un message Binding Request à un serveur public STUN sur le port UDP 3478.

Le serveur observe l'adresse IP source et le port d'arrivée, puis renvoie ces coordonnées au client dans l'attribut XOR-MAPPED-ADDRESS. En comparant son socket d'origine (192.168.1.50:51820) à cette adresse réflexive (203.0.113.10:45000), la machine cliente détermine son adresse publique et son comportement NAT.

2. TURN : Relais à travers les passerelles NAT (RFC 8656)

Lorsque les deux extrémités se situent derrière des passerelles symétriques ou des pare-feu d'entreprise stricts, le poinçonnage direct devient impraticable. TURN fournit alors une solution de relais garantie.

Le client s'authentifie auprès du serveur TURN et demande l'allocation d'une adresse de transit (Allocate). Le pair distant transmet ses paquets à cette adresse, et le serveur les achemine au destinataire final. Si TURN assure une liaison opérationnelle en toutes circonstances, il engendre des coûts de bande passante et augmente la latence de transit.

3. ICE : Établissement de connectivité interactive (RFC 8445)

ICE agit comme le chef d'orchestre fédérant STUN et TURN :

  1. Collecte des candidats (Candidate Gathering) : Chaque terminal recense toutes ses adresses potentielles : adresses locales de cartes physiques et virtuelles (host), adresses publiques réflexives (srflx) et points de terminaison de relais (relay).
  2. Échange de signalisation : Les pairs s'échangent leurs listes respectives via un canal de contrôle sécurisé.
  3. Vérification de connectivité : Les machines forment des paires, les ordonnent par priorité (en privilégiant les liaisons directes) et envoient des paquets de test STUN simultanés.
  4. Sélection : Dès qu'une liaison directe bidirectionnelle est validée, ICE y bascule l'intégralité du trafic applicatif.

La mécanique du poinçonnage UDP (UDP Hole Punching)

Le principe du poinçonnage UDP repose sur l'exploitation des tables de suivi d'état des routeurs NAT.

Lorsqu'un terminal interne envoie un paquet UDP vers l'extérieur, le routeur NAT crée une entrée d'état temporaire :

[Interne : 192.168.1.50:51820] <-> [Externe : 203.0.113.10:45000] <-> [Destination : 198.51.100.25:51820]

Cette règle d'état reste active pendant une durée de temporisation allant généralement de 30 à 120 secondes. Tant que la session existe, les paquets retour en provenance de la destination sont autorisés à traverser le pare-feu.

La séquence de poinçonnage simultané

Étape 1 : Le pair A émet vers l'adresse IP et le port publics du pair B.
          Le NAT A crée un état d'autorisation pour le pair B.
          Le paquet arrive au NAT B et est rejeté (aucun état actif).

Étape 2 : Au même moment, le pair B émet vers les coordonnées du pair A.
          Le NAT B crée un état d'autorisation pour le pair A.
          Le paquet arrive au NAT A.

Étape 3 : Le NAT A vérifie sa table d'état : le paquet correspond exactement
          au flux que le pair A vient d'initier ! Le NAT A laisse passer.

Étape 4 : Le pair A répond. Le NAT B reconnaît l'état valide et laisse entrer le paquet.
          Le canal UDP direct est ouvert dans les deux directions.

Puisque les deux passerelles estiment que le trafic entrant constitue la réponse légitime à une requête interne préalable, les deux accès virtuels demeurent ouverts, garantissant des échanges directs sans intermédiaire.

VPN maillés pair-à-pair vs architecture Client-Serveur

Le paysage des tunnels chiffrés présente deux approches fondamentales :

Critère VPN Maillés P2P (Tailscale / ZeroTier) Architecture Client-Serveur (VPNRice)
Topologie de liaison Réseau décentralisé entre l'ensemble des nœuds Réseau de passerelles Anycast haut débit
Traversée NAT requise Poinçonnage STUN/ICE obligatoire pour chaque liaison Aucune traversée requise ; simple flux sortant
Gestion du NAT symétrique Dépendance aux relais DERP/TURN, latence accrue Routage Anycast direct sans intermédiaire
Confidentialité IP Les nœuds voient directement les IP résidentielles Les IP réelles sont protégées derrière les passerelles
Maintien de session Risque de rupture lors de la mobilité cellulaire Signal Keepalive préservant l'état en continu

Dans un modèle maillé, relier 10 appareils nécessite d'administrer jusqu'à 45 tunnels individuels. Dès qu'un appareil bascule sur un réseau 4G/5G soumis à un CGNAT symétrique, le poinçonnage direct échoue souvent, redirigeant le flux vers des serveurs relais. De surcroît, la liaison P2P dévoile l'adresse IP personnelle aux autres participants du groupe.

L'architecture Client-Serveur résout intrinsèquement la traversée NAT. Étant donné que le serveur VPN dispose d'une adresse IP publique fixe avec des ports ouverts permanents, la passerelle locale du client traite le tunnel comme un flux sortant classique, autorisant naturellement les réponses sans configuration complexe.

L'utilité du paramètre PersistentKeepalive dans WireGuard

Dans les liaisons chiffrées, la principale source d'interruption découle de la fermeture prématurée des sessions par les passerelles NAT en cas d'inactivité.

Plusieurs routeurs et opérateurs mobiles effacent les entrées d'état UDP après seulement 30 secondes de silence. Une fois la table vidée, le serveur distant ne peut plus transmettre de données vers le client tant que ce dernier n'émet pas un nouveau paquet.

WireGuard surmonte cet inconvénient au moyen de la directive PersistentKeepalive :

[Interface]
PrivateKey = aaaaaa...
Address = 10.8.0.2/24
DNS = 10.8.0.1

[Peer]
PublicKey = bbbbbb...
Endpoint = 198.51.100.10:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25

En configurant PersistentKeepalive = 25, le terminal expédie automatiquement un message authentifié vide de 32 octets toutes les 25 secondes d'inactivité. Cette impulsion légère maintient l'ouverture de la session NAT à travers tous les pare-feu sans impacter l'autonomie de la batterie.

Stabilité réseau et protection des données dans VPNRice

L'infrastructure VPNRice applique les principes avancés du routage de niveau 3 au cœur du protocole RiceGuard. Grâce à un maillage de serveurs Anycast, les terminaux établissent des liaisons sortantes directes et fiables, éliminant les complications liées à la traduction d'adresses réseau.

Le protocole RiceGuard intègre un mécanisme intelligent de temporisation Keepalive qui adapte la fréquence des signaux aux contraintes des réseaux mobiles et professionnels. Parallèlement, l'adresse IP d'origine et les identifiants réseau de chaque appareil demeurent protégés derrière nos passerelles réparties, empêchant toute corrélation externe.

Les techniques de traversée NAT ont considérablement évolué, passant de l'ouverture manuelle de ports à une coordination cryptographique sophistiquée portée par STUN, TURN et ICE. Si le poinçonnage pair-à-pair constitue une prouesse technique, l'architecture Client-Serveur offre une stabilité de transport et une confidentialité remarquables au quotidien. Préservez la réactivité et la fiabilité de vos communications réseau avec Télécharger VPNRice.