VPN funksionon, por një aplikacion nuk ka internet? Kontrollo proxy-n e tij

Tuneli yt është ngritur, faqja e statusit tregon një handshake të shëndetshëm, por një aplikacion ende nuk ngarkon asgjë. Ai aplikacion ndoshta vazhdon t'i dërgojë kërkesat një ndërmjetësi më të vjetër: një proxy sistemi, një shtesë, një skedar konfigurimi i shtyrë nga menaxhimi i pajisjeve, ose një variabël proxy që lexohet vetëm nga procesi i tij. Ndryshimi i serverit VPN nuk do ta prekë atë cilësim, dhe kjo shpjegon modelin ku aplikacionet e tjera punojnë nga i njëjti kompjuter. Punoni nga aplikacioni që dështon nga jashtë, dhe lëreni tunelin në paqe derisa çështja e proxy-t të zgjidhet.

Cila shtresë zotëron cilësimin e proxy-t

Katër vende mund të kërkojnë autoritet mbi kërkesat e një aplikacioni, dhe zakonisht fiton më i ngushti. Sistemi operativ mban një proxy global dhe një URL opsionale të konfigurimit automatik; një shfletues mund ta ndjekë, ta anashkalojë ose t'ia dorëzojë kontrollin një shtese; një mjet rreshti komandash lexon mjedisin e vet; dhe një politikë e menaxhuar mund të fiksojë përsëri cilindo nga sa më sipër pas një ndryshimi. Vendosni cila shtresë është përgjegjëse përpara se të modifikoni diçka, sepse fshirja e shtresës së gabuar duket si një rregullim i suksesshëm që kthehet në hyrjen tjetër.

Krahaso dy aplikacione në të njëjtën faqe normale interneti, jo në një faqe prove vetëm për VPN. Nëse shfletuesi dështon ndërsa shkarkimi në terminal ka sukses, sistemi operativ nuk është problemi, dhe ndryshimi qëndron në profilin e shfletuesit ose shtesat e tij. Nëse të dy dështojnë, por një llogari e dytë përdoruesi në të njëjtin kompjuter ka sukses, cilësimi është për përdorues. Ai krahasim kushton një minutë dhe heq shumicën e hamendjes.

Lexo vlerën që çdo mjet përdor në të vërtetë

Printo konfigurimin përpara se ta ndryshosh, dhe kopjo vargun e saktë të proxy-t diku nga mund ta rikthesh. Variablat e shell-it janë kontrolli më i shpejtë për mjetet e rreshtit të komandave, sepse një klient VPN zakonisht i lë të paprekura.

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

Ekzekuto vetëm rreshtin që përputhet me platformën përpara teje, pastaj lexo daljen për hostin, portin dhe kredencialet. Një vlerë si http://proxy.corp.example:8080 do të thotë që mjeti pyet atë host për çdo kërkesë, ndërsa një rezultat bosh do të thotë që shkon direkt dhe defekti i vërtetë është diku tjetër. Mbulojeni pjesën e përdoruesit dhe fjalëkalimit përpara se të ngjitni daljen në një biletë, sepse ato vargje janë kredenciale të gjalla shumë më shpesh nga sa mendojnë njerëzit.

Mjetet me motorin e tyre të proxy-t kanë nevojë për provat e tyre. Curl njofton vendimin që mori kur rrit fjalosjen, gjë që është më mirë se sa të hamendësosh nga mjedisi, dhe i njëjti flamur tregon nëse zgjidhja e emrave ndodhi lokalisht ose në proxy.

Fshi anashkalimin dhe ritesto të njëjtën kërkesë

Ndrysho një shtresë, pastaj përsërit saktësisht kërkesën që dështoi, sepse një URL tjetër nuk provon asgjë. Fillimisht fshi variablat e mjedisit në shell-in aktual, pasi ai ndryshim është i kthyeshëm dhe nuk mund të thyejë tunelin:

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

Nëse dalja e detajuar ende pohon se ka proxy, mjedisi nuk ishte autoriteti. Ngjitu një nivel më lart në vend që të grumbullosh më shumë anashkalime.

Në macOS, kontrollo që një skedar konfigurimi automatik nuk e furnizon vlerën, pastaj fik proxy-n e shërbimit dhe konfirmo ndryshimin. Në Windows, mba mend se cilësimi WinHTTP dhe cilësimi i shfletuesit për përdorues janë objekte të ndryshme, kështu që një mjet i pastër i rreshtit të komandave mund të bashkëjetojë me një shfletues që ende tregon një server të vjetër. Shtesat meritojnë të njëjtin dyshim: një shtesë proxy mund t'i rishkruajë kërkesat vetëm për një profil, dhe kjo është saktësisht forma e një defekti që prek një shfletues dhe asgjë tjetër.

Verifiko që rregullimi i mbijeton një rindezjeje

Një cilësim që funksionon vetëm në terminalin që modifikove nuk është rregulluar. Rihap aplikacionin nga lëshuesi i desktopit, dil dhe hyr përsëri, dhe vëzhgo nëse proxy i vjetër kthehet.

Dy kontrolle ndajnë një rregullim të vërtetë nga një i përkohshëm, dhe të dyja duhet të raportojnë një lidhje të drejtpërdrejtë ose vlerën e synuar. Ekzekutimi në një mjedis të pastër tregon nëse një proces i pastruar ende merr një cilësim sistemi.

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

Nëse vlera e vjetër kthehet pas një rindezjeje, burimi është një politikë e menaxhuar ose një profil që e zbaton përsëri, dhe pronari i asaj politike duhet ta heqë përjashtimin. Lëre verifikimin e certifikatave të aktivizuar gjatë gjithë kohës, sepse një proxy që përgjon trafikun do të duket i zgjidhur sapo t'i çaktivizosh kontrollet. Përfundo duke shkruar vlerën e hequr dhe datën në shënimet e tua, që personi tjetër të mund të dallojë një proxy të qëllimshëm nga një i harruar.