VPN ciągle się rozłącza: najpierw sprawdź radio, potem serwer

Rozłączenie VPN może zacząć się dużo wcześniej, nim jakikolwiek ruch dotrze do serwera. Utrata Wi-Fi, przejście z Wi-Fi na sieć komórkową, przeciążenie lokalnego punktu dostępu i telefon, który zasypia, mogą przerwać zewnętrzną ścieżkę, podczas gdy oprogramowanie tunelu zgłasza czysty błąd. Idź od urządzenia na zewnątrz: najpierw łącze, potem własne zdarzenia klienta, następnie kontrolowane porównanie i dopiero na końcu serwer. Ta kolejność powstrzymuje cię przed zmianą węzłów wyjściowych z powodu problemu, który mieszka w pokoju.

Obserwuj łącze, nie ikonę sygnału

Szukaj przejść łącza, a nie kresek sygnału. Urządzenie może pokazywać silny sygnał, gdy punkt dostępu jest nasycony, gdy trwa przejście roamingu albo gdy polityka oszczędzania energii zatrzymuje radio przy wyłączonym ekranie.

Zapisz stan interfejsu, bieżącą bramę i czas każdej zmiany. Potem sprawdź, czy rozłączenie pokrywa się z przejściem. Spadek, który zdarza się za każdym razem, gdy telefon przemieszcza się między pokojami, jest problemem łącza, dopóki nie zostanie dowiedzione inaczej, niezależnie od tego, który serwer pokazuje aplikacja.

Czytaj własne zdarzenia ponownego połączenia klienta

Większość klientów zapisuje powód rozłączenia i znacznik czasu następnej próby. Tunel, który w kilka sekund ponownie negocjuje, a potem działa, to inne zdarzenie niż ten, który pozostaje wyłączony, dopóki nie włączysz go ręcznie.

Powtarzające się krótkie ponowne połączenia wskazują na zewnętrzną ścieżkę, ponieważ klient stale dociera do serwera i traci sesję. Tunel, który pozostaje wyłączony, wskazuje na uwierzytelnianie, zmianę punktu końcowego lub politykę, ponieważ klient nie dociera dość daleko, by cokolwiek stracić. Czytaj oba wzorce osobno, zanim dotkniesz konfiguracji.

Porównuj drugi punkt końcowy ostrożnie

Drugi punkt końcowy to użyteczne porównanie i sam w sobie nie jest kontrolowanym eksperymentem. Zmienia trasę, infrastrukturę i często kraj, więc różnica między dwoma punktami końcowymi nie dowodzi, że pierwszy serwer jest wadliwy.

Utrzymaj urządzenie, sieć dostępu i obciążenie bez zmian i zanotuj, co jeszcze się zmieniło przy przełączeniu. Jeśli oba punkty końcowe zawiodą w tym samym czasie w tym samym miejscu, lokalna ścieżka jest wspólnym czynnikiem. Jeśli zawiedzie tylko jeden, serwer lub trasa do niego staje się głównym tropem. Zapisz czynniki zakłócające, aby wniosek nie wyprzedził dowodów.

Koreluj z serwerem, którym administrujesz

Jeśli administrujesz punktem końcowym, dopasuj czas próby do zapisów nasłuchu i skojarzenia. Kilku niepowiązanych klientów zawodzących na tej samej bramie to inny dowód niż jeden telefon, który spada przy każdym ruchu.

Jedna odpowiedź peera nie ustala ciągłego stanu aplikacji. Po przywróceniu przetestuj zasób, którego naprawdę potrzebujesz, ponieważ udany uścisk dłoni i osiągalny serwer mogą współistnieć z zerwaną ścieżką aplikacji.

Napisz raport, który to zawęża

Oddziel cztery twierdzenia: utratę lokalnego łącza, osiągalność zewnętrzną, negocjację tunelu i własny stan aplikacji. Każde ma własne dowody, a raport, który utrzymuje je osobno, mówi następnej osobie, gdzie patrzeć.

Zanotuj też ograniczenia porównania. Jeśli polityka uniemożliwiła test ścieżki bezpośredniej, powiedz to, zamiast przedstawiać porównanie punktów końcowych jako dowód. Etykieta kraju w aplikacji nie identyfikuje całej trasy, a serwer położony geograficznie blisko nadal może być osiągalny przez zatłoconą ścieżkę.

Strona znanych ograniczeń projektu WireGuard to użyteczne przypomnienie, że protokół może być poprawny i mimo to pozostawić zachowanie łącza systemowi operacyjnemu. Zakończ powtórzeniem tego samego testu po następnym rozłączeniu, bo pojedyncze zdarzenie to punkt danych, a wzorzec to diagnoza.