Kill-Switch-Test: Messen Sie die Lücke, nicht nur die Wiederverbindung

Eine schnelle Wiederverbindung beweist, dass der Client schnell ist. Protokollieren Sie, was die Maschine während der Lücke verließ, zusammen mit dem verwendeten Auslöser, sonst hat der Test nur die Hälfte gemessen.

Eine Wiederverbindung, die in einer Sekunde abgeschlossen ist, sagt Ihnen, dass der Client schnell ist. Sie sagt nicht, ob während der Tunnelpause etwas entkommen ist. Eine Wiederverbindung, die eine Minute dauert, sagt Ihnen, dass der Client langsam ist, und immer noch nicht, ob direkter Datenverkehr in der Lücke erlaubt war. Das sind zwei Messungen, und ein Kill-Switch-Test, der nur die erste meldet, hat den Schalter nicht getestet.

Zwei Beobachtungen, zwei getrennte Urteile

Die Verfügbarkeitsfrage ist einfach: Wann war der Tunnel wieder nutzbar, und brauchte die geschützte Anwendung eine neue Verbindung, um dorthin zu gelangen. Die Durchsetzungsfrage ist anders: Welche Pakete verließen die Maschine zwischen dem Moment, in dem der Schutz ausfiel, und dem Moment, in dem er zurückkehrte.

Beantworten Sie sie mit getrennten Aufzeichnungen. Eine Zeile sagt, die Lücke dauerte eine bestimmte Zahl von Sekunden. Eine andere Zeile sagt, ob eine ungeschützte Anfrage in dieser Lücke erfolgreich war. Beides zu einem einzigen Bestanden oder Durchgefallen zu verschmelzen, verbirgt den wichtigsten Fall: eine schnelle Wiederverbindung mit einem Leck.

Bauen Sie eine Sonde, die Sie messen können

Verwenden Sie eine Anfrage, die harmlos, billig und unabhängig vom eigenen Steuerkanal des Tunnels ist. Die Schleife unten gibt einmal pro Sekunde einen Zeitstempel, einen HTTP-Status und die verstrichene Zeit aus, und sie schlägt laut fehl, statt zu hängen:

while true; do
  printf '%s ' "$(date +%H:%M:%S)"
  curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 2 https://example.com || echo "curl-exit-$?"
  sleep 1
done

Lesen Sie die Exit-Codes von curl, nicht nur den Status. Eine 28 bedeutet, dass die Anfrage das Zeitlimit überschritt, so sieht ein blockierter Pfad aus. Eine 6 bedeutet, dass die Namensauflösung fehlschlug, was ein anderer Befund und oft der interessantere ist. Eine 200 mit kurzer verstrichener Zeit während der Lücke bedeutet, dass Verkehr hinausgelassen wurde.

Schreiben Sie die Ausgabe in eine Datei und behalten Sie sie. Der Verlauf des Terminals ist kein Beweis, und der interessante Teil sind meist drei Zeilen in der Mitte.

Lösen Sie einen echten Fehler aus, keinen aufgeräumten

Das Trennen über das Menü des Clients testet den kooperativen Pfad, auf dem der Client Zeit hat, seine Sperrregeln zu installieren. Töten Sie stattdessen den Prozess oder brechen Sie die darunterliegende Verbindung ab, und Sie testen den Pfad, den ein tatsächlicher Fehler nimmt.

Jeder Auslöser übt einen anderen Codepfad aus. Ein Ausfall auf der Serverseite, ein lokaler Verbindungsverlust und ein Absturz des Clients können jeweils unterschiedlichen Zustand hinterlassen, und einer davon ist wahrscheinlich der Fall, auf den Sie irgendwann treffen. Führen Sie die Sonde über mindestens zwei Auslöser aus und kennzeichnen Sie die Ergebnisse nach Auslöser.

Lesen Sie das Protokoll, um zu sehen, wie erlaubter Verkehr aussieht

Eine 200 oder ein schneller Verbindungsfehler während der Lücke ist ein Leck, in welche Richtung es auch zeigt. Timeouts über die gesamte Lücke sind die erwartete Form einer Sperrrichtlinie. Namensauflösung, die gelingt, während Verbindungen scheitern, deutet darauf hin, dass der Resolver noch erreichbar ist, was ein Leck anderer Art ist.

Bestehende Sockets brauchen Sorgfalt. Ein Programm kann eine Verbindung weiter nutzen, die es vor der Trennung geöffnet hat, sodass scheinbar lebendiger Verkehr nicht beweist, dass ein neuer Pfad erlaubt war. Die Socket-Liste zeigt, ob eine Verbindung älter als das Ereignis ist:

ss -tunp | grep -E 'ESTAB|SYN-SENT'
ip route get 198.51.100.7
resolvectl status | sed -n '1,20p'

Vergleichen Sie die Startzeit des Sockets mit dem Zeitstempel der Trennung. Eine Verbindung, die älter als der Ausfall ist, belegt die Wiederverwendung eines Sockets, nicht ein Leck, und sie als Fehler zu melden, schickt die nächste Person auf die Suche nach einem Fehler, den es nicht gibt.

Halten Sie das Ergebnis in einer Form fest, die ein Update übersteht

Notieren Sie den Auslöser, die Lücke in Sekunden, ob eine unblockierte Anfrage erfolgreich war, ob die Namensauflösung erfolgreich war und die Versionen von Client und Betriebssystem. Dieser Satz von fünf Fakten lässt sich über Releases hinweg vergleichen, was ein Absatz Prosa nicht kann.

Führen Sie denselben Test nach einem Client-Update oder einer Profiländerung erneut aus, denn Sperrverhalten ist ein Implementierungsdetail und es verschiebt sich. Der Sinn der Aufzeichnung ist, die Verschiebung zu bemerken, bevor sie zum Vorfall wird, nicht den Client einmalig zu zertifizieren.

Ähnliche Artikel