Capture VPN : paquets internes sur tun0, enveloppe sur eth0

Capturer sur un hôte VPN n’enregistre pas une seule chose. Le noyau expose le paquet deux fois : encapsulé, sur l’adaptateur physique, et désencapsulé, sur l’appareil tunnel. Choisir l’interface, c’est choisir laquelle de ces histoires vous lisez. La plupart des débats sur ce qu’une capture prouve portent en réalité sur l’histoire qui a été recueillie.

L’encapsulation crée deux vues

Le tunnel prend le paquet qu’une application a produit et le place dans un nouveau dont la destination est le serveur VPN. La forme interne apparaît sur tun0, wg0 ou sur l’appareil que le client a créé. La forme externe apparaît sur l’adaptateur qui la porte jusqu’au réseau. Les deux formes sont légitimes ; elles répondent à des questions différentes. Recueillez chacune séparément, car les deux ont des en-têtes et des lecteurs différents.

sudo tcpdump -i tun0 -n -s 0
sudo tcpdump -i eth0 -n host 198.51.100.20 and udp port 51820

La pseudo-interface any est un mauvais choix pour cette comparaison. Les paquets transférés peuvent être enregistrés deux fois, et un paquet généré localement apparaît dans les deux formes, ce qui gonfle les comptes. Si un nombre semble impossible, vérifiez l’interface avant d’accuser le tunnel.

Dans le tunnel, le paquet est ordinaire

Sur l’appareil tunnel, ce que vous voyez est ce que l’application a demandé au noyau d’envoyer. Les adresses de destination, les ports, les noms DNS, les noms de serveur TLS, les tailles et le minutage sont tous là. La charge utile TLS reste chiffrée par la session de l’application elle-même, si bien que la capture ne révèle pas le contenu de la page. Une requête DNS en clair est visible ici alors même que son transport est chiffré, parce qu’elle n’a jamais été protégée.

Le DNS chiffré supprime ce seul champ visible. Il ne cache ni l’adresse de destination, ni le nombre d’octets, ni le rythme, qui sont des propriétés du flux et non de la requête.

Dehors, seulement l’enveloppe et sa forme

L’adaptateur physique montre votre adresse, celle du serveur, le port, les tailles de paquet et le minutage. Les destinations transportées à l’intérieur sont absentes, même si leur forme peut encore soutenir des inférences. Les tailles et la cadence peuvent suggérer un flux vidéo, un transfert massif ou une session de discussion sans en nommer aucun. Un observateur proche voit à peu près la même vue, ce qui explique comment un tunnel peut dissimuler des sites tout en annonçant sa propre présence.

Cette affirmation dépend du routage. Une route plus étroite, une IPv6 par défaut qui n’entre pas dans le tunnel ou un processus lié à l’interface physique placeront le trafic hors de l’enveloppe. Lisez la route réelle avant de tirer des conclusions de la capture.

Adresse du pair et hygiène de capture

OpenVPN en mode TCP garde une socket établie, si bien que la table des sockets peut nommer le pair. OpenVPN en mode UDP laisse souvent la socket non connectée, et ss peut ne montrer que le côté local. Lisez plutôt le remote du profil, un journal client détaillé ou la route vers le point de terminaison. WireGuard rapporte directement son point de terminaison et sa dernière poignée de main.

wg show
ss -tunp | grep 51820

Un fichier de capture survit à la session qui l’a produit. Il peut être copié et être lisible par quiconque dispose d’un accès local. Ne gardez que ce dont l’enquête a besoin, restreignez les permissions et supprimez-le une fois le travail terminé.

Une capture partageable devrait indiquer quelle interface l’a produite et quand. Sans cette note, le lecteur suivant doit deviner quelle couche il regarde.