Ce qu’un écran iftop peut prouver au sujet d’un VPN, et ce qu’il ne peut pas

Un écran iftop répond à une question à la fois : quelles paires d’hôtes échangent des octets par l’interface vers laquelle vous l’avez dirigé. Il ne répond pas si chaque application suit une politique VPN, et un écran vide ne prouve pas que rien n’a fui. C’est précisément dans l’écart entre ces deux affirmations que la plupart des discussions sur les tests de fuite se trompent. Trois conditions décident de ce que l’affichage signifie réellement, et toutes trois sont visibles dans la ligne de commande que vous avez utilisée.

Trois conditions décident de ce que signifie l’écran

Les conditions sont l’interface affichée, ce que le filtre et l’outil lui-même dissimulent, et ce que le test a réellement exercé. Répondez-y dans cet ordre, car une erreur sur la première rend les deux autres inutiles.

La condition d’interface compte parce que la vue du tunnel et la vue physique montrent des couches différentes du même trafic. Regarder l’interface du tunnel montre les flux à l’intérieur du tunnel ; regarder l’interface physique montre le porteur du tunnel, plus tout trafic légitime de configuration, de contrôle ou local qui partage ce lien. Aucune des deux vues n’est fausse, et aucune n’est l’image complète. Nommer celle que vous regardez, c’est la différence entre une preuve et une impression.

Condition un : quelle interface est affichée

iftop prend l’interface explicitement avec -i, et son manuel décrit le comportement quand vous ne le faites pas : il en choisit une, qui peut être le périphérique à l’allure externe plutôt que le tunnel. Ce choix par défaut est raisonnable pour un outil de bande passante et mauvais pour un test de fuite.

Passez toujours l’interface, et notez-la à côté du résultat. Une capture d’écran sans le nom de l’interface n’est pas reproductible.

Condition deux : ce que le filtre et l’outil dissimulent

iftop accepte une expression de filtre, et un flux que le filtre exclut est invisible par construction et non par absence. L’outil effectue aussi par défaut des résolutions de noms d’hôtes pour étiqueter les adresses, et ces résolutions génèrent leur propre trafic DNS, c’est-à-dire un trafic que vous ne cherchiez pas à observer. -n désactive les résolutions et rend l’affichage numérique ; masquer ensuite les lignes DNS n’est pas la même chose que ne pas générer les requêtes.

Cette distinction mérite d’être dite clairement, car elle apparaît aussi dans d’autres outils : supprimer l’affichage d’une activité n’est pas la même chose que l’empêcher. Si les résolutions DNS font partie de ce que vous testez, exécutez le test avec les résolutions désactivées, afin que l’observation ne soit pas contaminée par l’observateur.

Condition trois : ce que le test a réellement exercé

Une seule requête d’une application, vers une destination, dans une famille d’adresses, prouve quelque chose sur cette requête. Elle ne prouve rien sur une autre application, une autre destination ou l’autre famille d’adresses, et IPv6 est la famille la plus souvent oubliée précisément dans ce genre de vérification.

Définissez donc la requête avant de commencer : une destination inoffensive, depuis l’application qui vous importe, dans la famille qui vous importe, le tunnel dans son état approuvé. Vérifiez ensuite le côté récepteur ou les diagnostics du client lui-même, car l’extrémité distante sait ce qui est arrivé d’une manière que l’écran local ne peut pas. Exercez ensuite le cas approuvé du tunnel indisponible et regardez si le trafic s’arrête, car c’est le comportement auquel l’exigence se réfère généralement vraiment.

Le DNS mérite sa propre observation. Le destinataire de la requête et la route qu’elle a empruntée sont deux faits, et un écran de bande passante ne montre ni l’un ni l’autre.

Utiliser iftop comme preuve d’appui

C’est seulement alors qu’iftop apporte de la valeur, et il l’apporte comme corroboration. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" montre si le flux attendu apparaît sur l’interface attendue, avec des compteurs d’octets qui rendent vérifiable une affirmation d’inactivité.

Comparez cela avec ss -tnp pour la vue au niveau des sockets et ip route get pour la route que le noyau choisirait, et vous avez trois observations d’une requête au lieu d’une impression d’une machine. Le manuel d’iftop documente la sélection d’interface, la syntaxe du filtre et le comportement des résolutions, qui sont les trois choses dont dépend un test de fuite. Un écran de bande passante localise l’activité ; la route, les exceptions et le comportement en cas de panne décident si cette activité satisfait à l’exigence.