VPN of proxy: wat elk fan beide dekt en wat net

Sawol in VPN as in foarútproxy feroarje it adres dat in webside sjocht, en dêr stopje de measte fergelikingen. It ferskil dat jo ynstelling beslissend is, is dekking: in foarútproxy is in tuskenpersoan dy't jo applikaasje sels brûke wol, oars as de omkearde proxy foar in webside, wylst in VPN alles ferpleatst wat it bestjoeringssysteem nei in tunnel rûtelet. Fersifering, DNS-behanneling en flatergedrach folgje allegear út dy splitsing. Fier dizze fiif kontrôles op folchoarder út, en de earste dy't mislearret fertelt jo hokker ark jo echt nedich hawwe.

Hokker applikaasjes dekt de tuskenpersoan?

In browser-proxy-útwreiding jildt allinnich foar dat browserprofyl. E-postprogramma's, pakketbehearders en in twadde browser geane troch mei har eigen ynstellingen, en guon applikaasjes negearje de systeemproxyferariabelen hielendal. In VPN dekt wat de rûtetabel de tunnel yn stjoert, en dat kinne alle applikaasjes wêze of in dielset by in splitst tunnel, ôfhinklik fan rûtes en kliïntbelied.

Test de applikaasjes dy't der ta dogge ynstee fan te generalisearjen út ien sidebelading. curl https://ifconfig.me folget de proxyferariabelen fan 'e omjouwing; in desktopapp miskien net. Op Windows prints netsh winhttp show proxy de WinHTTP-proxy dy't tsjinsten brûke, en dat is in oare ynstelling as dy fan 'e browser.

Is de hop fersifere, en wêr einiget TLS?

In proxyprotokol is in moetsplak, gjin garânsje. SOCKS5 stjoert TCP troch sûnder it te fersiferjen, en in gewoane HTTP-proxy ferfiert de oanfraachrigel en kopteksten yn iepen tekst. HTTPS fia in proxy brûkt CONNECT, dat jo TLS-sesje einiget noch altyd by de bestimming, net by de proxy. De MDN-gids oer proxyservers en tunneljen beskriuwt dat ûnderskie fan 'e protokolside.

In VPN fersiferet it stik tusken jo apparaat en syn einpunt. Foarby it einpunt jilde deselde regels as op elk oar netwurk, en dêrom beskermet in tunnel allinnich gjin applikaasje dy't oanmeldgegevens oer gewoane HTTP stjoert. Gjin fan beide ûntwerpen ferberget in oanmeld account, in cookie of in browser-fingerprint.

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

De wiidweidige útfier lit sjen oft curl CONNECT nei poarte 443 stjoerd hat of in gewoane GET mei in folsleine URL. Mei socks5h:// kriget de proxy de hostnamme yn 'e SOCKS5-oanfraach en ferfiert dan TLS dat er net lêze kin, dus hy sjocht de namme en it bytetale. Fia in http://-proxy is in https://-URL in CONNECT, dus dy proxy sjocht ek de namme en it folume fan 'e bestimming, mar net de oanfraach of de antwirdtekst.

Hokker resolver sjocht de namme?

Nammerêding kin lokaal plakfine foardat de oanfraach fuortgiet, of op ôfstân by de proxy. Mei curl stjoert socks5h:// de hostnamme nei de proxy, wylst socks5:// dy earst lokaal oplost. Browser-proxyynstellingen biede in fergelykbere DNS-opsje, en PAC-bestannen kinne ferskate hosts ferskillend rûtele.

Twa protokollen kinne in proxy omgean sûnder ien ferkearde ynstelling. WebRTC sammelt kandidaten fia STUN, en QUIC rint HTTP/3 oer UDP, dat in TCP-proxy net ferfiere kin. In browser falt werom op TCP as UDP 443 blokkearre is, dus it blokkearjen fan UDP 443 yn 'e firewall fan 'e host (of op 'e router foar in hiel netwurk), net in browserflagge, is de betroubere manier om HTTP/3 yn it proxyplak te hâlden.

Kontrolearje de resolver fanút it perspektyf fan 'e bestimming, net fan jo laptop. In oanfraach dy't oankomt mei it útgongsadres fan 'e proxy mar mei in lokaal oploste namme fertelt de lokale resolver noch hieltiten hokker siden jo besykje.

Wat bart der as de tuskenpersoan mist?

In eksplisite proxy mist sletten: stop it proxyproses en de browser of app jout in ferbiningsflater ynstee fan direkt te gean. PAC- en WPAD-ynstellingen binne dejingen dy't iepen misse - as it skript net ophelle wurde kin, falt de kliïnt werom op DIRECT en sjocht de side wer jo echte adres. In VPN kin iepen of sletten misse, ôfhinklik fan 'e kliïnt en oft in kill switch of firewallregel aktyf is.

Test it flatergefal mei opsetsin: stop de proxystsjinst en laad opnij; krije jo in flaterside ynstee fan in direkte belading, rjochtsje dan de PAC-URL op in ûnberikbere host om de weromfal te sjen. As de side noch altyd fia jo gewoane rûte laadt, biedt de proxy gjin beskerming tsjin syn eigen steuring, en dat is in eigenskip dy't jo kenne moatte foardat jo dêrop fertrouwe.

De folchoarder beslissend wat de side sjocht. In proxy wêrfan it útgeande ferkear fia de VPN giet, lit de side it adres fan it VPN-einpunt sjen; pleats de proxy bûten de tunnel (VPN nei in proxy op in fiere host) en de side sjocht ynstee it útgongsadres fan dy proxy. Yn beide gefallen kinne de twa hops ferskillende dingen logge.

Fiif kontrôles, op folchoarder

De checklist hjirûnder is de hiele beslissing op ien plak. Dekking komt earst omdat it de measte mismatches fuorthellet: as de app dy't dekt wurde moat de ynstelling net respektearret, rêdt neat letter yn 'e list it.

Befêstigje dan it resultaat mei de app dy't de feroaring feroarsake hat. Laad in side yn 'e ynstelde browser, helje deselde side mei curl, en fergelykje it adres dat elk rapportearret. As se ferskille, is in útwreiding, in PAC-regel of in oerskriuwing op appnivo noch yn it spul, en gjin einige tunnelôfstelling sil dat oplosse.

Skriuw op wat jo ynsteld hawwe: hokker apps de proxy brûke, oft DNS lokaal of op ôfstân is, oft UDP blokkearre is, en wat it flatergedrach is. Krekt dy lytse ynventarisaasje makket de folgjende fergeliking mooglik, want “it IP is feroare” hat jo nea ferteld hokker fan dizze fiif kontrôles slagge.