Perte de Ping sur un VPN : regrouper les requêtes Echo avant le pourcentage

Une capture contient six requêtes Echo et trois réponses, et quelqu'un écrit dans le ticket une perte de paquets de 50 pour cent. Ce chiffre peut être vrai pour la capture et faux pour le tunnel. Les six requêtes peuvent appartenir à deux conversations différentes avec deux contrats de livraison différents. Regroupez-les avant de diviser, et le ratio cesse d'être la partie intéressante du rapport.

Étape 1 : séparer les flux par source et destination

Une requête Echo porte une source et une destination, et ces deux champs définissent à quelle conversation elle appartient. Une sonde générée par la passerelle utilise l'adresse de tunnel de la passerelle, tandis qu'une sonde transmise au nom d'un hôte LAN conserve l'adresse de cet hôte. Le côté distant peut avoir une route de retour pour l'une et pas pour l'autre, ce qui fait que les deux groupes se comportent différemment pour des raisons sans aucun rapport avec le tunnel.

Séparez la capture sur ces champs avant de compter quoi que ce soit, et gardez la destination comme partie de la clé. Deux flux vers des pairs différents ne sont pas comparables même lorsqu'ils partagent une source.

Notez les groupes avec leurs décomptes, car l'étape suivante décide quelles réponses appartiennent à quel groupe. Un groupe avec trois requêtes et aucune réponse correspondante est une constatation. Un groupe avec trois requêtes et trois réponses est une ligne de base.

Étape 2 : faire correspondre sur l'identifiant et la séquence

Le format Echo de la RFC 792 porte un identifiant et un numéro de séquence, et il les traite comme les champs qui apparient une réponse à sa requête. Les deux sont nécessaires pour ce travail. Un numéro de séquence seul n'est pas unique, car différents émetteurs ou processus peuvent réutiliser la même valeur dans une même fenêtre de capture. L'identifiant resserre l'émetteur et la séquence resserre la position, et c'est la paire ensemble qui rend une correspondance défendable.

Une réponse inverse la direction d'adresses de sa requête, donc une correspondance est une paire requête-réponse et non deux tuples identiques. Comparez la source de la requête avec la destination de la réponse et la destination de la requête avec la source de la réponse, puis confirmez que l'identifiant et la séquence concordent.

Conservez aussi la fenêtre d'observation, car une longue capture peut contenir une réutilisation légitime des deux champs. Réduire la fenêtre à une rafale élimine l'essentiel de cette ambiguïté. Cela rend aussi les décomptes reproductibles pour quiconque lit le ticket.

tshark -r capture.pcap -Y 'icmp.type == 8' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq
tshark -r capture.pcap -Y 'icmp.type == 0' -T fields -e frame.time -e ip.src -e ip.dst -e icmp.ident -e icmp.seq

Étape 3 : comparer les tuples à la même frontière

Si la traduction d'adresses réseau se situe entre le point de capture et le pair, les adresses de la requête et de la réponse différeront par conception. Comparez les tuples à une seule frontière, ou transportez la correspondance explicitement pour que la différence soit prise en compte. Mélanger des requêtes avant traduction avec des réponses après traduction invente des écarts qui n'ont jamais existé sur le câble.

Décidez de la frontière avant de commencer à compter, et indiquez-la dans le rapport pour que la personne suivante puisse reproduire le regroupement. Une capture côté client et une autre côté serveur sont deux frontières différentes. Chacune répond à une question différente sur l'endroit où la réponse a disparu.

Un groupe de sondes traduites hérite aussi de l'état propre du dispositif de traduction, qui peut être la raison réelle pour laquelle une réponse n'arrive jamais. Vérifiez cet état avant d'accuser le chemin au-delà.

tcpdump -ni any icmp and host 10.90.0.1 -c 20
tshark -r capture.pcap -Y 'icmp' -T fields -e ip.src -e ip.dst -e ip.ttl | head -20

Étape 4 : dire ce que la capture peut et ne peut pas prouver

Un vide observé n'établit pas que l'hôte distant soit resté silencieux. Le point de capture peut ne voir qu'une direction, un filtre peut supprimer la réponse, ou le tampon a pu déborder pendant la fenêtre. Chacun de ces cas produit la même absence et une conclusion différente.

Notez l'emplacement de la capture, l'expression du filtre et les compteurs de rejet à côté des décomptes, car un ratio sans eux ne peut pas être audité. Ce sont ces trois lignes qui rendent le chiffre défendable plus tard.

Séparez ensuite ce que l'observation établit de ce qu'elle suggère, en deux phrases plutôt qu'une. La première phrase énonce les décomptes et la frontière. La seconde énonce l'hypothèse et ce qui la confirmerait.

Lorsque la question est de savoir si un chemin précis rejette des paquets, une sonde contrôlée avec une adresse source explicite est une preuve plus forte qu'un décompte passif de trafic mélangé. Envoyez-la depuis la même machine, au même moment, vers le même pair. Changez une variable et la comparaison tient.

Rapportez les groupes et la frontière suivante

Le rapport comporte trois lignes : la définition du groupe, les décomptes appariés à l'intérieur de chaque groupe et la frontière à laquelle la comparaison a été faite. Le lecteur peut alors voir qu'un groupe a répondu complètement et un autre non, ce qui pointe vers une route ou une autorisation plutôt que vers une perte aléatoire.

Joignez le fichier de capture et les expressions de filtre pour que le regroupement soit reproductible. Un résumé sans le fichier est une affirmation et non un résultat.

ping -c 5 -I 10.80.0.6 10.90.0.1
ping -c 5 -I 10.30.0.25 10.90.0.1
tshark -r capture.pcap -Y 'icmp.type == 8 || icmp.type == 0' -T fields -e ip.src -e ip.dst -e icmp.ident -e icmp.seq | sort | uniq -c | head

Quand un groupe montre cinq réponses et l'autre aucune, la constatation est qu'une source dispose d'une route de retour fonctionnelle et l'autre pas. C'est un bien meilleur ticket qu'un pourcentage mélangé, et cela oriente la vérification suivante vers la route de retour plutôt que vers une instance VPN sans rapport.