Pingverlust im VPN: Echo-Anfragen vor der Prozentzahl gruppieren

Ein Mitschnitt enthält sechs Echo-Anfragen und drei Antworten, und jemand schreibt 50 Prozent Paketverlust ins Ticket. Diese Zahl kann für den Mitschnitt stimmen und für den Tunnel falsch sein. Die sechs Anfragen können zu zwei verschiedenen Gesprächen mit zwei verschiedenen Zustellverträgen gehören. Gruppieren Sie sie, bevor Sie teilen, und das Verhältnis ist nicht mehr der interessante Teil des Berichts.

Schritt 1: Ströme nach Quelle und Ziel trennen

Eine Echo-Anfrage trägt eine Quelle und ein Ziel, und diese beiden Felder legen fest, zu welchem Gespräch sie gehört. Eine vom Gateway erzeugte Sonde verwendet die Tunneladresse des Gateways, während eine im Namen eines LAN-Hosts weitergeleitete Sonde die Adresse dieses Hosts behält. Die Gegenseite kann für die eine eine Rückroute haben und für die andere nicht, wodurch sich die beiden Gruppen aus Gründen unterschiedlich verhalten, die nichts mit dem Tunnel zu tun haben.

Teilen Sie den Mitschnitt an diesen Feldern, bevor Sie irgendetwas zählen, und behalten Sie das Ziel als Teil des Schlüssels. Zwei Ströme zu verschiedenen Peers sind nicht vergleichbar, selbst wenn sie sich eine Quelle teilen.

Schreiben Sie die Gruppen mit ihren Anzahlen auf, denn der nächste Schritt entscheidet, welche Antworten zu welcher Gruppe gehören. Eine Gruppe mit drei Anfragen und keiner passenden Antwort ist ein Befund. Eine Gruppe mit drei Anfragen und drei Antworten ist eine Grundlinie.

Schritt 2: nach Kennung und Sequenz abgleichen

Das Echo-Format in RFC 792 trägt eine Kennung und eine Sequenznummer und behandelt sie als die Felder, die eine Antwort mit ihrer Anfrage paaren. Beide werden für diese Aufgabe gebraucht. Eine Sequenznummer allein ist nicht eindeutig, da verschiedene Absender oder Prozesse denselben Wert innerhalb eines Mitschnittfensters wiederverwenden können. Die Kennung grenzt den Absender ein und die Sequenz die Position, und das Paar zusammen macht einen Abgleich belastbar.

Eine Antwort kehrt die Adressrichtung ihrer Anfrage um, ein Abgleich ist also ein Anfrage-Antwort-Paar und nicht zwei identische Tupel. Vergleichen Sie die Quelle der Anfrage mit dem Ziel der Antwort und das Ziel der Anfrage mit der Quelle der Antwort, und bestätigen Sie dann, dass Kennung und Sequenz übereinstimmen.

Behalten Sie auch das Beobachtungsfenster, denn ein langer Mitschnitt kann eine legitime Wiederverwendung beider Felder enthalten. Das Fenster auf einen Burst zu kürzen, beseitigt den größten Teil dieser Mehrdeutigkeit. Es macht die Zahlen auch für jeden reproduzierbar, der das Ticket liest.

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

Schritt 3: Tupel an derselben Grenze vergleichen

Wenn die Netzwerkadressübersetzung zwischen Mitschnittpunkt und Peer liegt, unterscheiden sich die Adressen in Anfrage und Antwort konstruktionsbedingt. Vergleichen Sie die Tupel an einer Grenze, oder führen Sie die Zuordnung ausdrücklich mit, damit die Differenz berücksichtigt wird. Anfragen vor der Übersetzung mit Antworten nach der Übersetzung zu mischen, erfindet Abweichungen, die es auf der Leitung nie gab.

Legen Sie die Grenze fest, bevor Sie zu zählen beginnen, und nennen Sie sie im Bericht, damit die nächste Person die Gruppierung reproduzieren kann. Ein Mitschnitt auf der Clientseite und ein anderer auf der Serverseite sind zwei verschiedene Grenzen. Jede beantwortet eine andere Frage dazu, wo die Antwort verschwunden ist.

Eine Gruppe übersetzter Sonden erbt auch den eigenen Zustand des Übersetzungsgeräts, der der eigentliche Grund sein kann, warum eine Antwort nie ankommt. Prüfen Sie diesen Zustand, bevor Sie den Pfad dahinter beschuldigen.

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

Schritt 4: sagen, was der Mitschnitt beweisen kann und was nicht

Eine beobachtete Lücke belegt nicht, dass der entfernte Host geschwiegen hat. Der Mitschnittpunkt sieht möglicherweise nur eine Richtung, ein Filter kann die Antwort verwerfen, oder der Puffer kann während des Fensters übergelaufen sein. Jedes davon erzeugt dieselbe Abwesenheit und eine andere Schlussfolgerung.

Halten Sie Mitschnittort, Filterausdruck und Verwerfungszähler neben den Zahlen fest, denn ein Verhältnis ohne sie lässt sich nicht prüfen. Diese drei Zeilen machen die Zahl später belastbar.

Trennen Sie dann, was die Beobachtung belegt, von dem, was sie nahelegt, in zwei Sätzen statt einem. Der erste Satz nennt die Zahlen und die Grenze. Der zweite nennt die Hypothese und was sie bestätigen würde.

Geht es um die Frage, ob ein bestimmter Pfad Pakete verwirft, ist eine kontrollierte Sonde mit ausdrücklicher Quelladresse ein stärkerer Nachweis als eine passive Zählung gemischten Verkehrs. Senden Sie sie von derselben Maschine, zur selben Zeit, an denselben Peer. Ändern Sie eine Variable, und der Vergleich bleibt gültig.

Melden Sie die Gruppen und die nächste Grenze

Der Bericht hat drei Zeilen: die Gruppendefinition, die abgeglichenen Anzahlen innerhalb jeder Gruppe und die Grenze, an der der Vergleich stattfand. Dann sieht der Leser, dass eine Gruppe vollständig geantwortet hat und eine andere nicht, was auf eine Route oder eine Berechtigung und nicht auf zufälligen Verlust deutet.

Fügen Sie die Mitschnittdatei und die Filterausdrücke bei, damit die Gruppierung reproduzierbar ist. Eine Zusammenfassung ohne die Datei ist eine Behauptung und kein Ergebnis.

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

Wenn eine Gruppe fünf Antworten zeigt und die andere keine, lautet der Befund, dass eine Quelle eine funktionierende Rückroute hat und die andere nicht. Das ist ein viel besseres Ticket als ein gemischter Prozentsatz, und es lenkt die nächste Prüfung auf die Rückroute statt auf eine unabhängige VPN-Instanz.