Le trafic sur eth0 ne signifie pas que le tunnel VPN fuit

Voir des adresses publiques sur eth0 alors que le tunnel est actif ressemble à la preuve que quelque chose s’est échappé. C’est souvent l’inverse : les paquets du tunnel lui-même doivent traverser cet adaptateur pour atteindre le serveur, et ils ressemblent à des flux UDP ou TCP ordinaires. Le paquet intérieur n’apparaît que sur le périphérique du tunnel. Distinguer les deux, c’est lire l’enveloppe, pas faire confiance à un décompte d’octets.

Chaque paquet du tunnel traverse encore le câble

Un tunnel est une interface, pas un câble. Le client prend un paquet intérieur, l’encapsule et envoie le résultat à l’adresse et au port du serveur indiqués dans le profil. Sur l’adaptateur physique, vous voyez l’enveloppe ; sur le périphérique du tunnel, vous voyez ce qui a été encapsulé.

En mode UDP, le flux extérieur est une seule paire d’adresse et de port dans chaque direction, ce qui explique qu’un tunnel sain paraisse presque ennuyeux sur eth0. C’est précisément cette paire unique qu’il faut chercher d’abord.

Capturez une interface à la fois

Capturez une interface à la fois lorsque vous voulez comparer des décomptes. La pseudo-interface any collecte tous les périphériques à la fois, si bien qu’un paquet transmis apparaît à l’entrée et à la sortie, et qu’un paquet généré localement apparaît deux fois sous deux formes différentes. Des décomptes de paquets égaux avec des décomptes d’octets différents sont normaux, car l’enveloppe est plus grosse que ce qu’elle transporte. L’ARP, le DHCP et les annonces de routeur IPv6 appartiennent à la liaison locale et ne disent rien de votre application.

sudo tcpdump -i eth0 -n host 203.0.113.10 and udp port 1194

Remplacez l’adresse et le port par les valeurs du profil lui-même. Si ce flux est régulier, le tunnel transporte quelque chose.

Demandez au noyau quel périphérique il choisit

Demandez au noyau quel périphérique il choisirait, puis confirmez sur le câble. La recherche de route est la décision, et la capture est la preuve que la décision a été suivie. Elles répondent à des questions différentes et vous voulez les deux.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Un résultat divisé est la constatation habituelle : IPv4 passe par le tunnel et IPv6 passe par l’adaptateur physique parce que le profil n’a poussé que des routes IPv4. C’est une vraie fuite, et elle est invisible dans une capture limitée à IPv4. Filtrez sur IPv6 et surveillez les adresses qui ne sont ni le serveur ni link-local.

Exécutez les deux recherches avant et après la connexion, afin de voir ce que le client a réellement changé. La différence entre les deux exécutions est l’effet réel du client.

Quand la capture est vraiment une fuite

Parfois la capture dit la vérité. Une route plus étroite qui envoie un préfixe à côté du tunnel, un sous-réseau que l’on a dit au client d’exclure, ou une autorisation du pare-feu qui s’exécute avant la politique du tunnel peuvent tous mettre du trafic sur le câble en clair. Une règle qui correspond à un groupe de processus peut aussi être une exception délibérée. Lisez son interface et sa portée de destination avant de la déclarer défaillante.

Corrigez la route ou l’exclusion, pas le pare-feu. Capturez ensuite à nouveau depuis une connexion neuve et vérifiez IPv4 et IPv6 séparément, car corriger l’un ne dit rien de l’autre. Le manuel de tcpdump décrit les sélecteurs d’interface et de direction utilisés plus haut.