VPN działa, ale jedna aplikacja nie ma internetu? Sprawdź jej proxy

Twój tunel jest podniesiony, strona statusu pokazuje zdrowy handshake, ale jedna aplikacja nadal nic nie wczytuje. Ta aplikacja prawdopodobnie wciąż wysyła żądania do starszego pośrednika: proxy systemowego, rozszerzenia, pliku konfiguracyjnego wypychanego przez zarządzanie urządzeniami albo zmiennej proxy, którą czyta tylko jej własny proces. Zmiana serwera VPN nie dotknie tego ustawienia i to wyjaśnia wzorzec, w którym inne aplikacje działają z tej samej maszyny. Pracuj od niedziałającej aplikacji na zewnątrz i zostaw tunel w spokoju, dopóki sprawa proxy nie zostanie rozstrzygnięta.

Która warstwa posiada ustawienie proxy

Cztery miejsca mogą rościć sobie prawo do władzy nad żądaniami aplikacji, a zwykle wygrywa najwęższe. System operacyjny trzyma globalne proxy i opcjonalny adres URL automatycznej konfiguracji; przeglądarka może go przestrzegać, nadpisać go lub przekazać kontrolę rozszerzeniu; narzędzie wiersza poleceń czyta własne środowisko; a polityka zarządzana może po zmianie ponownie przypiąć którekolwiek z powyższych. Zdecyduj, która warstwa odpowiada, zanim cokolwiek edytujesz, bo wyczyszczenie niewłaściwej warstwy wygląda jak udana naprawa, która wraca przy kolejnym logowaniu.

Porównaj dwie aplikacje na tej samej zwykłej stronie internetowej, a nie na stronie testowej przeznaczonej tylko dla VPN. Jeśli przeglądarka zawodzi, a pobieranie w terminalu się udaje, system operacyjny nie jest problemem, a różnica tkwi w profilu przeglądarki lub jej rozszerzeniach. Jeśli obie zawodzą, ale drugie konto użytkownika na tej samej maszynie działa, ustawienie jest per użytkownik. To porównanie kosztuje minutę i usuwa większość domysłów.

Odczytaj wartość, której każde narzędzie naprawdę używa

Wydrukuj konfigurację przed zmianą i skopiuj dokładny ciąg proxy w miejsce, z którego możesz go przywrócić. Zmienne powłoki to najszybsza kontrola dla narzędzi wiersza poleceń, bo klient VPN zwykle zostawia je nietknięte.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Uruchom tylko tę linię, która pasuje do platformy przed tobą, a potem odczytaj dane wyjściowe dla hosta, portu i poświadczeń. Wartość taka jak http://proxy.corp.example:8080 oznacza, że narzędzie pyta ten host przy każdym żądaniu, a pusty wynik oznacza, że idzie bezpośrednio i prawdziwa usterka jest gdzie indziej. Zasłoń część z użytkownikiem i hasłem przed wklejeniem danych wyjściowych do zgłoszenia, bo te ciągi znacznie częściej są żywymi poświadczeniami, niż ludzie zakładają.

Narzędzia z własnym silnikiem proxy potrzebują własnych dowodów. Curl podaje decyzję, którą podjął po zwiększeniu szczegółowości, co jest lepsze niż zgadywanie ze środowiska, a ten sam przełącznik pokazuje, czy rozwiązywanie nazw odbyło się lokalnie, czy na proxy.

Wyczyść nadpisanie i ponownie przetestuj to samo żądanie

Zmień jedną warstwę, a potem powtórz dokładnie to żądanie, które zawiodło, bo inny URL niczego nie dowodzi. Najpierw wyczyść zmienne środowiskowe w bieżącej powłoce, bo ta zmiana jest odwracalna i nie może zepsuć tunelu:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Jeśli szczegółowe dane wyjściowe nadal twierdzą, że jest proxy, to środowisko nie było władzą. Przejdź o poziom wyżej, zamiast piętrzyć kolejne nadpisania.

W macOS sprawdź, czy plik automatycznej konfiguracji nie dostarcza wartości, potem wyłącz proxy usługi i potwierdź zmianę. W Windows pamiętaj, że ustawienie WinHTTP i ustawienie przeglądarki per użytkownik to różne obiekty, więc czyste narzędzie wiersza poleceń może współistnieć z przeglądarką, która nadal wskazuje na stary serwer. Rozszerzenia zasługują na tę samą podejrzliwość: rozszerzenie proxy może przepisywać żądania tylko dla jednego profilu, i to jest dokładnie kształt usterki, która dotyka jednej przeglądarki i niczego więcej.

Sprawdź, czy naprawa przetrwa restart

Ustawienie, które działa tylko w terminalu, który edytowałeś, nie jest naprawione. Otwórz aplikację ponownie z launchera pulpitu, wyloguj się i zaloguj ponownie, i obserwuj, czy stare proxy wraca.

Dwa testy oddzielają prawdziwą naprawę od tymczasowej, a oba powinny zgłosić bezpośrednie połączenie lub zamierzoną wartość. Uruchomienie w czystym środowisku pokazuje, czy oczyszczony proces nadal przejmuje ustawienie systemowe.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Jeśli stara wartość wraca po restarcie, źródłem jest zarządzana polityka lub profil, który ją ponownie stosuje, a właściciel tej polityki musi usunąć wyjątek. Zostaw weryfikację certyfikatów włączoną przez cały czas, bo proxy, które przechwytuje ruch, inaczej będzie wyglądać na rozwiązane, gdy tylko wyłączysz testy. Na koniec zapisz usuniętą wartość i datę w notatkach, aby następna osoba mogła odróżnić celowe proxy od zapomnianego.