VPN werk, maar een app het geen internet? Kyk na sy proxy

Jou tonnel is op, die statusbladsy wys ’n gesonde handshake, en een toepassing laai steeds niks. Daardie toepassing stuur waarskynlik nog versoeke na ’n ouer tussenlaag: ’n stelselproxy, ’n uitbreiding, ’n konfigurasielêer wat deur toestelbestuur afgedwing word, of ’n proxyveranderlike wat net sy eie proses lees. Om die VPN-bediener te vervang beïnvloed nie daardie instelling nie, en dit verduidelik die patroon waar ander toepassings van dieselfde masjien af werk. Werk van die mislukkende toepassing af na buite, en los die tonnel alleen tot die proxyvraag besleg is.

Watter laag besit die proxyinstelling

Vier plekke kan gesag oor ’n toepassing se versoeke opeis, en die nouste een wen gewoonlik. Die bedryfstelsel hou ’n globale proxy en ’n opsionele outomatiese konfigurasie-URL; ’n blaaier kan dit volg, dit oorskryf of beheer aan ’n uitbreiding oorhandig; ’n opdragreëlhulpmiddel lees sy eie omgewing; en ’n bestuurde beleid kan enige van die bogenoemde ná ’n verandering weer vaspen. Besluit watter laag in beheer is voordat jy iets wysig, want om die verkeerde een skoon te maak lyk soos ’n suksesvolle regstelling wat by die volgende aanmelding terugkom.

Vergelyk twee toepassings teen dieselfde gewone webwerf eerder as teen ’n bladsy wat net vir VPN-toetsing bedoel is. As die blaaier misluk terwyl ’n terminaalaflaai slaag, is die bedryfstelsel nie die probleem nie, en die verskil sit in die blaaierprofiel of sy uitbreidings. As albei misluk maar ’n tweede gebruikerrekening op dieselfde masjien slaag, is die instelling per gebruiker. Daardie vergelyking kos ’n minuut en verwyder die meeste raaiwerk.

Lees die waarde wat elke hulpmiddel werklik gebruik

Druk die konfigurasie af voordat jy dit verander, en kopieer die presiese proxystring na ’n plek waar jy dit kan bêre en herstel. Die skulpveranderlikes is die vinnigste toets vir opdragreëlhulpmiddels, want ’n VPN-kliënt laat dit gewoonlik ongemoeid.

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

Voer net die reël uit wat by die platform voor jou pas, en lees dan die uitset vir gasheer, poort en geloofsbriewe. ’n Waarde soos http://proxy.corp.example:8080 beteken dat die hulpmiddel daardie gasheer vir elke versoek vra, terwyl ’n leë resultaat beteken dat dit direk gaan en die werklike fout elders lê. Verberg die gebruikers- en wagwoorddeel voordat jy die uitset in ’n kaartjie plak, want daardie stringe is baie vaker lewendige geloofsbriewe as wat mense aanneem.

Hulpmiddels met hul eie proxymotor het hul eie bewyse nodig. Curl noem die besluit wat dit geneem het wanneer jy die breedsprakigheid verhoog, wat beter is as om uit die omgewing te raai, en dieselfde vlag wys of naamoplossing plaaslik of by die proxy gebeur het.

Maak die oorheersing skoon en toets dieselfde versoek weer

Verander een laag en herhaal dan presies die versoek wat misluk het, want ’n ander URL bewys niks. Maak eers die omgewingsveranderlikes in die huidige skulp skoon, want daardie wysiging is omkeerbaar en kan nie die tonnel breek nie:

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

As die breedsprakige uitset steeds ’n proxy beweer, was die omgewing nie die gesag nie. Beweeg een vlak op in plaas daarvan om meer oorheersings te stapel.

Kontroleer op macOS of ’n outomatiese konfigurasielêer nie die waarde lewer nie, en skakel dan die diensproxy af en bevestig die verandering. Onthou op Windows dat die WinHTTP-instelling en die blaaierinstelling per gebruiker verskillende objekte is, sodat ’n skoon opdragreëlhulpmiddel saam kan bestaan met ’n blaaier wat nog na ’n ou bediener wys. Uitbreidings verdien dieselfde agterdog: ’n proxy-uitbreiding kan versoeke net vir een profiel herskryf, en dit is presies die vorm van ’n fout wat een blaaier raak en niks anders nie.

Kontroleer dat die regstelling ’n herstart oorleef

’n Instelling wat net in die terminaal werk wat jy gewysig het, is nie reggestel nie. Open die toepassing weer vanaf die lessenaar se lanseerder, meld af en weer aan, en kyk of die ou proxy terugkeer.

Twee kontroles skei ’n regte regstelling van ’n tydelike een, en albei moet ’n direkte verbinding of die bedoelde waarde rapporteer. Die lopie in ’n skoon omgewing wys of ’n gestroopte proses steeds ’n stelselinstelling optel.

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

As die ou waarde ná ’n herstart terugkom, is die bron ’n bestuurde beleid of ’n profiel wat dit weer toepas, en die eienaar van daardie beleid moet die uitsondering verwyder. Laat sertifikaatverifikasie deurgaans aan, want ’n proxy wat verkeer onderskep sal andersins opgelos lyk sodra jy die kontroles deaktiveer. Sluit af deur die verwyderde waarde en die datum in jou notas te skryf, sodat die volgende persoon ’n doelbewuste proxy van ’n vergeetde een kan onderskei.