Jak przetestować przełącznik VPN bez prawdziwych kont
Przeprowadź test przełącznika z przynętą i zapasowym profilem: pokryj każdy typ przerwy, odczytaj kody wyjścia curl i odróżnij prawdziwą blokadę od awarii DNS.
Nie potrzebujesz prawdziwego konta, by sprawdzić, czy przełącznik blokujący trzyma; to właśnie konto test stawia na szali. Sprawdzenie tworzy krótkie okno, w którym ruch może, ale nie musi wyjść poza tunel, więc ładunkiem powinno być coś, co możesz stracić. Robię to teraz z przynętą i zapasowym profilem przeglądarki i dostaję jaśniejszą odpowiedź niż przy poprzedniej rutynie z przeglądarką i pocztą webową. Dalej idę w tej samej kolejności, którą pokazuje klient: ustawienie, cel, przejście, a potem dowód.
Test odpowiada tylko na jedno wąskie pytanie: czy podczas tego przejścia ta aplikacja może dotrzeć do sieci poza tunelem? nie mówi nic o tym, czy reszta polityki jest sensowna. Trzymaj zakres tak wąski, a wynik będzie wart zapisania.
Znajdź przełącznik i jego zakres w kliencie
Otwórz klienta i znajdź ustawienie blokowania, zanim zmienisz jakikolwiek stan sieci. Producenci nazywają je różnie: przełącznik blokujący, tryb blokady, blokada sieci, blokowanie ruchu poza tunelem. Etykieta mówi mniej niż opcje w środku. Liczy się to, czy blokada działa zawsze, czy tylko gdy aplikacja uzna, że tunel właśnie zawiódł, oraz czy obejmuje wszystkie aplikacje, czy wybraną listę.
Następnie wypisz przejścia, które twój klient naprawdę potrafi wykonać. Rozłączenie zainicjowane przez użytkownika, wyjście z aplikacji i utrata kontaktu z serwerem to w większości klientów trzy różne ścieżki kodu i nie dzielą jednej polityki blokowania. Jedne zdejmują blokadę przy wyjściu z aplikacji. Inne zostawiają reguły filtra, dopóki coś ich nie usunie. Przeczytaj dokumentację ustawień producenta dla swojej kompilacji, zamiast zakładać, a potem zapisz, który z trzech przypadków testujesz.
Zapisz też profil: protokół, rodziny adresów i czy włączony jest tunel dzielony. Twierdzenie o ochronie całego urządzenia jest bez sensu, jeśli profil celowo wyklucza kilka aplikacji, a wykluczenie, które sam skonfigurowałeś, nie jest wyciekiem. Dokumentacja ustawień OpenVPN Connect to właśnie taka strona, która nazywa, który przełącznik zmienia które zachowanie, choć etykiety różnią się między klientami.
Wybierz przynętę, która działa też bez tunelu
Przynęta musi mieć dwie właściwości, a pominięcie którejkolwiek daje nieczytelny wynik. Musi być osiągalna bezpośrednio, gdy tunel jest wyłączony, a blokada wyłączona, bo inaczej informacja, że przestała odpowiadać, może po prostu oznaczać, że host zniknął. I nie może wymagać logowania, pliku cookie ani płatności, żeby wyciek kosztował jedną linię logu, a nie sesję.
Statyczna strona na hoście, który kontrolujesz, to najczystszy wybór. Zapasowa maszyna wirtualna z prostym serwerem HTTP jest prawie tak samo dobra, a publiczna strona sprawdzania łączności też się nada, jeśli akceptujesz, że jej dostępność jest poza twoją kontrolą. Zapisz adres, port, rodzinę adresów i to, czy żądanie wymaga wyszukania nazwy, bo każdy z tych punktów staje się zmienną, którą później możesz musieć wyizolować.
Ustal stan bazowy, zanim dotkniesz przełącznika. Gdy tunel jest włączony, przynęta musi odpowiadać przez tunel, co dowodzi, że trasa zgodna z polityką działa. Gdy tunel jest wyłączony, a blokada wyłączona, musi odpowiadać bezpośrednio, co dowodzi, że cel żyje. Dopiero wtedy niepowodzenie w zablokowanym stanie coś ci powie.
Wykonuj przejścia w ustalonej kolejności
Wykonuj przejścia po jednym i daj każdemu kilka sekund na ustabilizowanie się, bo klienci często właśnie w tej przerwie burzą i odbudowują reguły. Powtarzanie tego samego krótkiego testu za każdym razem czyni obserwacje porównywalnymi:
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
Wiersz z wyjściem z aplikacji zasługuje na osobne uruchomienie, nawet jeśli w normalnym użyciu nigdy nie zamykasz klienta. Jeśli blokada zwalnia się przy wyjściu, awaria lub wymuszona aktualizacja daje ci tę samą ekspozycję, a to fakt o wdrożeniu, nie o twojej cierpliwości. W systemie Windows równoważne próby to Resolve-DnsName decoy.example i curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Oddziel blokadę od zepsutego resolvera
Strona, która się nie ładuje, ma kilka przyczyn, a tylko jedna z nich to działający przełącznik. Jeśli nazwa się nie rozwiązuje, dowiedziałeś się, że DNS jest zablokowany lub zepsuty, a nie że ścieżka danych jest zablokowana. Sprawdź też adres dosłowny, żeby odpowiedź w ogóle nie zależała od rozwiązywania nazw.
Kody wyjścia curl rozdzielają te przypadki. 6 to błąd rozwiązywania nazwy, 7 oznacza odrzucone połączenie, 28 to przekroczenie czasu. Zablokowana trasa zwykle objawia się przekroczeniem czasu lub odmową przy adresie dosłownym, a blokada samego DNS zostawia 6 i ukrywa wszystko inne. Zbuforowana strona lub portal przechwytujący oszukują oko, dlatego dowodem jest kod wyjścia, a nie ekran.
Powtórz próbę przez IPv6 z adresem dosłownym. Blokada, która obejmuje IPv4 i ignoruje IPv6, jest dość powszechna, by zasłużyć na osobną linię w notatkach, a klient wyłączający IPv6 poza tunelem powinien czysto zawodzić w obu rodzinach.
Zapisz zakres, który obejmuje wynik
Gdy tunel wróci, potwierdź odzyskanie: przynęta odpowiada przez tunel, resolver zwraca odpowiedzi, a polityka stoi tam, gdzie ją zostawiłeś. Potem cofnij eksperymenty. Tymczasowa reguła zapory, trasa debugowania lub profil testowy pozostawione na miejscu zdezorientują następne uruchomienie i mogą przeżyć aplikację.
Jedno przejście obejmuje jedną kompilację klienta, jeden profil, jedno przejście i jedną rodzinę adresów. Zapisz te cztery razem z wynikiem:
- Kompilacja klienta i platforma oraz to, czy ustawienie jest na profil czy globalne.
- Profil, protokół i wszelkie wykluczenia tunelu dzielonego.
- Testowane przejście i sposób, w jaki je wywołałeś.
- Rodziny adresów i DNS, z kodami wyjścia curl dla stanu zablokowanego i niezablokowanego.
Jeśli którakolwiek linia jest pusta, test nie jest skończony. Roaming oznacza powtórzenie wiersza ze zmianą sieci. Nieobsługiwany restart oznacza sprawdzenie, czy reguły wracają, a to pytanie o kolejność przywracania, nie o przełącznik. Powtarzaj sekwencję po aktualizacji klienta, bo przełączniki rzadko się zmieniają, a zachowanie za nimi owszem. Zatrzymaj przynętę: nic nie trzeba rotować, a następne sprawdzenie zajmuje pięć minut.