Sprawdzić, czy tunel dzielony działa: jeden wynik IP to nie test

Pojedyncza strona przeglądarki pokazująca adres IP nie dowodzi prawie niczego o tunelu dzielonym. Widoczny adres może być właściwy z niewłaściwego powodu, a wykluczony przepływ nigdy nie jest przez nią sprawdzany. Zapisz oczekiwany wynik przed testem: która aplikacja lub cel ma korzystać z tunelu, który ma pozostać bezpośredni i co ma się zatrzymać, gdy tunel zawiedzie. Bez tego planu każda wiarygodna liczba wygląda jak sukces.

Mit: wyszukanie adresu dowodzi pokrycia

Sprawdzenie IP odpowiada na jedno pytanie: co świat zewnętrzny widzi z jednej aplikacji w jednym momencie. Nie mówi nic o wewnętrznym prefiksie, drugim profilu przeglądarki ani nazwie, która powinna być rozwiązywana prywatnie. Nie mówi też nic o awarii, a to właśnie ta połowa projektu tunelu dzielonego, która psuje się w produkcji.

Strona adresu nie pokaże też trasy, resolvera ani polityki awarii. Traktuj ją jako jedną obserwację, nie jako wyrok.

Przetestuj przepływ objęty i wykluczony

Wyślij nieszkodliwe żądanie z aplikacji, która ma być objęta, lub do prefiksu, który, jak oczekujesz, ma być kierowany przez tunel, i zapisz źródło, cel, rodzinę adresów oraz zaobserwowaną ścieżkę. Zrób to samo dla przepływu, który ma pozostać bezpośredni. Strona wykluczona to ta, którą ludzie pomijają, i jest ona jedynym dowodem, że podział jest zamierzony, a nie przypadkowy. Proces pomocniczy może mieć osobną tożsamość polityki, więc testuj w procesie, który posiada gniazdo.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Dlatego test uruchomiony w niewłaściwej aplikacji może pokazać przeciwieństwo tego, co zakłada projekt. Zapisz cztery pola dla obu stron, zanim wyciągniesz jakikolwiek wniosek.

Dodaj DNS i przypadek awarii

Odpytaj resolver systemowy i resolver używany przez aplikację, a następnie porównaj te odpowiedzi z adresem wyjściowym podawanym przez witrynę. Obie warstwy mogą rozmyślnie się różnić, a jedno wyszukanie w przeglądarce nie sprawdza polityki systemu operacyjnego. Powłoka czyni porównanie powtarzalnym: Złam tunel celowo, a potem wykonaj żądanie, którego przeglądarka nie ma w pamięci podręcznej; strona podana z pamięci podręcznej nie mówi nic o tym, w którą stronę poszło obejście. Zapisz, co faktycznie się stało, a nie to, co przewidywał projekt.

curl -s https://ifconfig.me
nslookup intranet.example

Tunel dzielony, który zawodzi zamknięty, i ten, który zawodzi otwarty, wyglądają identycznie, dopóki celowo nie złamiesz tunelu. Zapisz, jakie zachowanie zaobserwowałeś, a nie jakie oczekiwałeś.

Powtórz po zmianie stanu

Powtórz te same obserwacje po ponownym połączeniu, zmianie sieci i istotnej aktualizacji aplikacji. Zapisane wykluczenie może nadal wskazywać ścieżkę lub tożsamość aplikacji, która już nie istnieje, a projekt po cichu przestaje odpowiadać swojej dokumentacji. Te trzy zdarzenia to miejsca, w których tunele dzielone dryfują, a każde z nich jest tanie do ponownego przetestowania. Test uruchamiany tylko raz przy wdrożeniu opisuje konfigurację, która już nie istnieje.

Jeśli wynik się różni, znajdź właściciela reguły i etap przetwarzania, zanim zmienisz kilka ustawień naraz. Zmiana pięciu rzeczy i obserwacja jednego wyniku nie jest diagnozą, to nowa konfiguracja.

Co powinien ustalić wynik

Powiąż obserwacje z polityką i wersją klienta, które faktycznie testowałeś. Celem jest pokazanie, że to wdrożenie odpowiada deklarowanemu pokryciu, a nie że każda przyszła aplikacja będzie prywatna. To węższe twierdzenie i to takie, które naprawdę możesz poprzeć dowodami. Zapisz twierdzenie, wersję i wyniki czterech pól w rejestrze zmian.

Wtedy następny recenzent może stwierdzić, czy zmienił się projekt, czy test. Tunel dzielony jest zweryfikowany, gdy obie strony, podział resolvera i zachowanie przy awarii odpowiadają temu, co zapisałeś na początku. Jeden wynik IP nie weryfikuje żadnego z nich.