VPN virker, men en app har ingen internet? Se på dens proxy

Din tunnel er oppe, statussiden viser et sundt handshake, og en applikation indlæser stadig intet. Den applikation sender sandsynligvis stadig sine anmodninger til en ældre mellemled: en systemproxy, en udvidelse, en konfigurationsfil, der skubbes ud af enhedsadministration, eller en proxyvariabel, som kun dens egen proces læser. Et nyt VPN-servervalg rører ikke den indstilling, og det forklarer mønstret, hvor andre apps virker fra samme maskine. Arbejd udad fra den app, der fejler, og lad tunnelen være i fred, indtil proxy-spørgsmålet er afklaret.

Hvilket lag ejer proxyindstillingen

Fire steder kan gøre krav på autoriteten over en apps anmodninger, og det snævreste vinder som regel. Styresystemet har en global proxy og en valgfri automatisk konfigurations-URL; en browser kan følge den, tilsidesætte den eller overlade kontrollen til en udvidelse; et kommandolinjeværktøj læser sit eget miljø; og en administreret politik kan fastlåse alt det ovenstående igen efter en ændring. Beslut, hvilket lag der har ansvaret, før du redigerer noget, fordi at rydde det forkerte lag ser ud som en vellykket rettelse, der vender tilbage ved næste login.

Sammenlign to applikationer mod det samme almindelige websted i stedet for mod en testside, der kun er beregnet til VPN. Hvis browseren fejler, mens en download i terminalen lykkes, er styresystemet ikke problemet, og forskellen ligger i browserprofilen eller dens udvidelser. Hvis begge fejler, men en anden brugerkonto på samme maskine lykkes, er indstillingen per bruger. Den sammenligning koster et minut og fjerner det meste gætværk.

Læs den værdi, hvert værktøj faktisk bruger

Udskriv konfigurationen, før du ændrer den, og kopiér den nøjagtige proxystreng til et sted, hvor du kan gendanne den. Shellvariablerne er den hurtigste kontrol for kommandolinjeværktøjer, fordi en VPN-klient normalt lader dem være urørt.

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

Kør kun den linje, der passer til den platform, du har foran dig, og læs derefter outputtet for vært, port og legitimationsoplysninger. En værdi som http://proxy.corp.example:8080 betyder, at værktøjet spørger den vært for hver anmodning, mens et tomt resultat betyder, at det går direkte, og at den egentlige fejl ligger et andet sted. Slør bruger- og adgangskodedelen, før du indsætter outputtet i en sag, fordi de strenge er levende legitimationsoplysninger langt oftere, end folk antager.

Værktøjer med deres egen proxymotor har brug for deres eget bevis. Curl angiver den beslutning, den traf, når du øger detaljegraden, hvilket er bedre end at gætte ud fra miljøet, og det samme flag viser, om navneopløsningen skete lokalt eller ved proxyen.

Ryd tilsidesættelsen og test den samme anmodning igen

Skift et lag, og gentag derefter præcis den anmodning, der fejlede, fordi en anden URL ikke beviser noget. Ryd først miljøvariablerne i den aktuelle shell, da den ændring er reversibel og ikke kan ødelægge tunnelen:

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/'

Hvis det detaljerede output stadig hævder en proxy, var miljøet ikke autoriteten. Flyt et niveau op i stedet for at stable flere tilsidesættelser.

På macOS skal du kontrollere, at en automatisk konfigurationsfil ikke leverer værdien, og derefter slå tjenesteproxyen fra og bekræfte ændringen. På Windows skal du huske, at WinHTTP-indstillingen og browserindstillingen per bruger er forskellige objekter, så et rent kommandolinjeværktøj kan eksistere side om side med en browser, der stadig peger på en gammel server. Udvidelser fortjener samme mistanke: en proxyudvidelse kan omskrive anmodninger for kun én profil, og det er præcis formen på en fejl, der rammer én browser og intet andet.

Bekræft, at rettelsen overlever en genstart

En indstilling, der kun virker i den terminal, du redigerede, er ikke rettet. Åbn applikationen igen fra skrivebordets starter, log ud og ind igen, og se, om den gamle proxy vender tilbage.

To kontroller adskiller en rigtig rettelse fra en midlertidig, og begge bør rapportere en direkte forbindelse eller den tilsigtede værdi. Kørslen i et rent miljø viser, om en strippet proces stadig samler en systemindstilling op.

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

Hvis den gamle værdi vender tilbage efter en genstart, er kilden en administreret politik eller en profil, der anvender den igen, og ejeren af den politik skal fjerne undtagelsen. Lad certifikatvalideringen være slået til hele vejen, fordi en proxy, der opfanger trafik, ellers vil se løst ud, når du slår kontrollerne fra. Afslut med at skrive den fjernede værdi og datoen i dine noter, så den næste person kan skelne en bevidst proxy fra en glemt.