Multipath TCP (MPTCP) vs VPN Roaming : basculement fluide entre Wi-Fi et 5G

Les environnements de réseaux mobiles sont marqués par une instabilité physique permanente. Qu'ils se déplacent dans des bureaux, des couloirs de transports urbains ou des zones résidentielles, les utilisateurs de smartphones et d'ordinateurs portables basculent constamment entre points d'accès Wi-Fi et antennes cellulaires 5G. Dans une pile réseau classique, ce « basculement vertical » (vertical handover) entraîne de fréquentes coupures de session, l'interruption des appels VoIP, le gel des terminaux SSH et l'arrêt brutal des transferts de fichiers.

Pour résoudre ce défi persistant, deux architectures majeures ont vu le jour : Multipath TCP (MPTCP, standardisé dans la RFC 8684) et les mécanismes de roaming des VPN modernes au niveau de la couche réseau (Layer 3). Tandis que MPTCP cherche à coordonner plusieurs sous-flux directement au niveau de la couche transport, les VPN récents (fondés sur WireGuard et le moteur RiceGuard de VPNRice) traitent la mobilité au niveau réseau grâce au suivi cryptographique sans état des extrémités. L'analyse comparée de leur fonctionnement, de leurs contraintes réelles et de leur résistance face aux boîtiers intermédiaires (middleboxes) démontre pourquoi le tunnel Layer 3 reste la solution la plus robuste pour la connectivité nomade.

La réalité des réseaux mobiles : pourquoi les connexions se rompent

Les échanges sur Internet reposent historiquement sur la rigidité du quadruplet caractéristique du protocole TCP :

       [ Adresse IP source ]  :  [ Port source ]
                               ↕
     [ Adresse IP destination ] : [ Port destination ]

Lorsqu'un terminal mobile quitte la couverture du Wi-Fi d'entreprise (192.168.1.45, routé via NAT sous l'IP publique 203.0.113.10) pour passer sur le réseau cellulaire 5G (198.51.100.82), l'adresse IP source attribuée au terminal change instantanément. Pour le serveur distant, les paquets provenant de cette nouvelle adresse IP appartiennent à une session inconnue et non autorisée.

Le protocole TCP standard ne permettant pas de réassigner un socket actif vers une nouvelle adresse IP sans fermer la liaison :

Le serveur distant persiste à transmettre ses paquets d'acquittement (ACK) à l'ancienne adresse Wi-Fi désormais inaccessible.
Le système d'exploitation du client ne recevant plus les numéros de séquence attendus, les temporisateurs de retransmission TCP s'affolent.
La connexion finit par expirer, contraignant les applications (SSH, flux vidéo, WebSockets) à relancer l'intégralité de la poignée de main (SYN → SYN-ACK → ACK), à renégocier les clés de chiffrement TLS et à soumettre à nouveau les identifiants d'accès.

Fonctionnement de Multipath TCP (MPTCP) : des sous-flux au niveau transport

Multipath TCP (RFC 8684) prévient la rupture des sockets en découplant le flux applicatif des interfaces réseau physiques :

┌─────────────────────────────────────────────────────────────┐
│                      Couche applicative                     │
│                  (Sockets Posix standards)                  │
└──────────────────────────────┬──────────────────────────────┘
                               │
┌──────────────────────────────▼──────────────────────────────┐
│                    Multipath TCP (MPTCP)                    │
│    Gestion des jetons, ordonnancement des sous-flux, tri    │
└──────────────┬──────────────────────────────┬───────────────┘
               │                              │
┌──────────────▼──────────────┐┌──────────────▼───────────────┐
│     Sous-flux TCP 1 (Wi-Fi) ││      Sous-flux TCP 2 (5G)    │
│  Src : 192.168.1.45 (wlan0) ││  Src : 10.42.0.12 (modem 5G) │
└─────────────────────────────┘└──────────────────────────────┘

Plutôt que d'être rattaché à une seule adresse IP, MPTCP présente un socket unifié à l'application tout en gérant plusieurs sous-flux TCP distincts sur les cartes réseau actives.

Négociation initiale via MP_CAPABLE : Lors de l'ouverture de session, le client transmet l'option MP_CAPABLE dans son paquet SYN. Si le serveur distant prend en charge MPTCP, il répond favorablement en échangeant un jeton d'authentification de 64 bits.
Ajout dynamique avec MP_JOIN : Dès qu'une seconde interface réseau devient opérationnelle (comme la connexion 5G), le client transmet un paquet MP_JOIN sur ce nouveau chemin en référençant le jeton de la session principale.
Migration transparente des flux : Si la liaison Wi-Fi s'affaiblit, MPTCP achemine les paquets sur le sous-flux 5G. L'ordre des données est maintenu au niveau global (Data Sequence Signal - DSS), permettant au serveur de reconstituer le flux d'origine sans impact sur le logiciel applicatif.

L'écueil des boîtiers intermédiaires : les obstacles réels à MPTCP

Bien que séduisant sur le plan architectural, le protocole MPTCP se heurte dans la pratique aux comportements invasifs des boîtiers réseau intermédiaires (middleboxes) :

[ Client MPTCP ] ──► [ Pare-feu d'entreprise / CGNAT opérateur ] ──► [ Serveur Web ]
                     (Inspecte l'en-tête TCP Option 30)
                     ├── Supprime les options inconnues ────► (Rétrograde en simple TCP)
                     ├── Altère les numéros de séquence ────► (Échec de validation DSS)
                     └── Bloque les paquets anormaux ───────► (Rupture de connexion)

Suppression systématique des options TCP : De nombreux pare-feux professionnels, passerelles CGNAT et équipements d'inspection DPI retirent d'office les options TCP qu'ils ne reconnaissent pas. MPTCP dépendant entièrement de l'option TCP 30, son élimination rétrograde immédiatement la connexion en TCP standard, supprimant tout bénéfice de mobilité.
Exigence d'un support bilatéral : MPTCP ne fonctionne que si le poste client et le serveur cible exécutent tous deux un noyau compatible. La grande majorité des serveurs web, passerelles d'API et infrastructures cloud mondiales utilisent des noyaux Linux conventionnels sans MPTCP actif.
Altération des numéros de séquence : Plusieurs équipements de transit modifient délibérément les numéros de séquence TCP pour prévenir les attaques SYN Flood. Ce comportement brise l'alignement interne de MPTCP (Data Sequence Mapping), provoquant des erreurs d'intégrité et la fermeture brutale des sous-flux.

Le roaming VPN moderne : la réponse de WireGuard et RiceGuard

Les VPN Layer 3 modernes neutralisent la fragilité des options TCP en traitant la mobilité directement à la racine de la couche réseau. WireGuard (et le protocole RiceGuard au cœur de VPNRice) s'appuie sur le roaming cryptographique de point de terminaison sans état (Stateless Cryptographic Endpoint Roaming) :

[ Poste mobile client ]                              [ Passerelle VPN (RiceGuard) ]
          │                                                       │
          ├────── (Paquet UDP chiffré via Wi-Fi : 192.168.1.45) ─►│
          │       Signé avec la clé publique Curve25519           │ (Table noyau : Peer -> 192.168.1.45)
          │                                                       │
   [ Déconnexion Wi-Fi ]                                          │
   [ Connexion 5G ]                                               │
          │                                                       │
          ├────── (Paquet UDP chiffré via 5G : 198.51.100.82) ───►│
          │       Signé avec la même clé de session active        │ (Le noyau met à jour de façon
          │                                                       │  atomique : Peer -> 198.51.100.82)
          │◄───── (Réponse UDP envoyée directement à 198.51.100.82)┤

Dans ce modèle, les applications de l'appareil communiquent exclusivement au travers d'une interface réseau virtuelle (comme tun0 ou wg0), pourvue d'une adresse IP privée immuable (par exemple 10.8.0.2) :

Immunité totale des sockets applicatifs : Comme les applications échangent via la carte réseau virtuelle statique, leurs sockets TCP/UDP internes ne subissent aucun changement d'IP. Une session SSH ou un échange VoIP s'exécutant dans le tunnel ne perçoit jamais les sauts d'interfaces physiques.
Mise à jour atomique de l'adresse UDP distante : Lors du basculement vers la 5G, le client VPN achemine simplement son paquet UDP chiffré suivant via l'interface mobile. À réception, la passerelle VPN déchiffre la charge utile et authentifie la signature. Puisque le paquet est validé par la clé publique de 32 octets du client, le noyau du serveur met à jour instantanément la table de routage vers la nouvelle adresse IP et le nouveau port 5G.
Aucun délai de renégociation : La mise à jour de la table de transfert s'effectue en une fraction de microseconde au sein du noyau, sans réémission de clé ni temps de latence.

Gestion de l'agrégation de liens : réordonnancement et bufferbloat

Au-delà du basculement consécutif, certains besoins industriels impliquent l'agrégation simultanée de plusieurs liaisons (émettre à la fois sur Wi-Fi et 5G). Utiliser plusieurs cartes réseau physiques en parallèle engendre des contraintes techniques particulières :

Retards liés au réordonnancement des paquets : Les réseaux Wi-Fi et 5G présentent des temps de propagation très dissemblables. Si le paquet 1 transite par le Wi-Fi (15 ms de latence) et le paquet 2 par la 5G (45 ms de latence), le premier arrivera bien avant le second. Sans algorithme de réordonnancement, la pile TCP destinataire interprète cette désynchronisation comme une perte de paquets et réduit drastiquement son débit.
Problématique du Bufferbloat : Les liaisons cellulaires exploitent de volumineux tampons mémoire pour amortir les variations radio. Lors d'une agrégation, ces tampons gonflent artificiellement la latence, retardant les flux interactifs.
La réponse du VPN Layer 3 : Le moteur RiceGuard gère la répartition de charge grâce à une analyse continue des canaux. En évaluant en temps réel la gigue et la perte de paquets de chaque interface, le tunnel réserve la ligne à plus faible latence au trafic prioritaire (frappes SSH, requêtes DNS, voix) tout en exploitant la liaison secondaire pour le transfert massif ou le secours immédiat.

Tableau comparatif : MPTCP vs Roaming VPN Layer 3

Critère technique	Multipath TCP (MPTCP)	Roaming VPN Layer 3 (RiceGuard)
Couche d'action	Layer 4 (Transport / Option TCP 30)	Layer 3 (Couche réseau / IP encapsulé dans UDP)
Protocoles supportés	Flux TCP exclusivement (Pas d'UDP/DNS)	Universel (Couverture intégrale TCP, UDP, ICMP)
Dépendance serveur	Le serveur web final doit supporter MPTCP	Seule la passerelle VPN doit être compatible
Traversée Middlebox	Fragile (Options supprimées par les pare-feux)	Robuste (Paquets UDP chiffrés standards)
Temps de basculement	Dépend de l'initialisation des sous-flux	Instantané (Mise à jour atomique dans le noyau)
Transparence logicielle	Élevée (Compatible API Posix standard)	Totale (La carte virtuelle isole les applications)
Protection métadonnées	Nulle (IP et ports visibles en clair)	Complète (Toutes les destinations sont masquées)

Bonnes pratiques pour une connectivité mobile ininterrompue

Pour garantir une expérience réseau continue à travers des infrastructures physiques hétérogènes, suivez ces recommandations :

Protégez les sockets derrière une carte réseau virtuelle : Acheminez l'ensemble des flux nomades au travers d'un tunnel VPN Layer 3 authentifié. L'ancrage des applications sur une interface virtuelle prévient toute coupure de session lors des transitions réseau.
Privilégiez les tunnels UDP sans état : Bannissez l'encapsulation de flux au sein de tunnels TCP externes (comme l'ancien protocole OpenVPN sur TCP). L'imbrication de TCP dans TCP provoque un effondrement complet du débit (TCP Meltdown) dès que des paquets sont perdus pendant le basculement.
Configurez des intervalles de Keepalive réguliers : Sur les clients VPN mobiles, activez l'envoi de trames de maintien d'activité toutes les 20 à 25 secondes. Cela préserve les tables d'états NAT des opérateurs mobiles, garantissant la réception immédiate des notifications descendantes.
Verrouillez la résolution DNS au sein du tunnel : Assurez-vous que l'ensemble des requêtes DNS soit traité exclusivement par l'interface chiffrée. Lors du passage d'un réseau Wi-Fi à un réseau cellulaire, les serveurs DNS transmis par DHCP ne doivent en aucun cas court-circuiter le tunnel.

Bien que séduisant sur le plan théorique, Multipath TCP souffre des blocages répétés des boîtiers intermédiaires et d'un déploiement restreint sur les serveurs web. Le roaming VPN Layer 3 apporte une réponse universelle et performante, permettant aux appareils nomades de naviguer sereinement entre Wi-Fi et 5G sans la moindre déconnexion ni compromis sur la confidentialité.

Télécharger VPNRice.