VPN połączony, ale nie ma internetu? Przejdź cztery warstwy

Klient mówi połączony, przeglądarka się kręci, a każda witryna kończy się przekroczeniem czasu. Ten układ jest częsty i nie jest sprzecznością: połączony znaczy, że tunel wynegocjował połączenie, i nic więcej. Rozwiązywanie nazw, trasowanie i samo wyjście serwera zawodzą każde na swój sposób, a każde ma innego właściciela. Przechodź warstwy po kolei i zatrzymaj się na pierwszej, która zawodzi.

Zacznij od sieci, z której przyszedłeś

Zerwij tunel własnym przyciskiem rozłączenia klienta, a potem spróbuj dwóch niezwiązanych witryn HTTPS, jeśli polityka pozwala. Zostaw wrażliwą pracę zamkniętą na czas tego testu. Jeśli zwykły dostęp też zawodzi, VPN nie jest pierwszym podejrzanym.

Spójrz na łącze Wi-Fi, router i każdą stronę portalu wymagającą logowania, zanim dotkniesz tunelu. Kill switch może blokować ruch po rozłączeniu z założenia, więc postępuj według jego udokumentowanej procedury testowej, zamiast uznawać, że sieć jest martwa. Inna zaufana sieć to przydatne porównanie, a nowe wyjście VPN nie dokończy wygasłego logowania w hotelu. Jeśli otwarta sieć działa, a tunel nie, sieć jest oczyszczona i następna warstwa należy do ciebie.

Ustal, czy awaria dotyczy rozwiązywania nazw

Zapisz treść błędu, bo awaria rozwiązywania, przekroczenie czasu i ostrzeżenie o certyfikacie wskazują każde gdzie indziej. Wzorzec, który trzeba złapać wcześnie, to nazwa hosta, której nigdy nie odwiedziłeś, zawodząca, podczas gdy aplikacja z otwartą sesją działa dalej. Ten wzorzec dotyczy nowych zapytań, a nie tego, czy tunel przenosi pakiety. Jedno zapytanie pokazuje, co zwraca resolver, i zajmuje sekundę. Spróbuj też drugiej nazwy, żeby jedna odpowiedź z pamięci podręcznej albo jeden uszkodzony rekord nie rozstrzygnęły diagnozy.

nslookup example.com

Dowolny adres IP w pasku adresu HTTPS nie jest testem DNS, bo certyfikat i host wirtualny zwykle zależą od nazwy. Nazwy wewnętrzne mogą wymagać resolvera organizacji zamiast publicznego zamiennika, a przeglądarka z własnym bezpiecznym resolverem może odpowiedzieć inaczej niż zapytanie systemu operacyjnego. Tam, gdzie oba się różnią, resolver przeglądarki jest tym, czego doświadcza użytkownik, i ta różnica należy do zgłoszenia.

Pełny tunel czy tylko podsieci firmowe

Niektóre profile istnieją tylko po to, by dotrzeć do kilku podsieci firmowych; inne są zbudowane, by nieść wszystko, i potrzebują działającego wyjścia za sobą. Przeczytaj udokumentowany cel, zanim uznasz, że wskaźnik obejmuje każdą aplikację i każdą rodzinę adresów. Profil sieci prywatnej może działać dokładnie tak, jak zaprojektowano, podczas gdy przeglądarka, która nigdy nie miała go używać, nadal zawodzi. Przeczytaj tablicę tras bez jej zmieniania i uwzględnij IPv6, bo działająca trasa IPv4 nic nie mówi o drugiej rodzinie.

Bardziej szczegółowa trasa może wygrać, gdy trasa domyślna nadal istnieje, dlatego tablicę trzeba czytać, a nie zakładać. Konkurujące adaptery wirtualne też mogą mieć ruch, którego oczekiwałeś gdzie indziej, zwłaszcza po zainstalowaniu i zapomnieniu drugiego klienta VPN. Nie usuwaj trasy domyślnej jako eksperymentu; to zamienia diagnozę w drugą awarię.

Jedna zawodząca witryna pośród działających to problem tej witryny, a to także dowód, że tunel przenosi ruch. Zawieszenia pojawiające się tylko przy dużych transferach wskazują na rozmiar pakietu, a nie na osiągalność.

Gdy serwer nigdy niczego nie przekazuje

Jeśli każde miejsce docelowe zawodzi na dwóch urządzeniach i w dwóch sieciach dostępu, tunel jest podniesiony, a wyjście nie przekazuje. To właśnie ta para oddziela awarię po stronie serwera od jednego urządzenia źle skonfigurowanego w jednym miejscu. Wyślij operatorowi pytania o przekazywanie, NAT i drogę powrotną, a nie zrzut ekranu wskaźnika.

Te trzy obejmują większość przyczyn po stronie serwera, a odpowiedź należy do operatora. Strona rozwiązywania problemów z łącznością OpenVPN przechodzi te same pytania od strony serwera, więc przekaż ją ze zgłoszeniem. Zrzut ekranu zielonego wskaźnika nie odpowiada na żadne z nich.

Przejrzyj dziennik klienta po zalogowaniu pod kątem błędów stosowania tras, ustawień DNS lub adaptera wirtualnego. Błędy na tym etapie wskazują na urządzenie, a nie na serwer. Błąd, który nigdy nie pojawia się w dzienniku, jest równie pouczający, bo przenosi podejrzenie na drugą stronę.

Sprawdzaj jedną warstwę naraz

Gdy coś zmienisz, połącz się ponownie i powtórz dokładnie tę aplikację, która zawiodła. Jedna wczytana strona dowodzi mniej niż powtarzalna droga do zasobów, dla których zbudowano profil. Dwie komendy oddzielają rozwiązywanie od osiągalności, a druga zależy od hosta. Uruchom wiersz curl gdziekolwiek, a potem komendę tras dopasowaną do hosta przed tobą.

curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://example.com
route print -4          # Windows
ip -4 route show        # Linux
netstat -rn | head      # macOS

Jeśli zapytanie numeryczne działa, a nazwa nie, zostań przy DNS. Jeśli żadne nie działa, porównaj tablicę tras z oczekiwanym domyślnym tunelem i sprawdź rodzinę, którą naprawdę testujesz. Jeśli trasa jest poprawna, a zapytanie nadal umiera na wyjściu, pozostałe pytanie należy do operatora, a dowody, które zachowałeś, są zgłoszeniem.