Sprawdzanie VPN bez interfejsu: jeden przepływ naraz, z dowodami
Bezinterfejsowe urządzenie potrzebuje żądania, którego odpowiedź można odczytać. Przetestuj każdą rodzinę adresów, kontekst i cel, a potem zapisz, czego wynik nie objął.
Na urządzeniu bez interfejsu nie ma przeglądarki do otwarcia ani kłódki do obejrzenia, więc sprawdzenie musi być żądaniem, którego odpowiedź można odczytać. Brzmi to trywialnie, dopóki nie zauważysz, że jeden wynik adresu wyjściowego służy do certyfikowania urządzenia, które uruchamia kilkanaście usług, dwie rodziny adresów i proxy. Poniższy przegląd buduje po jednym ograniczonym dowodzie naraz, w tym samym kontekście, w którym obciążenie naprawdę działa.
Zdecyduj, co test ma udowodnić
Zanim cokolwiek uruchomisz, zapisz oczekiwanie w jednej linii: który przepływ, przez który interfejs, do którego celu i co powinno być widoczne po drugiej stronie. Test bez wyrażonego oczekiwania daje liczbę, której nikt nie potrafi zinterpretować.
Najbardziej użyteczna wersja wskazuje zatwierdzony punkt końcowy, który raportuje widziany adres źródłowy.
Ten punkt końcowy to jedyna część, którą musisz zorganizować. Wszystko inne jest obserwacją po stronie klienta, a obserwacje po stronie klienta zawodzą w ciekawy sposób.
Przeprowadź obserwację w odpowiednim kontekście
Powłoka administratora nie jest środowiskiem obciążenia. Może nieść inną zmienną proxy, inną tabelę routingu w innej przestrzeni nazw albo plik środowiska innego użytkownika. Przeprowadź test w tym samym kontekście hosta, kontenera, przestrzeni nazw lub usługi co sprawdzany obiekt. Inaczej mierzysz własną powłokę.
Na zwykłym hoście oznacza to tego samego użytkownika i tę samą jednostkę. W środowisku kontenerów oznacza wejście do przestrzeni nazw sieci kontenera zamiast testowania z hosta. W usłudze systemd może to oznaczać jednostkę tymczasową z tymi samymi ustawieniami.
Następne żądanie ma sens dopiero, gdy jesteś w odpowiednim kontekście.
Sprawdzaj rodziny adresów osobno
Pytaj o każdą rodzinę wyraźnie, ponieważ udane żądanie IPv4 w ogóle nie ćwiczy ścieżki IPv6. Selektory --ipv4 i --ipv6 wymuszają wybór, a różnica między oboma wynikami sama w sobie jest informacją.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceNieudane żądanie IPv6 nie jest dowodem skutecznej blokady. Może oznaczać, że punkt końcowy nie ma adresu IPv6, że DNS nie zwrócił nic użytecznego albo że urządzenie w ogóle nie ma trasy IPv6. Przeczytaj porażkę, zanim wyciągniesz wniosek. Udane żądanie IPv6 przez tunel to jedyny wynik, który dowodzi, że ścieżka IPv6 jest objęta.
Zapisz obie odpowiedzi obok siebie. Jedna z nich sama to połowa faktu.
Dodaj cztery rzeczy, które pomija kontrola wyjścia
Adres wyjściowy odpowiada na jedno pytanie. Cztery kolejne decydują, czy tunel zachowuje się zgodnie z projektem.
| 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 |
Polityka celów jest pierwsza: przetestuj przepływ, który powinien być objęty, i ten, który powinien być wykluczony, gdy projekt ma podział. Potem DNS, gdzie sprawdzasz rzeczywistą ścieżkę resolvera, a nie skonfigurowaną wartość, bo odpowiedź z pamięci podręcznej albo wydrukowane ustawienie nic nie mówi o tym, dokąd poszło nowe zapytanie.
Zachowanie przy awarii wymaga planu i zachowanej ścieżki odzyskiwania. Obserwuj nowe żądanie, gdy tunel jest niedostępny, i pamiętaj, że stare otwarte połączenie nie jest dowodem w sprawie polityki awaryjnej. Cykl życia przychodzi na końcu: powtórz obserwację po ponownym połączeniu lub restarcie usługi, jeśli te zdarzenia wpływają na wymaganie.
Zapisuj dowody, nie wyrok
Dla każdego wyniku zachowaj kontekst procesu, cel, rodzinę adresów, czas i zaobserwowane źródło. Ten zbiór to ograniczony dowód o przepływach, które ćwiczyłeś, i jest obronny właśnie dlatego, że mówi, co objął.
To nie jest audyt zapisów operatora VPN ani certyfikat dla każdej przyszłej aplikacji na urządzeniu.
Zapisz granice obok wyniku. Test, który mówi, czego nie objął, przechodzi przegląd, a ten, który twierdzi, że urządzenie jest zweryfikowane, nie przechodzi. Trzymaj instrukcję curl obok użytych selektorów rodziny i trzymaj tabelę z czterema wierszami razem z wynikami.