Ce qu’est un tunnel VPN et où la protection s’arrête

Le client indique connecté, le cadenas est fermé, et un site enregistre toujours l’adresse de votre appartement. Rien n’a échoué. Un tunnel ne remplace pas votre Wi-Fi ni votre liaison mobile ; il place une seconde enveloppe autour de certains paquets et envoie cette enveloppe sur le réseau que vous aviez déjà. Comprendre l’astuce consiste surtout à suivre une requête et à repérer où l’enveloppe est ouverte, car presque chaque symptôme déroutant, d’une adresse domicile qui fuit à un gros téléchargement bloqué, vient de cette frontière.

Deux enveloppes, une liaison physique

Votre ordinateur portable conserve sa connexion normale au routeur, et le routeur conserve sa connexion normale au fournisseur. Rien sur ce chemin ne change lorsqu’un tunnel monte. Ce qui change, c’est que certains paquets sont remis à une interface virtuelle, emballés dans un nouveau paquet adressé au pair VPN et envoyés comme trafic ordinaire sur la liaison physique.

L’extrémité réceptrice est un appareil qui ouvre l’enveloppe et transmet le paquet d’origine vers sa destination. Entre les deux extrémités, un observateur voit l’en-tête extérieur et rien de l’intérieur, sauf si le protocole le chiffre, ce que font la plupart des protocoles grand public et ce que la technique générale n’exige pas.

C’est pourquoi l’interface virtuelle est à la fois réelle et trompeuse. Elle existe comme objet du noyau avec une adresse et une unité de transmission maximale, et le système d’exploitation y achemine le trafic comme vers n’importe quelle autre interface. Ce n’est pas un câble, et son existence prouve seulement qu’un composant est installé. Que votre navigateur l’utilise se décide par les routes, pas par le fait que l’interface soit active.

Suivez une requête en voyage

Choisissez une destination et demandez au noyau quelle interface il utilisera. Cette seule commande tranche la plupart des débats sur l’utilité réelle du tunnel :

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

Si la sortie de route nomme l’interface du tunnel, le paquet sera emballé. Si elle nomme l’interface physique, il ne le sera pas, et aucun redémarrage du client n’y change rien. La seconde commande montre les deux interfaces côte à côte, et c’est ainsi que vous repérez un tunnel monté sans adresse ou avec une adresse de la mauvaise famille.

Regardez ensuite le premier saut depuis l’intérieur de l’enveloppe, et comparez-le au premier saut depuis l’extérieur :

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

À l’intérieur du tunnel, le premier saut est l’adresse intérieure du pair, pas votre routeur. La capture sur l’interface du tunnel montre les paquets intérieurs, c’est-à-dire le trafic que l’application croit envoyer. La capture simultanée sur l’interface physique montre les paquets extérieurs, et les deux ensemble sont la démonstration la plus claire de ce que fait réellement un tunnel.

Trois adresses, et une seule est vue par le site

Les gens les confondent sans cesse, et la confusion produit de faux rapports de fuite. Ce sont des champs différents dans des en-têtes différents avec des durées de vie différentes.

Le numéro à côté de l’adaptateur virtuel est la deuxième ligne. Ce n’est pas l’adresse qu’un site enregistre, et le citer comme votre IP publique est tout simplement faux. L’adresse qu’un site voit est attribuée par la sortie, et pour un tunnel vers un réseau privé il peut n’y avoir aucune sortie publique, car la destination vit à l’intérieur de l’organisation et non sur internet.

Un tunnel entre sites est le même mécanisme avec d’autres extrémités. Deux routeurs emballent le trafic entre réseaux, et aucun appareil individuel n’a de client installé. L’enveloppe est identique en principe, la frontière administrative non.

Où l’enveloppe est ouverte, et ce qui y survit

Le tunnel se termine à son pair. Si le chiffrement propre à l’application va plus loin, il survit à cette frontière, ce qui est le cas normal de HTTPS : la session du navigateur se termine au site, donc la sortie transmet un texte chiffré qu’elle ne peut pas lire.

Rien d’autre ne survit par défaut. Une requête non chiffrée est lisible à la sortie exactement comme elle l’était sur le Wi-Fi du café, et le tunnel n’ajoute pas une protection que l’application n’a jamais eue. De même, les règles de pare-feu et la politique de transfert de la sortie décident de la suite ; une poignée de main réussie est un fait sur la connexion au pair, pas sur le reste du trajet.

La surcharge est l’autre conséquence visible. Chaque paquet porte un en-tête supplémentaire, et le transport extérieur peut ajouter le sien, si bien que la charge utile par paquet diminue. Sur un chemin à unité de transmission maximale fixe, c’est exactement pourquoi un tunnel peut laisser passer un ping et bloquer un gros envoi.

Vérifiez le chemin que l’application a réellement pris

La dernière étape consiste à confirmer l’application précise, plutôt que la machine en général. Résolvez la destination, regardez la route pour cette adresse, puis observez la connexion tant qu’elle est ouverte :

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

Si la route nomme le tunnel mais que la liste des sockets montre une connexion avec une adresse source issue de l’interface physique, l’application est liée à quelque chose de précis, ou un second tunnel se dispute la route par défaut. C’est une question de routage, et elle se résout avec ces trois sorties plutôt qu’avec l’écran d’état du client.

L’architecture de sécurité RFC 4301 décrit la version de couche IP de cet emballage pour IPsec, et la même logique de couches s’applique à WireGuard et à OpenVPN. Une fois que vous pouvez désigner le paquet intérieur et le paquet extérieur comme des objets distincts, l’essentiel du comportement d’un tunnel cesse d’être mystérieux et devient une table de routage que vous pouvez lire.