Eine headless VPN prüfen: ein Flow nach dem anderen, mit Belegen
Eine Headless-Box braucht eine Anfrage, deren Antwort Sie lesen können. Prüfen Sie jede Adressfamilie, jeden Kontext und jedes Ziel, und halten Sie dann fest, was das Ergebnis nicht abdeckte.
Auf einer Headless-Box gibt es keinen Browser zum Öffnen und kein Schloss zum Ansehen, also muss die Prüfung eine Anfrage sein, deren Antwort Sie lesen können. Das klingt trivial, bis Ihnen auffällt, dass ein einzelnes Exit-Adress-Ergebnis dazu dient, ein Gerät zu zertifizieren, das ein Dutzend Dienste, zwei Adressfamilien und einen Proxy betreibt. Der folgende Durchgang baut jeweils einen begrenzten Beleg auf, im selben Kontext, in dem die Arbeitslast tatsächlich läuft.
Entscheiden Sie, was der Test beweisen soll
Bevor Sie irgendetwas ausführen, schreiben Sie die Erwartung in einer Zeile: welcher Flow, über welche Schnittstelle, zu welchem Ziel, und was am anderen Ende zu beobachten sein soll. Ein Test ohne ausgesprochene Erwartung liefert eine Zahl, die niemand deuten kann.
Die nützlichste Fassung nennt einen freigegebenen Endpunkt, der die Quelladresse meldet, die er gesehen hat.
Dieser Endpunkt ist der einzige Teil, den Sie einrichten müssen. Alles andere ist eine Beobachtung auf der Clientseite, und clientseitige Beobachtungen gehen auf interessante Weise schief.
Führen Sie die Beobachtung im richtigen Kontext aus
Die Shell eines Administrators ist nicht die Umgebung der Arbeitslast. Sie kann eine andere Proxy-Variable, eine andere Routing-Tabelle in einem anderen Namespace oder die Umgebungsdatei eines anderen Benutzers tragen. Führen Sie den Test im selben Host-, Container-, Namespace- oder Dienstkontext aus wie das, was Sie prüfen. Sonst messen Sie Ihre Shell.
Auf einem normalen Host bedeutet das denselben Benutzer und dieselbe Unit. In einer Container-Landschaft bedeutet es, in den Netzwerk-Namespace des Containers zu gehen, statt vom Host aus zu testen. Bei einem systemd-Dienst kann es eine transiente Unit mit denselben Einstellungen bedeuten.
Die folgende Anfrage ist nur sinnvoll, wenn Sie im richtigen Kontext sind.
Prüfen Sie Adressfamilien getrennt
Fragen Sie jede Familie ausdrücklich ab, denn eine erfolgreiche IPv4-Anfrage beansprucht einen IPv6-Pfad überhaupt nicht. Die Selektoren --ipv4 und --ipv6 erzwingen die Wahl, und der Unterschied zwischen beiden Ergebnissen ist selbst eine Information.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceEine fehlgeschlagene IPv6-Anfrage ist kein Beweis für eine wirksame Sperre. Sie kann bedeuten, dass der Endpunkt keine IPv6-Adresse hat, dass DNS nichts Brauchbares zurückgab oder dass das Gerät überhaupt keine IPv6-Route hat. Lesen Sie den Fehlschlag, bevor Sie eine Schlussfolgerung daraus ziehen. Eine erfolgreiche IPv6-Anfrage durch den Tunnel ist das einzige Ergebnis, das belegt, dass der IPv6-Pfad abgedeckt ist.
Halten Sie beide Antworten nebeneinander fest. Eine davon allein ist die Hälfte eines Fakts.
Fügen Sie die vier Dinge hinzu, die eine Exit-Prüfung übersieht
Eine Exit-Adresse beantwortet eine Frage. Vier weitere entscheiden, ob sich der Tunnel wie entworfen verhält.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
Die Zielrichtlinie kommt zuerst: Testen Sie einen Flow, der einbezogen werden soll, und einen, der ausgeschlossen werden soll, wenn das Design eine Aufteilung hat. Dann DNS, wo Sie den tatsächlichen Resolver-Pfad untersuchen statt des konfigurierten Werts, denn eine zwischengespeicherte Antwort oder eine gedruckte Einstellung sagt nichts darüber, wohin eine neue Abfrage ging.
Fehlerverhalten braucht einen Plan und einen erhaltenen Wiederherstellungspfad. Beobachten Sie eine neue Anfrage, während der Tunnel nicht verfügbar ist, und denken Sie daran, dass eine alte offene Verbindung kein Beleg für die Fehlerrichtlinie ist. Der Lebenszyklus kommt zuletzt: Wiederholen Sie die Beobachtung nach einem erneuten Verbinden oder einem Dienstneustart, wenn diese Ereignisse die Anforderung betreffen.
Halten Sie Belege fest, kein Urteil
Behalten Sie für jedes Ergebnis den Prozesskontext, das Ziel, die Adressfamilie, die Zeit und die beobachtete Quelle. Diese Menge ist begrenzter Beleg über die Flows, die Sie ausgeübt haben, und sie ist gerade deshalb verteidigbar, weil sie sagt, was sie abdeckte.
Es ist kein Audit der Aufzeichnungen des VPN-Betreibers und kein Zertifikat für jede künftige Anwendung auf dem Gerät.
Schreiben Sie die Grenzen neben das Ergebnis. Ein Test, der nennt, was er nicht abdeckte, übersteht die Prüfung, einer, der behauptet, das Gerät sei verifiziert, nicht. Halten Sie das curl-Handbuch neben den verwendeten Familienselektoren und die Tabelle mit vier Zeilen bei den Ergebnissen.