Test kill switcha: mierz lukę, nie tylko ponowne połączenie

Ponowne połączenie, które kończy się w sekundę, mówi, że klient jest szybki. Nie mówi, czy coś uciekło, gdy tunel był wyłączony. Ponowne połączenie, które trwa minutę, mówi, że klient jest wolny, i nadal nie mówi, czy w luce dozwolony był ruch bezpośredni. To dwa pomiary, a test kill switcha, który raportuje tylko pierwszy, nie sprawdził przełącznika.

Dwie obserwacje, dwa osobne werdykty

Pytanie o dostępność jest proste: kiedy tunel znów stał się użyteczny i czy chronionej aplikacji potrzebne było nowe połączenie, by tam dotrzeć. Pytanie o egzekwowanie jest inne: które pakiety opuściły maszynę od chwili, gdy ochrona spadła, do chwili, gdy wróciła.

Odpowiedz na nie osobnymi zapisami. Jedna linia mówi, że luka trwała określoną liczbę sekund. Druga linia mówi, czy w tej luce powiodło się niechronione żądanie. Zlanie ich w jedno zaliczone lub niezaliczone ukrywa najważniejszy przypadek: szybkie ponowne połączenie z wyciekiem.

Zbuduj sondę, którą można zmierzyć w czasie

Użyj żądania, które jest nieszkodliwe, tanie i niezależne od własnego kanału sterowania tunelu. Pętla poniżej wypisuje raz na sekundę znacznik czasu, status HTTP i upływający czas, a zamiast zawieszać się głośno zawodzi:

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

Czytaj kody wyjścia curl, a nie tylko status. 28 oznacza, że żądanie przekroczyło czas, tak wygląda zablokowana ścieżka. 6 oznacza, że rozwiązywanie nazw nie powiodło się, co jest innym ustaleniem i często ciekawszym. 200 z krótkim upływem czasu w luce oznacza, że ruchowi pozwolono wyjść.

Zapisz dane wyjściowe do pliku i zachowaj go. Historia terminala nie jest dowodem, a ciekawa część to zwykle trzy linie w środku.

Wywołaj prawdziwą awarię, nie uporządkowaną

Rozłączenie z menu samego klienta testuje ścieżkę kooperatywną, w której klient ma czas zainstalować swoje reguły blokowania. Zamiast tego zabij proces albo zerwij łącze pod spodem, a przetestujesz ścieżkę, którą idzie prawdziwa awaria.

Każdy wyzwalacz ćwiczy inną ścieżkę kodu. Awaria po stronie serwera, utrata łącza lokalnego i awaria klienta mogą zostawić różny stan, a jeden z nich to prawdopodobnie przypadek, na który w końcu trafisz. Uruchom sondę z co najmniej dwoma wyzwalaczami i oznacz wyniki według wyzwalacza.

Czytaj dziennik, by zobaczyć, jak wygląda dozwolony ruch

200 lub szybkie niepowodzenie połączenia w luce to wyciek, w którąkolwiek stronę wskazuje. Przekroczenia czasu przez całą lukę to oczekiwany kształt polityki blokowania. Powodzenie rozwiązywania nazw przy nieudanych połączeniach sugeruje, że resolver jest nadal osiągalny, co jest wyciekiem innego rodzaju.

Istniejące sockety wymagają ostrożności. Program może dalej używać połączenia otwartego przed rozłączeniem, więc pozornie żywy ruch może nie dowodzić, że zezwolono na nową ścieżkę. Lista socketów pokazuje, czy połączenie jest starsze niż zdarzenie:

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

Porównaj czas rozpoczęcia socketu ze znacznikiem czasu rozłączenia. Połączenie starsze niż awaria jest dowodem ponownego użycia socketu, a nie wycieku, a zgłoszenie go jako awarii wysyła następną osobę na polowanie na błąd, którego nie ma.

Zapisz wynik w formie, która przetrwa aktualizację

Zapisz wyzwalacz, lukę w sekundach, czy powiodło się jakiekolwiek nieblokowane żądanie, czy powiodło się rozwiązywanie nazw oraz wersje klienta i systemu operacyjnego. Ten zestaw pięciu faktów można porównywać między wydaniami, czego nie potrafi akapit prozy.

Uruchom ten sam test ponownie po aktualizacji klienta lub zmianie profilu, bo zachowanie blokowania jest szczegółem implementacji i się przesuwa. Sensem zapisu jest zauważenie przesunięcia, zanim stanie się incydentem, a nie jednorazowe certyfikowanie klienta.