VPN sur plusieurs chemins : quatre garanties que l’opérateur doit fournir

Ajoutez un second lien WAN et les tunnels montent, mais une copie de fichier se bloque encore lorsqu’un chemin vacille. Les liens sont sains et les processus VPN tournent ; ce qui manque, c’est un contrat entre l’opérateur et le tunnel. Plusieurs sockets ne se comportent pas automatiquement comme une seule connexion, et l’application au-dessus ne fait pas la différence tant que la livraison casse. Chaque partie du contrat correspond à une panne testable, et c’est ce qui le rend utile.

Écrivez ce contrat avant de choisir un produit. Il comporte quatre parties : le flux que reçoit le VPN, la manière dont l’opérateur récupère les données manquantes, l’identité de point de terminaison qui survit à un changement de chemin, et le comportement de l’ensemble lorsqu’un chemin tombe.

Le symptôme : les liens sont actifs, la session casse quand même

Un graphique de supervision qui montre les deux liens actifs prouve seulement que chaque chemin peut transporter du trafic. Il ne prouve pas que le VPN voit un seul flux ordonné, qu’un paquet perdu sur un chemin est récupéré sur un autre, ni que le pair sait encore à quelle session il parle. Le reste du contrat couvre ce que ce graphique ne peut pas montrer.

Quand un transfert se bloque, déterminez si l’opérateur a continué à livrer sur le chemin survivant. Si la session meurt alors que le second lien est inactif, l’opérateur ne l’a jamais utilisé. Si la session survit mais que les données arrivent dans le désordre ou dupliquées, l’opérateur déplace des paquets sans contrat au niveau de la connexion. Les horodatages des deux côtés le montrent généralement.

Cette distinction décide du correctif. Un problème de routage ou de politique exige un changement de sélection de chemin ; une couche d’ordre et de reprise absente exige un autre transport, pas un tampon plus gros.

Garantie un : un flux d’octets au niveau de la connexion

Si le VPN a besoin d’un flux ordonné et fiable, l’opérateur doit identifier des plages d’octets au-dessus du chemin individuel. Chaque connexion TCP sous-jacente ne numérote que ses propres segments, si bien qu’un récepteur ne peut pas réordonner entre chemins avec ces seuls numéros.

Multipath TCP est l’exemple normalisé. Il présente un flux d’octets fiable tout en coordonnant plusieurs sous-flux TCP, avec mappage de séquence et acquittement au niveau des données. L’application lit un flux, pas le sous-flux qui a livré un morceau en premier.

Sous Linux, MPTCP s’active par socket via IPPROTO_MPTCP. Quand la négociation ne peut pas utiliser le comportement multipath, le repli documenté est TCP ordinaire, ce qui signifie que l’application peut continuer sur un seul chemin sans jamais utiliser le second. Vérifiez le comportement réellement négocié par le socket déployé au lieu de supposer que le réglage du noyau s’applique.

Garantie deux : ordre, duplication et reprise

Des chemins aux délais et taux de perte différents obligent l’opérateur à mettre en tampon, réordonner et retransmettre. Le contrat doit indiquer la quantité de tampon autorisée, la contre-pression vue par l’application et le chemin qui porte une retransmission.

Un chemin qui reste connecté mais cesse de livrer est plus difficile qu’une fermeture propre. L’opérateur doit le détecter, déplacer les données en attente et éviter d’attendre indéfiniment un segment qui n’arrivera jamais. Un simple contrôle « les deux liens sont actifs » ne couvre pas cet état.

La duplication a besoin de sa propre règle. Envoyer la même charge utile sur les deux chemins peut améliorer la latence, mais le récepteur doit supprimer la copie avant qu’elle n’atteigne le VPN. L’anti-rejeu IPsec est facultatif par association de sécurité et vérifie les numéros de séquence ; une couche de duplication qui réordonne ou rejoue des paquets peut le déclencher ou masquer le problème jusqu’à la chute du tunnel.

Garantie trois : identité de point de terminaison et jonction de chemin

Le pair a besoin d’un moyen stable de reconnaître la session lorsqu’un nouveau chemin apparaît. Si chaque chemin est authentifié comme un tunnel distinct, le VPN peut voir deux sessions au lieu d’une. Si l’opérateur joint les chemins sous une seule session, il doit définir comment le nouveau chemin est authentifié et ce qu’il advient de l’ancien.

Notez quelles adresses et quels identifiants restent stables : le point de terminaison du tunnel, l’identifiant de session de l’opérateur et tout proxy intermédiaire. Un proxy ajoute une frontière de disponibilité et de confiance supplémentaire même s’il ne voit jamais la charge utile protégée.

C’est aussi là que réside la politique. Un chemin qui rejoint depuis un réseau inattendu peut être techniquement valide et violer malgré tout le modèle de confiance prévu. Décidez si les nouveaux chemins sont acceptés automatiquement, exigent une authentification ou sont refusés.

Garantie quatre : comportement borné en cas de panne

Testez une panne complète de chemin, pas seulement un chemin lent. Le chemin survivant doit porter la session sans croissance illimitée de la mémoire, et la reprise ne doit pas dépendre d’une minuterie plus longue que ce que l’application tolère. Quand le chemin défaillant revient, l’opérateur doit décider de rééquilibrer ou de laisser le flux où il est.

Fixez des limites de tampon, de retransmission et de nombre de chemins, puis vérifiez-les sous perte, réordonnancement, duplication et déséquilibre de délai. La bande passante agrégée est le chiffre le moins intéressant ici ; la continuité de livraison et les bornes mémoire constituent le contrat.

Gardez l’état de reprise de l’opérateur séparé de l’état cryptographique du VPN. Une couche de fiabilité maison qui remplace une authentification ou un chiffrement établis n’est pas un raccourci, et réutiliser des numéros de séquence entre couches rend la protection contre le rejeu et le diagnostic peu fiables.

Acceptez l’opérateur avec un plan de test

Écrivez les quatre garanties sous forme de contrôles réussite ou échec : un flux ordonné, une reprise définie, une identité de session stable, un comportement de panne borné. Exécutez chaque contrôle avec un chemin dégradé, puis avec un chemin retiré.

Un seul transfert de fichier réussi à travers un changement de chemin ne prouve pas un fonctionnement continu. Répétez le transfert en basculant le chemin préféré, et inspectez à la fois la vue de l’opérateur et les compteurs du VPN. Si les deux ne s’accordent pas sur le chemin qui a porté les données, le contrat n’est pas encore observable.

Conservez la matrice validée avec le déploiement. Elle indique à l’ingénieur suivant quel comportement a été promis, quelles combinaisons de chemins ont été testées et quel mode de panne reste non pris en charge, sans une nouvelle série de suppositions à partir des voyants d’état des liens.