VPN o proxy: ano ang sinasaklaw ng bawat isa at ano ang hindi
Sinasaklaw ng VPN ang niruruta na trapiko ng apps; sinasaklaw ng proxy lamang ang app na iyong kino-configure. Suriin ang saklaw, encryption, DNS at pag-uugali kapag bumagsak bago pumili.
Parehong binabago ng VPN at ng forward proxy ang address na nakikita ng isang website, at doon nagtatapos ang karamihan ng paghahambing. Ang pagkakaibang nagtatakda ng iyong setup ay ang saklaw: ang forward proxy ay isang tagapamagitan na pinipili ng iyong app na gamitin, kaiba sa reverse proxy na nakatayo sa harap ng isang website, samantalang inililipat ng VPN ang lahat ng niruruta ng operating system papasok sa isang tunnel. Ang encryption, paghawak ng DNS at pag-uugali kapag bumagsak ay lahat nagmumula sa paghahati na iyon. Isagawa ang limang pagsusuring ito nang sunod-sunod, at ang unang mabibigo ang magsasabi sa iyo kung anong tool ang talagang kailangan mo.
Aling mga app ang sinasaklaw ng tagapamagitan?
Ang extension ng proxy sa browser ay nalalapat lamang sa profile ng browser na iyon. Ang mga mail client, package manager at pangalawang browser ay patuloy na gumagamit ng sarili nilang mga setting, at ang ilang app ay ganap na binabalewala ang mga variable ng proxy ng system. Sinasaklaw ng VPN ang ipinapadala ng routing table papasok sa tunnel, at maaaring ito ay lahat ng app o isang subset sa split tunnel depende sa mga ruta at patakaran ng client.
Subukan ang mga app na mahalaga sa halip na mag-generalize mula sa isang pag-load ng pahina. Ang curl https://ifconfig.me ay sumusunod sa mga variable ng proxy ng environment; ang isang desktop app ay maaaring hindi. Sa Windows, ang netsh winhttp show proxy ay nagpi-print ng WinHTTP proxy na ginagamit ng mga serbisyo, at iba itong setting kaysa sa browser.
Naka-encrypt ba ang hop, at saan nagtatapos ang TLS?
Ang protocol ng proxy ay isang tagpuan, hindi isang garantiya. Ang SOCKS5 ay nagpapasa ng TCP nang hindi ito ini-encrypt, at ang plain HTTP proxy ay nagdadala ng request line at mga header sa malinaw na teksto. Gumagamit ang HTTPS sa proxy ng CONNECT, kaya ang iyong TLS session ay nagtatapos pa rin sa destinasyon, hindi sa proxy. Inilalarawan ng gabay ng MDN tungkol sa mga proxy server at tunneling ang pagkakaibang iyon mula sa panig ng protocol.
Ini-encrypt ng VPN ang bahagi sa pagitan ng iyong device at ng endpoint nito. Sa kabila ng endpoint, parehong mga patakaran ang nalalapat tulad ng sa anumang ibang network, kaya ang tunnel lamang ay hindi nagpoprotekta sa isang app na nagpapadala ng credentials sa plain HTTP. Wala sa dalawang disenyo ang nagtatago ng naka-log in na account, cookie o fingerprint ng browser.
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
Ipinapakita ng detalyadong output kung ang curl ay nagpadala ng CONNECT sa port 443 o isang plain GET na may buong URL. Sa socks5h:// ang hostname ay ibinibigay sa proxy sa loob ng SOCKS5 request at pagkatapos ay ipinapasa nito ang TLS na hindi nito mabasa, kaya nakikita nito ang pangalan at bilang ng byte. Sa pamamagitan ng http:// proxy, ang isang https:// URL ay CONNECT, kaya nakikita rin ng proxy na iyon ang pangalan at volume ng destinasyon, ngunit hindi ang request o ang response body.
Aling resolver ang nakakakita ng pangalan?
Ang paglutas ng pangalan ay maaaring mangyari nang lokal bago umalis ang request, o malayo sa proxy. Sa curl, ang socks5h:// ay nagpapadala ng hostname sa proxy habang ang socks5:// ay nilulutas muna ito nang lokal. Nag-aalok ang mga setting ng proxy ng browser ng maihahambing na opsyon sa DNS, at ang mga PAC file ay maaaring mag-ruta ng iba't ibang host sa iba't ibang paraan.
Dalawang protocol ang maaaring lumampas sa isang proxy nang walang anumang maling configuration. Ang WebRTC ay nangongolekta ng mga kandidato sa pamamagitan ng STUN, at ang QUIC ay nagpapatakbo ng HTTP/3 sa UDP, na hindi madadala ng TCP proxy. Babalik ang browser sa TCP kung naka-block ang UDP 443, kaya ang pag-block ng UDP 443 sa firewall ng host (o sa router para sa buong network), at hindi isang flag ng browser, ang maaasahang paraan para mapanatili ang HTTP/3 sa landas ng proxy.
Suriin ang resolver mula sa pananaw ng destinasyon, hindi ng iyong laptop. Ang isang request na dumarating na may exit address ng proxy ngunit may lokal na nalutas na pangalan ay nagsasabi pa rin sa lokal na resolver kung aling mga site ang binibisita mo.
Ano ang nangyayari kapag bumagsak ang tagapamagitan?
Ang isang tahasang proxy ay bumagsak nang sarado: itigil ang proseso ng proxy at ang browser o app ay magbabalik ng error sa koneksyon sa halip na dumiretso. Ang mga setup ng PAC at WPAD ang mga bumagsak nang bukas - kung hindi makuha ang script, babalik ang client sa DIRECT at makikita muli ng site ang iyong tunay na address. Ang isang VPN ay maaaring bumagsak nang bukas o sarado depende sa client at kung aktibo ang isang kill switch o patakaran ng firewall.
Subukan ang kaso ng pagbagsak nang sinasadya: itigil ang serbisyo ng proxy at i-reload; kung makakuha ka ng error page sa halip na direktang pag-load, ituro ang URL ng PAC sa isang host na hindi maabot upang makita ang fallback. Kung naglo-load pa rin ang pahina sa iyong karaniwang ruta, walang proteksyong ibinibigay ang proxy laban sa sarili nitong pagkaantala, at iyon ay isang katangiang dapat mong malaman bago umasa dito.
Ang pagkakasunod-sunod ang nagtatakda kung ano ang nakikita ng site. Ang isang proxy na ang outgoing traffic ay dumadaan sa VPN ay nag-iiwan sa site na nakikita ang address ng endpoint ng VPN; ilagay ang proxy sa labas ng tunnel (VPN patungo sa proxy sa isang malayong host) at makikita ng site ang exit address ng proxy na iyon sa halip. Sa alinmang paraan, ang dalawang hop ay maaaring mag-log ng magkaibang bagay.
Limang pagsusuri, nang sunod-sunod
Ang checklist sa ibaba ay ang buong desisyon sa isang lugar. Nauuna ang saklaw dahil inaalis nito ang karamihan ng hindi pagtutugma: kung ang app na kailangang saklawin ay hindi gumagalang sa setting, walang anumang bagay sa listahan ang makakapagligtas dito.
| Check | Forward proxy | VPN |
|---|---|---|
| What is covered | The app or browser you configure | Traffic the OS routes into the tunnel, all or split |
| Encryption scope | Protocol-dependent; SOCKS5 alone encrypts nothing | Device to VPN endpoint |
| DNS path | Local or remote, depending on the setting | Normally inside the tunnel |
| Failure mode | Explicit config: connection error; PAC/WPAD: DIRECT fallback | Client policy: fail-open or kill switch |
| What the site sees | The proxy's exit address | The VPN endpoint's exit address |
Pagkatapos ay kumpirmahin ang resulta gamit ang app na nagdulot ng pagbabago. Mag-load ng pahina sa naka-configure na browser, kunin ang parehong pahina gamit ang curl, at ihambing ang address na iniuulat ng bawat isa. Kung hindi sila nagtutugma, may extension, patakaran ng PAC o override sa antas ng app na gumagana pa, at walang pagsasaayos ng tunnel ang makakapag-ayos nito.
Itala kung ano ang iyong kino-configure: aling mga app ang gumagamit ng proxy, kung lokal o malayo ang DNS, kung naka-block ang UDP, at ano ang pag-uugali kapag bumagsak. Ang maliit na imbentaryong iyon ang nagpapangyari sa susunod na paghahambing, dahil ang “nagbago ang IP” ay hindi kailanman nagsabi sa iyo kung alin sa limang pagsusuring ito ang pumasa.