Gumagana ang VPN, pero isang app ang walang internet? Suriin ang proxy nito

Nakaup na ang tunnel mo, ipinapakita ng status page ang malusog na handshake, pero isang application ang hindi pa rin naglo-load ng kahit ano. Malamang ipinapadala pa rin ng application na iyon ang mga kahilingan nito sa mas lumang tagapamagitan: isang system proxy, isang extension, isang configuration file na itinutulak ng pamamahala ng device, o isang proxy variable na ang sariling proseso lang ang nagbabasa. Hindi gagalawin ng pagpalit ng VPN server ang setting na iyon, at iyon ang nagpapaliwanag sa pattern kung saan gumagana ang ibang apps mula sa parehong makina. Magtrabaho mula sa app na nabibigo pakanluran, at iwanan ang tunnel hanggang matapos ang tanong tungkol sa proxy.

Aling layer ang may-ari ng proxy setting

Apat na lugar ang maaaring mag-angkin ng awtoridad sa mga kahilingan ng isang app, at kadalasan ang pinakamakitid ang nananalo. Ang operating system ay may global proxy at opsyonal na automatic configuration URL; maaaring sundin ito ng browser, i-override ito, o ibigay ang kontrol sa isang extension; ang command-line tool ay nagbabasa ng sarili nitong kapaligiran; at ang pinamamahalaang patakaran ay maaaring muling i-pin ang alinman sa mga nasa itaas pagkatapos ng pagbabago. Magpasya kung aling layer ang responsable bago mag-edit ng kahit ano, dahil ang paglilinis ng maling layer ay mukhang matagumpay na pag-aayos na bumabalik sa susunod na pag-login.

Ihambing ang dalawang application sa parehong ordinaryong website, hindi sa test page na para lang sa VPN. Kung nabibigo ang browser habang tagumpay ang download sa terminal, hindi ang operating system ang problema, at nasa loob ng browser profile o ng mga extension nito ang pagkakaiba. Kung parehong nabibigo pero tagumpay ang pangalawang user account sa parehong makina, per user ang setting. Ang paghahambing na iyon ay tumatagal ng isang minuto at tinatanggal ang karamihan ng hula.

Basahin ang value na aktwal na ginagamit ng bawat tool

I-print ang configuration bago ito baguhin, at kopyahin ang eksaktong proxy string sa lugar na maaari mong ibalik ito. Ang mga shell variable ang pinakamabilis na tsek para sa command-line tool, dahil karaniwang hindi ito ginagalaw ng VPN client.

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

Patakbuhin lang ang linyang tumutugma sa platform sa harap mo, pagkatapos basahin ang output para sa host, port at credentials. Ang value na tulad ng http://proxy.corp.example:8080 ay nangangahulugang tinatanong ng tool ang host na iyon sa bawat kahilingan, habang ang walang laman na resulta ay nangangahulugang dumadaan ito nang direkta at ang tunay na sira ay nasa ibang lugar. Itago ang bahagi ng user at password bago i-paste ang output sa isang ticket, dahil ang mga string na iyon ay mas madalas na buhay na credentials kaysa sa inaasahan ng mga tao.

Ang mga tool na may sariling proxy engine ay nangangailangan ng sariling ebidensya. Sinasabi ng Curl ang desisyong ginawa nito kapag pinataas mo ang verbosity, na mas mahusay kaysa sa paghula mula sa kapaligiran, at ang parehong flag ay nagpapakita kung lokal o sa proxy nangyari ang paglutas ng pangalan.

Burahin ang override at muling subukan ang parehong kahilingan

Baguhin ang isang layer, pagkatapos ulitin ang eksaktong kahilingan na nabigo, dahil walang pinatutunayan ang ibang URL. Burahin muna ang mga environment variable sa kasalukuyang shell, dahil nababalik ang pagbabagong iyon at hindi nito masisira ang tunnel:

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

Kung ang detalyadong output ay nag-aangkin pa rin ng proxy, hindi ang kapaligiran ang awtoridad. Umakyat ng isang antas sa halip na magpatong ng mas maraming override.

Sa macOS, tiyakin na walang awtomatikong configuration file na nagbibigay ng value, pagkatapos patayin ang service proxy at kumpirmahin ang pagbabago. Sa Windows, tandaan na ang WinHTTP setting at ang per-user browser setting ay magkaibang bagay, kaya ang malinis na command-line tool ay maaaring mabuhay kasama ng browser na nakaturo pa rin sa lumang server. Karapat-dapat din sa pagdududa ang mga extension: ang proxy extension ay maaaring magsulat muli ng mga kahilingan para sa isang profile lang, at iyon ang eksaktong hugis ng sira na tumatama sa isang browser at wala nang iba.

Kumpirmahin na nakakaligtas ang pag-aayos sa restart

Ang setting na gumagana lang sa terminal na inedit mo ay hindi pa naayos. Muling buksan ang app mula sa desktop launcher, mag-log out at mag-log in muli, at tingnan kung bumabalik ang lumang proxy.

Dalawang tsek ang naghihiwalay ng tunay na pag-aayos sa pansamantala, at pareho dapat mag-ulat ng direktang koneksyon o ang nilalayong value. Ang pagtakbo sa malinis na kapaligiran ay nagpapakita kung ang hinubarang proseso ay kumukuha pa rin ng system setting.

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

Kung bumalik ang lumang value pagkatapos ng restart, ang pinagmulan ay pinamamahalaang patakaran o profile na naglalapat muli nito, at ang may-ari ng patakarang iyon ay kailangang mag-alis ng exception. Iwanang naka-on ang verification ng certificate sa lahat ng oras, dahil ang proxy na humaharang sa traffic ay magmumukhang naayos sa sandaling patayin mo ang mga tsek. Tapusin sa pagsusulat ng tinanggal na value at petsa sa iyong mga tala, para makilala ng susunod na tao ang sinadyang proxy mula sa nakalimutan.