Un tunnel achète une topologie, pas du chiffrement ni de la latence

L’hypothèse est qu’un tunnel est un fil privé et rapide : on le construit, le trafic à l’intérieur est chiffré, le chemin est plus court et la liaison se comporte comme un câble entre deux sites. Chaque partie de cette hypothèse est une propriété distincte, et le tunnel ne fournit que la première chose qu’on lui a demandée, à savoir un chemin logique. Tout le reste doit être choisi et configuré volontairement. Confondre les propriétés, c’est ainsi qu’une conception finit avec une liaison chiffrée que personne ne peut diagnostiquer et une promesse de latence que personne ne peut tenir.

Le mythe : un tunnel, trois garanties

Un tunnel fait une chose de manière fiable. Il fait en sorte que deux extrémités qui ne sont pas directement connectées se comportent comme si elles étaient adjacentes pour un certain usage, tandis que le réseau intermédiaire transporte les paquets externes. C’est un changement de topologie, et il est réellement utile en soi.

Le chiffrement, le transport de protocoles et l’isolation du réacheminement sont des décisions distinctes superposées. Un tunnel GRE n’en a aucune des trois au sens cryptographique, et un tunnel IP-in-IP est une conception valable sans aucune confidentialité. Ni l’un ni l’autre n’est une erreur ; ce sont des tunnels qui font exactement ce que font les tunnels. L’étiquette sur le schéma ne dit pas quelles propriétés sont présentes.

Une fois les propriétés séparées, les questions deviennent répondables : ce tunnel transporte-t-il une adjacence de routage, transporte-t-il des trames, masque-t-il les adresses internes, promet-il quelque chose sur le délai ? Ce sont quatre réponses différentes avec quatre conséquences de configuration différentes.

Ce que le tunnel ajoute réellement à la carte

Les extrémités obtiennent un chemin qu’elles n’avaient pas auparavant. Que ce chemin se comporte comme un saut routé ou comme un segment Ethernet dépend entièrement de l’encapsulation, et la différence change ce que les deux sites peuvent en faire. Un tunnel routé vous donne un prochain saut et un préfixe ; une extension Ethernet vous donne un comportement de diffusion et un domaine de panne bien plus grand.

Un tunnel IP ne rend pas automatiquement le site distant partie du même sous-réseau, et il ne fait pas fonctionner un protocole de routage à travers lui, sauf si l’implémentation prend en charge cette adjacence. Le multicast est une autre question distincte avec sa propre réponse.

ip -d link show type gre
ip route get 10.20.0.5
traceroute -n -T -p 443 10.20.0.5
mtr -n --report -c 20 10.20.0.5

Ces commandes répondent à différentes parties de la question. La première indique quel type d’interface existe, la deuxième indique quel chemin le noyau choisirait, et les deux dernières montrent le comportement réel du sous-jacent plutôt que la promesse de l’étiquette.

Le transport est une décision distincte de l’accessibilité

Un tunnel peut transporter un protocole que le sous-jacent ne transmet pas. IPv6 sur un chemin IPv4 est le cas classique, et cela fonctionne parce que les extrémités comprennent les deux familles tandis que les routeurs entre elles n’ont qu’à livrer les paquets externes. Le sous-jacent a besoin d’un chemin fonctionnel vers l’extrémité du tunnel et rien de plus.

Les extrémités, en revanche, ont besoin d’un support complet : réacheminement, adresses et une application qui utilise réellement la famille interne. Attribuer un préfixe IPv6 à un tunnel ne rend pas un service qui ne fonctionne qu’en IPv4 accessible via IPv6, et ne rend pas le sous-jacent double pile.

Le transport de trames est un engagement plus lourd que le transport de protocoles. Étendre un domaine de diffusion sur un tunnel déplace avec lui le comportement de l’arbre couvrant, ARP et la propagation des pannes, ce qui est une décision de conception et non un commutateur de fonctionnalité.

L’isolation n’est pas la confidentialité

Les VPN de fournisseur gardent les routes et le trafic des clients dans des contextes de réacheminement séparés, et cette séparation est réelle et précieuse. Ce n’est pas du chiffrement. La spécification BGP/MPLS VPN dit explicitement que sa confidentialité vient du modèle de réacheminement et non de la cryptographie, et c’est exactement la distinction qui se perd dans une diapositive qui dit simplement VPN.

Si vous avez besoin de confidentialité, vous avez besoin d’un mécanisme cryptographique avec authentification et gestion des clés, et vous devez savoir où il se termine. Un tunnel qui assure la séparation et un tunnel qui assure le chiffrement peuvent être le même tunnel, mais seulement quand quelqu’un a configuré les deux.

La conséquence pratique est que « c’est dans un VPN » répond à une question sur le contexte de routage et ne vous dit rien sur qui peut lire les octets sur le chemin. Deux équipes peuvent avoir toutes deux raison et néanmoins décrire des choses différentes. Quand la question de sécurité se pose, demandez où se termine la cryptographie et ce qui authentifie les pairs, pas si un tunnel existe.

La latence et la QoS suivent le sous-jacent

Une arête logique n’est pas un chemin physique plus court. Les paquets externes traversent toujours les mêmes liens, files d’attente et fournisseurs, et l’encapsulation ajoute une surcharge par paquet plus un traitement aux deux extrémités. Un tunnel peut être rapide parce que le sous-jacent est bon, jamais parce qu’il est un tunnel.

Le traitement de la qualité de service est pire que cela, car il dépend de domaines administratifs que vous ne contrôlez peut-être pas. Les marquages internes doivent être mappés délibérément aux marquages externes, et chaque fournisseur sur le chemin doit offrir le traitement que vous attendez. Le chiffrement ne crée pas de priorité ; il masque le champ qu’un équipement intermédiaire aurait pu utiliser pour classer le flux.

Mesurez le sous-jacent avant de promettre quoi que ce soit. Un rapport qui montre un délai stable et aucune perte sur le chemin externe est une preuve ; un schéma avec un tunnel dessus ne l’est pas.

Choisissez le tunnel pour la relation réseau dont vous avez besoin, puis spécifiez séparément le chiffrement, la politique d’accès, la taille des paquets et les performances. Quatre décisions, quatre preuves, et aucune étiquette unique ne tenant lieu de l’une d’elles.