VPN apo proxy: çfarë mbulon secili dhe çfarë jo

Si një VPN ashtu edhe një proxy përpara ndryshojnë adresën që sheh një faqe web, dhe aty ndalen shumica e krahasimeve. Dallimi që përcakton konfigurimin tuaj është mbulimi: një proxy përpara është një ndërmjetës që aplikacioni juaj zgjedh ta përdorë vetë, ndryshe nga proxy i kundërt që qëndron përpara një faqeje web, ndërsa një VPN lëviz gjithçka që sistemi operativ rrugëzon në një tunel. Kriptimi, trajtimi i DNS-së dhe sjellja në dështim rrjedhin të gjitha nga kjo ndarje. Kryeni këto pesë kontrolle me radhë, dhe i pari që dështon do t'ju thotë se çfarë mjeti ju nevojitet në të vërtetë.

Cilat aplikacione mbulon ndërmjetësi?

Një shtojcë proxy në shfletues vlen vetëm për atë profil të shfletuesit. Klientët e postës, menaxherët e paketave dhe një shfletues i dytë vazhdojnë me cilësimet e tyre, dhe disa aplikacione i injorojnë plotësisht variablat e proxy-t të sistemit. Një VPN mbulon atë që tabela e rrugëzimit dërgon në tunel, dhe kjo mund të jenë të gjitha aplikacionet ose një nëngrup në një tunel të ndarë, në varësi të rrugëve dhe politikës së klientit.

Testoni aplikacionet që kanë rëndësi në vend që të përgjithësoni nga një ngarkim i vetëm faqeje. curl https://ifconfig.me ndjek variablat e proxy-t të mjedisit; një aplikacion desktop mund të mos i ndjekë. Në Windows, netsh winhttp show proxy shtyp proxy-n WinHTTP që përdorin shërbimet, dhe ky është një cilësim i ndryshëm nga ai i shfletuesit.

A është i kriptuar kërcimi, dhe ku përfundon TLS?

Një protokoll proxy është një vend takimi, jo një garanci. SOCKS5 e përcjell TCP-në pa e kriptuar, dhe një proxy HTTP i thjeshtë e transporton rreshtin e kërkesës dhe titujt në tekst të hapur. HTTPS përmes një proxy përdor CONNECT, kështu që sesioni juaj TLS përfundon përsëri në destinacion, jo në proxy. Udhëzuesi i MDN për serverat proxy dhe tunelizimin e përshkruan këtë dallim nga ana e protokollit.

Një VPN kripton segmentin midis pajisjes tuaj dhe pikës së saj fundore. Përtej pikës fundore zbatohen të njëjtat rregulla si në çdo rrjet tjetër, prandaj një tunel i vetëm nuk mbron një aplikacion që dërgon kredenciale përmes HTTP të thjeshtë. Asnjëra nga dy modelet nuk fsheh një llogari të identifikuar, një cookie ose një gjurmë gishti të shfletuesit.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

Dalja e detajuar tregon nëse curl ka dërguar CONNECT në portën 443 apo një GET të thjeshtë me një URL të plotë. Me socks5h:// emri i hostit i jepet proxy-t brenda kërkesës SOCKS5 dhe më pas ai përcjell TLS që nuk mund ta lexojë, pra sheh emrin dhe numrin e bajteve. Përmes një proxy http://, një URL https:// është CONNECT, kështu që edhe ai proxy sheh emrin dhe volumin e destinacionit, por jo kërkesën ose trupin e përgjigjes.

Cili zgjidhës e sheh emrin?

Zgjidhja e emrave mund të ndodhë lokalisht përpara se kërkesa të largohet, ose në distancë te proxy. Me curl, socks5h:// dërgon emrin e hostit te proxy ndërsa socks5:// e zgjidh fillimisht lokalisht. Cilësimet e proxy-t të shfletuesit ofrojnë një opsion DNS të krahasueshëm, dhe skedarët PAC mund të rrugëzojnë hoste të ndryshëm në mënyra të ndryshme.

Dy protokolle mund të anashkalojnë një proxy pa asnjë gabim konfigurimi. WebRTC mbledh kandidatë përmes STUN, dhe QUIC ekzekuton HTTP/3 mbi UDP, të cilin një proxy TCP nuk mund ta transportojë. Shfletuesi do të kthehet në TCP nëse UDP 443 është bllokuar, prandaj bllokimi i UDP 443 në murin e zjarrit të hostit (ose në ruter për një rrjet të tërë), dhe jo një flamur i shfletuesit, është mënyra e besueshme për ta mbajtur HTTP/3 në rrugën e proxy-t.

Kontrolloni zgjidhësin nga këndvështrimi i destinacionit, jo i laptopit tuaj. Një kërkesë që mbërrin me adresën e daljes së proxy-t por me një emër të zgjidhur lokalisht përsëri i thotë zgjidhësit lokal se cilat sajte vizitoni.

Çfarë ndodh kur ndërmjetësi dështon?

Një proxy i qartë dështon i mbyllur: ndaloni procesin e proxy-t dhe shfletuesi ose aplikacioni kthen një gabim lidhjeje në vend që të shkojë direkt. Konfigurimet PAC dhe WPAD janë ato që dështojnë hapur - nëse skenari nuk mund të merret, klienti kthehet në DIRECT dhe faqja e sheh përsëri adresën tuaj reale. Një VPN mund të dështojë hapur ose mbyllur në varësi të klientit dhe nëse një ndërprerës ose rregull i murit të zjarrit është aktiv.

Testoni rastin e dështimit qëllimisht: ndaloni shërbimin e proxy-t dhe ringarkoni; nëse merrni një faqe gabimi në vend të një ngarkimi direkt, drejtojeni URL-në e PAC te një host i paarritshëm për të parë rrugën alternative. Nëse faqja ngarkohet përsëri përmes rrugës tuaj të zakonshme, proxy nuk ofron asnjë mbrojtje ndaj ndërprerjes së vet, dhe kjo është një veti që duhet ta dini përpara se të mbështeteni tek ai.

Rendi vendos se çfarë sheh faqja. Një proxy, trafiku dalës i të cilit kalon përmes VPN-së, e lë faqen të shohë adresën e pikës fundore të VPN-së; vendosni proxy-n jashtë tunelit (VPN te një proxy në një host të largët) dhe faqja do të shohë në vend të kësaj adresën e daljes së atij proxy. Në të dyja rastet, dy kërcimet mund të regjistrojnë gjëra të ndryshme.

Pesë kontrolle, me radhë

Lista e kontrollit më poshtë është i gjithë vendimi në një vend. Mbulimi vjen i pari sepse eliminon shumicën e mospërputhjeve: nëse aplikacioni që duhet mbuluar nuk e respekton cilësimin, asgjë më tej në listë nuk e shpëton.

Më pas konfirmoni rezultatin me aplikacionin që shkaktoi ndryshimin. Ngarkoni një faqe në shfletuesin e konfiguruar, merrni të njëjtën faqe me curl dhe krahasoni adresën që raporton secili. Nëse nuk përputhen, një shtojcë, një rregull PAC ose një anashkalim në nivel aplikacioni është ende në lojë, dhe asnjë rregullim i tunelit nuk do ta rregullojë.

Shënoni çfarë konfiguruat: cilat aplikacione përdorin proxy-n, nëse DNS është lokal ose në distancë, nëse UDP është bllokuar dhe cila është sjellja në dështim. Ky inventar i vogël është ai që e bën të mundur krahasimin e radhës, sepse «IP-ja ndryshoi» nuk ju tha kurrë se cila nga këto pesë kontrolle kaloi.