Publiczna lista VPN mówi online; twój klient mówi nie

Otwierasz katalog, sortujesz według szybkości, wybierasz węzeł oznaczony jako online, a klient poddaje się, zanim skończy się łączyć. Lista nie kłamała, ściśle mówiąc. Podawała wynik czyjegoś sprawdzenia, z innej sieci, wcześniejszego momentu, wobec usługi, którą wolontariusz może wyłączyć w dowolnym momencie. Zrozumienie tej luki zamienia męczące polowanie w krótką serię sprawdzeń, które możesz wykonać na dowolnym kandydacie.

Co lista faktycznie zmierzyła

Publiczny katalog przechowuje pola takie jak czas ostatniego sprawdzenia, zaobserwowaną wartość czasu rundy, liczbę sesji i czasem listę protokołów. Każde z nich opisuje ostatnią udaną obserwację z punktu widzenia samego projektu, a nie stan węzła w chwili, gdy dociera twoja paczka.

Świeżość liczy się bardziej niż liczba. Węzeł sprawdzony cztery minuty temu i węzeł sprawdzony cztery godziny temu mogą pokazywać ten sam zielony znacznik, a tylko jeden z nich wciąż przypomina zapisany stan. Szukaj znacznika czasu, nie koloru.

Dobrowolne utrzymanie dodaje drugie źródło zmian, którego żaden monitor nie naprawi. Operator może restartować laptopa, kończyć mu się pasmo, zmieniać dostawcę albo po prostu zamykać pokrywkę. Wpis na liście jest kandydatem, a traktowanie go jak umowy o poziomie usług to błąd kategorii.

Obserwuj etapy klienta, nie wirujący wskaźnik

Każdy klient VPN przechodzi tę samą szeroką sekwencję: rozwiązać nazwę, otworzyć połączenie transportowe, wynegocjować bezpieczeństwo, uwierzytelnić się, a następnie skonfigurować tunel i przekazać dane. Awaria na każdym etapie zostawia inne dowody, a wirujący wskaźnik nie pokazuje żadnego z nich.

Zacznij od rozwiązywania nazw. Jeśli nazwa hosta się nie rozwiązuje, nic na temat dostępności węzła nie zostało sprawdzone, ponieważ połączenie nigdy nie opuściło twojej maszyny. Następnie transport: odrzucona lub przedawniona wymiana TCP lub UDP mówi ci, że punkt końcowy nie odpowiada na tym porcie, co jest realnym ustaleniem o węźle. Potem negocjacja i uwierzytelnianie, gdzie zły certyfikat, wygasły profil albo niedopasowany szyfr zawodzi, podczas gdy węzeł jest zupełnie zdrowy. Dopiero po skonfigurowaniu tunelu awaria routingu lub DNS może wyjaśnić ostatni krok.

Czytaj log klienta z najwyższą szczegółowością, która jeszcze mieści się na ekranie, i zapisz ostatnią udaną linię. Od tej linii zaczyna się diagnoza i zwykle jest ona bardziej pouczająca niż cokolwiek, co pokazuje katalog.

Jedna zmienna na próbę

Porównuj kandydatów z tym samym klientem, tą samą siecią dostępową i tym samym formatem profilu, zmieniając tylko punkt końcowy. W przeciwnym razie awaria może być twoja, a ty przypiszesz ją węzłowi.

Dwie próby wystarczą, by ustalić wzorzec, a trzecia go potwierdza. Jeśli węzeł A zawodzi na etapie transportu, a węzeł B przy uwierzytelnianiu, masz dwa niepowiązane problemy, a nie jedną przestarzałą listę.

Kiedy każdy węzeł zawodzi w ten sam sposób

Ogólna awaria na pierwszym etapie wskazuje na twoją stronę: resolver, który nie potrafi odpowiedzieć, lokalna zapora blokująca protokół albo sieć dopuszczająca tylko ruch webowy. Katalog nie może tego zgłosić, bo jego sondy nie działają z twojego miejsca.

Sprawdź świadomie przypadek ukształtowanej sieci. Niektóre sieci dostępowe pozwalają na HTTPS do sieci i odrzucają inne protokoły, przez co każdy kandydat wygląda na martwego, choć lista jest dokładna. Porównanie ładowania strony w przeglądarce z surową próbą połączenia rozdziela te dwie sytuacje w mniej niż minutę.

Czytaj awarię na tym etapie, na którym wystąpiła

Odtwórz próbę z terminala, aby etapy były widoczne. Trzy poniższe polecenia rozwiązują nazwę, sprawdzają, czy port odpowiada, i wypisują linie negocjacji z profilu OpenVPN:

dig +short node.example.net
curl -s --max-time 5 telnet://node.example.net:443
openvpn --config node.ovpn --verb 4 2>&1 | grep -iE "TLS|AUTH|PUSH"

Jeśli port odpowiada, a linia negocjacji zgłasza problem z certyfikatem, węzeł działa, a twój profil jest przestarzały. Jeśli port w ogóle nie odpowiada, wpis jest kandydatem, który zawiódł, i przejście do następnego jest właściwą reakcją zamiast debugowania klienta. Zapisz etap w krótkiej linii, a następna próba zacznie się od wiedzy, nie od nadziei.