Deux sauts VPN à la suite : qui voit réellement votre trafic ?

Chaque profil client nomme un serveur, donc du point de vue de l’utilisateur il y a un tunnel et un endroit où la protection s’arrête. Ce qui se passe après cette première passerelle est une décision de conception que le client ne voit jamais, et les deux conceptions courantes se comportent très différemment à l’examen. Dans une chaîne en série, la première passerelle déchiffre et rechiffre. Dans une chaîne imbriquée, elle retire une couche externe et transmet un tunnel interne qu’elle ne peut pas ouvrir. Le nombre de sauts est identique dans les deux, c’est pourquoi la différence doit être dessinée plutôt que comptée.

Partez du client et nommez les deux extrémités

Partez de là où l’utilisateur commence, dans le profil de connexion. Il contient une adresse distante, une méthode d’authentification et, quand la conception le permet, une liste de routes. Étiquetez ce tunnel externe du client vers la passerelle A et donnez-lui des adresses d’exemple : l’adresse du tunnel du client 10.77.0.2, celle de A 10.77.0.1 et le point de terminaison public de A 198.51.100.10, pris dans la plage de documentation TEST-NET-2 afin que rien dans l’exemple ne puisse entrer en collision avec un hôte réel.

Rien dans ce profil ne mentionne la passerelle B, et ce n’est pas un défaut. Le second saut appartient à A, et la seule obligation du client est d’acheminer le trafic vers A et d’accepter ce qui revient. Que A termine le tunnel, le transmette ou en ouvre un nouveau est la question à laquelle répond le reste de ce parcours, et c’est elle qui décide de ce que A peut lire.

En série : A déchiffre, puis rechiffre

Dans la conception en série, A termine le trafic deux fois. Elle retire la protection du client, obtient le paquet IP de l’application, puis envoie ce paquet par un second tunnel que A établit vers B. Entre ces deux opérations, le paquet se trouve dans le chemin de transmission de A comme un paquet IP ordinaire adressé à une destination privée.

Cela produit deux conséquences qu’il vaut la peine de dire clairement. A peut appliquer une politique au paquet interne, sous forme de routes, de règles de filtrage et de journalisation de la source et de la destination, et A doit détenir deux jeux d’identifiants : un comme serveur pour le client et un comme client de B. La protection existe à chaque instant, mais l’objet protégé change d’identité chez A.

Il ne s’ensuit pas que A lise le texte en clair de l’application. Lorsque le client et le service utilisent TLS et vérifient mutuellement leurs certificats, A voit un flux d’enregistrements TLS plutôt qu’une requête lisible. Confirmer où cette protection s’arrête demande de regarder la chaîne de certificats du service, pas le schéma du tunnel.

Imbriqué : A ne retire que la couche externe

Dans la conception imbriquée, le client construit d’abord un tunnel interne vers B, puis transporte ce tunnel à l’intérieur de l’externe jusqu’à A. A retire l’en-tête externe, trouve un tunnel interne et le transmet sans en détenir les clés, si bien que la protection interne se termine toujours à B.

La liaison montante du client porte alors deux couches, tandis que le chemin entre A et B en porte une. A voit les adresses externes du tunnel interne, ce qui suffit à savoir que du trafic existe et à peu près où il va, et ne suffit pas à lire la charge utile. C’est toute la différence avec le cas en série, et aucun compteur de sauts ne la montre. Ce que A peut encore faire, c’est refuser de transmettre ce qu’elle ne peut pas lire, et cela reste toujours disponible pour l’opérateur de cette passerelle.

L’imbrication se paie. Chaque couche ajoute un surcoût d’en-tête, si bien que la planification MTU et MSS devient obligatoire plutôt que soignée, et un chemin qui fonctionne avec une couche peut perdre silencieusement de gros paquets avec deux. Chaque couche a aussi besoin de son propre comportement de reconnexion et de keepalive, et une défaillance dans une couche ressemble à une panne partielle à travers l’autre.

Dessinez les observateurs, pas seulement les tunnels

Les tunnels sont la partie facile du dessin. Les observateurs sont le sujet de la conception, alors écrivez une ligne par point de vue et remplissez ce que chacun peut réellement lire.

Deux lignes sont constamment confondues : l’opérateur de A et le fournisseur du tunnel du client. Ils peuvent être une seule entité, et des noms de passerelle distincts ne les rendent pas indépendants. Une propriété indépendante exige un contrôle administratif distinct, des identifiants distincts et une journalisation distincte.

Les métadonnées survivent aux deux conceptions. La synchronisation, la taille des paquets et le nombre de connexions restent observables à chaque saut, donc deux sauts augmentent le coût de la corrélation plutôt que de supprimer le signal. Une conception qui promet l’invisibilité devrait être confrontée à cette liste avant que quiconque s’y fie.

Parcourez les chemins de défaillance avant de choisir

Cassez des choses exprès depuis le client, dans l’ordre où un utilisateur les rencontrerait. Commencez par l’interface et son MTU, car l’imbrication échoue sur la taille des paquets bien avant d’échouer sur l’authentification.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Confirmez ensuite les points de terminaison de protection au lieu de les supposer. Demandez au service son certificat depuis l’intérieur du tunnel qui est actif, et comparez la chaîne que le client voit à celle que le service présente réellement. Une passerelle qui re-signe ou intercepte modifie ce certificat, et l’inspection devient visible en une seule commande.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Terminez par la matrice de reconnexion : le tunnel du client tombe, celui de B tombe, le chemin entre A et B change. Notez ce qui revient et ce qui ne revient pas, et si une connexion interne retombe jamais sur une route hors de son transport prévu. Consignez les adresses utilisées par chaque test, car le répéter sur un autre réseau d’accès répond à une autre question. Répétez aussi la sonde MTU après chaque reconnexion, car un chemin modifié peut abaisser la taille utilisable sans qu’une seule ligne de configuration bouge.

Choisissez le sérieux quand A doit appliquer une politique au paquet interne, ou quand le client ne peut pas exécuter deux tunnels empilés. Choisissez l’imbrication quand la charge interne doit rester illisible chez A. Écrivez le choix avec ses observateurs et ses chiffres de MTU, et la personne suivante n’aura pas à redessiner toute l’image pour répondre à une question.