Internet działa tylko z włączoną aplikacją VPN? Sprawdź cztery warstwy

Próbujesz przez tydzień darmowego klienta VPN albo rozszerzenia przeglądarki, wyłączasz go i internet przestaje działać. Ikona Wi-Fi nadal pokazuje połączenie, inne urządzenia w tej samej sieci działają bez zarzutu, a jedyne, co przywraca przeglądanie, to ponowne włączenie aplikacji albo jej odinstalowanie. Ten wzorzec nie jest szyfrowaniem, które tworzy zależność. To konfiguracja, którą aplikacja zapisała gdzieś, gdzie tunel nie jest właścicielem.

Klient zmienia ustawienia, których tunel nie posiada

Klient dbający o prywatność w systemie Windows lub macOS zwykle dotyka trzech miejsc naraz. Ustawia systemowe proxy HTTP, czyli to samo pole, które pokazuje Opcje internetowe. Instaluje wirtualny adapter, często sterownik TAP, żeby przechwytywać pakiety. I przepisuje listę resolverów, choć po naciśnięciu rozłącz znika tylko tunel.

Rozszerzenie przeglądarki jest rzeczą węższą. Zwykle zmienia własny profil albo proxy, którego słucha jedna przeglądarka. Dlatego jedna przeglądarka może zawodzić, podczas gdy narzędzia wiersza poleceń działają dalej, albo odwrotnie: rozszerzenie nigdy nie miało uprawnień, by dotknąć pozostałych warstw. To, którą warstwę zmieniło, decyduje o tym, które narzędzia się psują.

Tak czy inaczej, tę nieaktualną decyzję podjęło oprogramowanie, które nie miało powodu jej cofać. Tunel był częścią widoczną i zarazem jedyną częścią z czystą ścieżką zamknięcia. Wszystko inne to ustawienie w magazynie, który przeżywa proces, więc usunięcie aplikacji jest jedynym krokiem cofającym wszystkie trzy naraz. Odczytanie tych magazynów przed ponowną instalacją jest tym, co zamienia objaw w diagnozę.

Trzy pozostałości, trzy różne awarie

Pierwsza pozostałość to proxy wskazujące na nic: pole proxy sieci LAN wciąż zaznaczone albo adres skryptu konfiguracyjnego celujący w port localhost, na którym żaden proces już nie nasłuchuje. Przeglądarka wysyła każde żądanie na ten martwy port i zawiesza się, aż przekroczenie limitu czasu wygląda jak martwa sieć. Druga to adapter, który nadal posiada trasę domyślną, bo urządzenie TAP-Windows albo sterownik tras producenta pozostaje prawdziwym interfejsem po odinstalowaniu. Zachowuje trasę, którą dostał, a ruch znika w tunelu, którego nie ma. Żadna z pozostałości się nie ogłasza; obie wyglądają dokładnie jak awaria.

Trzecia to DNS, i zawodzi wcześniej niż dwie poprzednie. Jeśli lista resolverów zawiera tylko serwery osiągalne przez tunel, każde zapytanie kończy się przekroczeniem czasu, zanim zostanie zamówiona choć jedna strona, więc przeglądarka zgłasza nieosiągalny serwis, a nie martwe proxy. Którąkolwiek z nich masz, żadna nie jest awarią w sensie sieciowym. Każda jest pozostałością, której nikt nie odwołał, i każdą naprawia się w innym miejscu.

Przejdź cztery warstwy

Zacznij najbliżej aplikacji i schodź w dół, bo warstwy zawodzą w tej kolejności widoczności. Zmieniaj jedną warstwę na test i po każdej zmianie testuj ponownie. Resetowanie wszystkiego naraz zwykle przywraca przeglądanie i zostawia cię bez odpowiedzi, która pozostałość była przyczyną, więc następna instalacja odtwarza tę samą zagadkę. Kolejność to proxy, adaptery, trasy, resolvery.

W systemie Windows każde sprawdzenie to jedno polecenie dostarczane z systemem, więc niczego nie trzeba instalować. Uruchom je po kolei i trzymaj wyniki razem, bo cztery odpowiedzi mają sens tylko obok siebie. Raportują proxy, adaptery, trasy IPv4 i listę resolverów, właśnie w tej kolejności:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux i macOS potrzebują własnych poleceń i nie są one wymienne. W Linuksie trasy pochodzą z ip route, a resolver z resolvectl status tam, gdzie zarządza nim systemd-resolved, z odwrotem do cat /etc/resolv.conf. W macOS trasy pochodzą z netstat -rn, resolvery ze scutil --dns, a proxy systemowe ze scutil --proxy. Czytelnik macOS, który uruchomi ip route, dostanie command not found, a /etc/resolv.conf jest tam wygenerowaną atrapą, a nie autorytatywną konfiguracją. Sprawdź platformę, zanim sprawdzisz warstwę, inaczej pierwsze polecenie samo stanie się ustaleniem.

Dla każdej warstwy zadaj jedno pytanie: czy ta wartość nadal wskazuje na coś, co istnieje, gdy aplikacja jest zamknięta? Proxy na martwym porcie, adapter bez tunelu, trasa domyślna przez wyłączony interfejs i resolver wewnątrz tunelu odpowiadają wszystkie nie. Jedno takie nie wystarcza, by wyjaśnić objaw, i dlatego jedna zmiana na test ma znaczenie.

Proxy to nie tunel

Proxy przyjmuje żądanie, pobiera je gdzie indziej i zwraca odpowiedź, co znaczy, że zna cel i widzi wszystko, czego strona sama nie zaszyfrowała. Nie przenosi innych protokołów. Nie chroni ścieżki, chyba że cel już używa TLS. I może być zmienione przez cokolwiek, co je zainstalowało, bez twojego udziału.

To rozróżnienie zmienia pytanie, które warto zadać. Gdy proxy zostaje, ustal, który program nadal kieruje twoją przeglądarką, a nie czy tunel jest włączony. Tunel może być całkiem zdrowy i całkowicie nieistotny dla awarii.

Jeśli chcesz wiedzieć, co taki klient naprawdę zrobił, obserwuj go, zamiast czytać jego panel. Process Monitor zapisuje, których kluczy rejestru i plików dotyka, a przechwycenie pakietów pokazuje, dokąd poszedł jego ruch. Oba są zwykłymi narzędziami i oba odpowiadają na pytanie o pozostałość lepiej niż jakakolwiek lampka stanu. Żadne nie wymaga, by aplikacja nadal działała.

Usuń komponent, nie dowód

Trwałe rozwiązanie to usunięcie tego, co zapisało ustawienie. Odinstaluj aplikację, usuń dodany przez nią wirtualny adapter, wyczyść proxy i listę resolverów, uruchom ponownie i przetestuj, gdy aplikacja wciąż jest odinstalowana. Jeśli przeglądanie wtedy działa, znalazłeś przyczynę, a nie obejście. Zanotuj, która warstwa była nieaktualna, bo ten sam dostawca zwykle dostarcza ten sam błąd dwa razy.

Jeśli objaw wraca po instalacji następnego klienta, przejdź cztery warstwy jeszcze raz, zanim uznasz, że usługa coś zepsuła. Dowód zwykle wciąż tam jest, w jednym z czterech miejsc. Druga aplikacja nie tworzy piątej warstwy; zmienia jedną z czterech.

Ponowna instalacja resetuje proxy, ale nie stary adapter, i może zostawić dwa resolvery na liście. Ta asymetria jest powodem, dla którego odinstaluj-i-przetestuj bije przycisk resetowania wszystkiego. Daje ci też punkt odniesienia do porównania, gdy połączenie następnym razem padnie.