Was ein iftop-Bildschirm über ein VPN beweisen kann und was nicht

Ein iftop-Bildschirm beantwortet jeweils eine Frage: Welche Hostpaare tauschen Bytes über die Schnittstelle aus, auf die Sie ihn gerichtet haben. Er beantwortet nicht, ob jede Anwendung eine VPN-Richtlinie befolgt, und ein leerer Bildschirm beweist nicht, dass nichts abgeflossen ist. Genau in der Lücke zwischen diesen beiden Aussagen gehen die meisten Diskussionen über Leak-Tests schief. Drei Bedingungen entscheiden, was die Anzeige tatsächlich bedeutet, und alle drei sind in der von Ihnen verwendeten Befehlszeile sichtbar.

Drei Bedingungen entscheiden, was der Bildschirm bedeutet

Die Bedingungen sind, welche Schnittstelle angezeigt wird, was der Filter und das Werkzeug selbst verbergen, und was der Test tatsächlich geübt hat. Beantworten Sie sie in dieser Reihenfolge, denn ein Fehler in der ersten macht die anderen beiden bedeutungslos.

Die Schnittstellenbedingung ist wichtig, weil eine Tunnelansicht und eine physische Ansicht verschiedene Schichten desselben Verkehrs zeigen. Der Blick auf die Tunnelschnittstelle zeigt die Ströme im Tunnel; der Blick auf die physische Schnittstelle zeigt den Träger des Tunnels sowie jeden legitimen Einrichtungs-, Steuerungs- oder lokalen Verkehr, der sich diese Verbindung teilt. Keine der Ansichten ist falsch, und keine ist das ganze Bild. Zu benennen, welche Sie betrachten, ist der Unterschied zwischen Beleg und Eindruck.

Bedingung eins: welche Schnittstelle angezeigt wird

iftop übernimmt die Schnittstelle ausdrücklich mit -i, und sein Handbuch beschreibt das Verhalten, wenn Sie es nicht tun: Es wählt eine aus, die das von außen wirkende Gerät statt des Tunnels sein kann. Diese Voreinstellung ist für ein Bandbreitenwerkzeug vernünftig und für einen Leak-Test schlecht.

Geben Sie die Schnittstelle immer an und notieren Sie sie neben dem Ergebnis. Ein Screenshot ohne den Schnittstellennamen ist nicht reproduzierbar.

Bedingung zwei: was der Filter und das Werkzeug verbergen

iftop akzeptiert einen Filterausdruck, und ein Strom, den der Filter ausschließt, ist konstruktionsbedingt unsichtbar und nicht wegen Abwesenheit. Das Werkzeug führt außerdem standardmäßig Hostnamen-Abfragen zur Kennzeichnung von Adressen durch, und diese Abfragen erzeugen eigenen DNS-Verkehr, also Verkehr, den Sie nicht beobachten wollten. -n schaltet die Abfragen ab und macht die Anzeige numerisch; die DNS-Zeilen hinterher zu verbergen ist nicht dasselbe, wie die Abfragen nicht zu erzeugen.

Diese Unterscheidung sollte man klar aussprechen, denn sie erscheint auch in anderen Werkzeugen: die Anzeige einer Aktivität zu unterdrücken ist nicht dasselbe, wie sie zu verhindern. Wenn die DNS-Abfragen Teil dessen sind, was Sie testen, führen Sie den Test mit abgeschalteten Abfragen aus, damit die Beobachtung nicht durch den Beobachter verunreinigt wird.

Bedingung drei: was der Test tatsächlich geübt hat

Eine einzelne Anfrage von einer Anwendung an ein Ziel in einer Adressfamilie beweist etwas über diese Anfrage. Sie beweist nichts über eine andere Anwendung, ein anderes Ziel oder die andere Adressfamilie, und IPv6 ist die Familie, die bei genau dieser Art Prüfung am häufigsten vergessen wird.

Definieren Sie die Anfrage daher vor dem Start: ein harmloses Ziel, von der Anwendung, die Ihnen wichtig ist, in der Familie, die Ihnen wichtig ist, mit dem Tunnel in seinem genehmigten Zustand. Prüfen Sie dann die Empfangsseite oder die Diagnose des Clients selbst, denn das entfernte Ende weiß, was angekommen ist, auf eine Weise, die der lokale Bildschirm nicht kann. Üben Sie dann den genehmigten Fall des nicht verfügbaren Tunnels und sehen Sie nach, ob der Verkehr stoppt, denn darum geht es bei der Anforderung meistens wirklich.

DNS verdient eine eigene Beobachtung. Der Empfänger der Abfrage und die Route, die die Abfrage genommen hat, sind zwei Tatsachen, und ein Bandbreitenbildschirm zeigt keine davon.

iftop als stützenden Beleg verwenden

Erst dann fügt iftop Wert hinzu, und zwar als Bestätigung. sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" zeigt, ob der erwartete Strom auf der erwarteten Schnittstelle erscheint, mit Bytedurchsätzen, die eine Behauptung über Leerlauf überprüfbar machen.

Vergleichen Sie das mit ss -tnp für die Ansicht auf Socket-Ebene und ip route get für die Route, die der Kernel wählen würde, und Sie haben drei Beobachtungen einer Anfrage statt eines Eindrucks von einer Maschine. Das iftop-Handbuch dokumentiert die Schnittstellenauswahl, die Filtersyntax und das Abfrageverhalten, also die drei Dinge, von denen ein Leak-Test abhängt. Ein Bandbreitenbildschirm lokalisiert Aktivität; die Route, die Ausnahmen und das Fehlerverhalten entscheiden, ob diese Aktivität die Anforderung erfüllt.