Limit czasu połączenia VPN: DNS, transport, negocjacja czy logowanie

„Połączenie przekroczyło limit czasu” to najmniej konkretny błąd, jaki może wypisać klient VPN. Oznacza, że jedna operacja minęła swój termin, a każdy etap od rozwiązania nazwy do odpowiedzi logowania ma termin. Klienci, którzy pokazują tylko końcowy komunikat, sprawiają, że etapy wyglądają identycznie, więc ludzie podnoszą limit, zmieniają port i reinstalują profil, w tej kolejności, nie ucząc się niczego. Porównanie etapów jest szybsze: każdy zawodzi w innym miejscu, a każda awaria zostawia inny rodzaj dowodu.

Cztery etapy, cztery różne awarie

Sekwencja jest stała, nawet gdy klient ją ukrywa: nazwa musi zostać rozwiązana, do wynikowego adresu trzeba ustanowić transport, protokół musi wynegocjować parametry i klucze, a konto musi zostać uwierzytelnione. Przewodnik OpenVPN po rozwiązywaniu problemów z łącznością stosuje tę samą kolejność dla własnego klienta, a pozostałe podążają za nią blisko. Limit czasu na drugim etapie i limit na czwartym nie mają ze sobą nic wspólnego poza słowem na ekranie.

Czytaj dziennik, szukając ostatniej linii wskazującej postęp, a nie ostatniej linii przed błędem. Większość klientów wypisuje coś w rodzaju rozwiązania adresu, ustanowionego gniazda, rozpoczętego uzgadniania lub żądania uwierzytelnienia, a etap następujący po tej linii to ten, który przekroczył limit.

Rozwiązywanie nazwy zawodzi przed jakimkolwiek kontaktem

Jeśli punkt końcowy nigdy się nie rozwiązuje, klient nie ma do czego się połączyć i nie wykonano żadnej pracy transportowej. Ta awaria jest zwykle natychmiastowa, a nie pełnym limitem czasu, i to najtańszy sposób odróżnienia jej od reszty. Sprawdź nazwę resolverem systemowym i drugim resolverem, i porównaj obie odpowiedzi, zanim uznasz, że serwer nie działa.

Stary adres skopiowany z postu na forum to częsta przyczyna limitu czasu, który wygląda jak problem serwera, ponieważ adres należy teraz do czegoś innego albo do niczego. Użyj bieżącego profilu operatora zamiast zastępować adres, który kiedyś działał. Brak odpowiedzi ping nie jest dowodem w żadną stronę: wiele punktów końcowych odrzuca ICMP, a mimo to dobrze obsługuje.

Konfiguracja transportu czeka na pakiet, który nie przyjdzie

Gdy DNS jest w porządku, a klient nadal spala cały limit, podejrzaną jest warstwa transportowa. W TCP możesz przetestować port bezpośrednio; Test-NetConnection w Windows lub nc -vz w Linux powie ci, czy coś przyjmuje połączenie, i to jest użyteczniejsze niż ping. W UDP nie da się sprawdzić w ten sam sposób, bo w tej warstwie nie ma uzgadniania do ukończenia, a ta asymetria powoduje wiele błędnych wniosków.

To, co dowodzi test TCP, jest ograniczone: usługa przyjmująca port 443 niekoniecznie jest nasłuchiwaczem VPN, a punkt końcowy tylko z UDP nie ma portu TCP, by cokolwiek przyjąć. Przepisanie profilu z UDP na TCP nie tworzy nasłuchiwacza po drugiej stronie; zmienia tylko to, na co czeka twój klient. Jeśli sieć filtruje protokół, zmiana powoduje inny limit czasu na tym samym etapie.

Portale przechwytujące zasługują na własną kontrolę na tym etapie. Dopóki portal nie autoryzuje urządzenia, ruch wychodzący idzie do portalu, a próba tunelu po prostu wisi. Najpierw dokończ portal w przeglądarce, potem spróbuj ponownie, i nie zmieniaj profilu, dopóki portal jest jeszcze w toku.

Negocjacja i logowanie oznaczają, że serwer odpowiedział

Gdy tunel dotrze do serwera, klient rozpoczyna uzgadnianie, a błąd zmienia charakter. Zatrzymanie tutaj dotyczy zgodności, nie osiągalności: niedopasowane wersje protokołu, ustawienie szyfru lub kanału danych, którego druga strona nie zaakceptuje, albo profil oczekujący funkcji, której serwer nie oferuje. OpenVPN przesuwał swoje domyślne ustawienia negocjacji między głównymi wersjami dość często, by profil napisany dla jednej generacji mógł dotrzeć do serwera i mimo to nie wstać.

Uwierzytelnianie to ostatni etap i najłatwiejszy do błędnego odczytu. Jawne odrzucenie jest odpowiedzią, co oznacza, że ścieżka działa, a problemem jest tożsamość, certyfikat lub stan konta. Przepływ jednokrotnego logowania oparty na przeglądarce to trzeci przypadek: klient czeka na działanie, którego nie wykonałeś, albo na przeglądarkę, której nie może uruchomić, i nic nie nadejdzie, dopóki nie dokończysz tego kroku.

Porównaj dowody, zanim zmienisz ponowną próbę

Trzymaj urządzenie i profil nieruchomo i zmieniaj jedną rzecz naraz, zaczynając od sieci. Jeśli ten sam profil łączy się przez hotspot telefonu i przekracza limit w Wi-Fi hotelu, zmienną jest ścieżka, nie serwer. Jeśli zawodzi wszędzie, zmienną jest profil lub punkt końcowy. Jeśli zawodzi tylko o jednej porze dnia, zapisz znacznik czasu i porównaj go ze zdarzeniami po stronie serwera, zanim cokolwiek założysz o obciążeniu.

Dla usługi, którą administrujesz, decydującym porównaniem jest to, czy próba w ogóle dociera. Połączenie, które dociera do nasłuchiwacza i potem się zatrzymuje, należy do etapu negocjacji; to, które nigdy nie pojawia się w polu widzenia nasłuchiwacza, jest problemem transportu lub rozwiązywania nazw, i żadne dostrajanie ponownych prób tego nie ruszy. Logi serwera rozdzielają też odrzucone logowanie od cichego porzucenia, a to różnica między poprawką tożsamości a poprawką zapory.

Zapisz wersję klienta, nazwę profilu, czas próby ze strefą czasową i pierwszy użyteczny błąd zamiast ostatniej linii rozłączenia. Usuń klucze i materiał zawierający poświadczenia, zanim udostępnisz fragment. Potem zrób jedną sensowną poprawkę i spróbuj ponownie, bo dłuższy termin pomaga tylko udokumentowanej wolnej operacji i nic nie daje w przypadku błędnego adresu czy zablokowanego portu.