VPN teenoor proxy: wat elkeen dek en wat nie

'n VPN en 'n vorentoe-proxy verander albei die adres wat 'n webwerf sien, en dit is waar die meeste vergelykings ophou. Die verskil wat jou opstelling bepaal, is dekking: 'n vorentoe-proxy is 'n tussenganger wat jou toepassing self kies om te gebruik, anders as die omgekeerde proxy voor 'n webwerf, en 'n VPN stuur alles wat die bedryfstelsel in 'n tonnel roeteer. Enkripsie, DNS-hantering en foutgedrag volg almal uit daardie skeiding. Voer hierdie vyf kontroles in volgorde uit, en die eerste een wat misluk, wys watter gereedskap jy werklik nodig het.

Watter programme dek die tussenganger?

'n Blaaier-proxy-uitbreiding geld net vir daardie blaaierprofiel. E-posprogramme, pakketbestuurders en 'n tweede blaaier bly hul eie instellings gebruik, en sommige programme ignoreer stelsel-proxyveranderlikes heeltemal. 'n VPN dek wat die roetebepaling in die tonnel instuur, wat elke toepassing of 'n verdeelde tonnel kan wees, afhangend van roetes en kliëntbeleid.

Toets die programme wat saak maak eerder as om uit een bladsylaai af te lei. curl https://ifconfig.me volg omgewingsveranderlikes vir die proxy; 'n tafeltoepassing doen dit dalk nie. Op Windows druk netsh winhttp show proxy die WinHTTP-proxy uit wat dienste gebruik, en dit is 'n ander instelling as die blaaier s'n.

Is die sprong geënkripteer, en waar eindig TLS?

'n Proxy-protokol is 'n ontmoetingspunt, nie 'n waarborg nie. SOCKS5 stuur TCP aan sonder om dit te enkripteer, en 'n gewone HTTP-proxy dra die versoekreël en kopstukke in gewone teks. HTTPS deur 'n proxy gebruik CONNECT, so jou TLS-sessie eindig steeds by die bestemming en nie by die proxy nie. Die MDN-gids oor proxyservers en tonneling beskryf daardie onderskeid van die protokol se kant af.

'n VPN enkripteer die segment tussen jou toestel en sy eindpunt. Anderkant die eindpunt geld dieselfde reëls as op enige ander netwerk, en daarom beskerm 'n tonnel alleen nie 'n toepassing wat aanmeldgegewens oor gewone HTTP stuur nie. Nie een van die twee ontwerpe verberg 'n aangemelde rekening, 'n koekie of 'n blaaier-vingerafdruk nie.

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

Die breedsprakige uitvoer wys of curl CONNECT na poort 443 gestuur het of 'n gewone GET met 'n volledige URL. Met socks5h:// kry die proxy die gasheernaam binne die SOCKS5-versoek en stuur dan TLS deur wat hy nie kan lees nie, so hy sien die naam en die aantal grepe. Deur 'n http://-proxy is 'n https:// URL 'n CONNECT, so daardie proxy sien ook die bestemmingsnaam en -volume, nie die versoek of die antwoordliggaam nie.

Watter oplosser sien die naam?

Naamresolusie kan plaaslik gebeur voordat die versoek weg is, of op afstand by die proxy. Met curl stuur socks5h:// die gasheernaam na die proxy, terwyl socks5:// dit eers plaaslik oplos. Blaaier-proxyinstellings bied 'n vergelykbare DNS-opsie, en PAC-lêers kan verskillende gashere op verskillende maniere roeteer.

Twee protokolle kan 'n proxy omseil sonder enige verkeerde instelling. WebRTC versamel kandidate oor STUN, en QUIC laat HTTP/3 oor UDP loop, wat 'n TCP-proxy nie kan dra nie. 'n Blaaier val terug na TCP as UDP 443 geblokkeer is, so om UDP 443 op die gasheer se firewall (of op die router vir 'n hele netwerk) te blokkeer, en nie 'n blaaier-vlag nie, is die betroubare manier om HTTP/3 binne die proxy-roete te hou.

Kontroleer die oplosser vanuit die bestemming se perspektief, nie vanuit jou skootrekenaar s'n nie. 'n Versoek wat met die proxy se uitgangsadres aankom maar 'n plaaslik opgeloste naam het, vertel steeds vir die plaaslike oplosser watter werwe jy besoek.

Wat gebeur wanneer die tussenganger faal?

'n Eksplisiete proxy faal geslote: stop die proxyproses en die blaaier of toepassing gee 'n verbindingsfout in plaas daarvan om direk te gaan. PAC- en WPAD-opstellings is diegene wat oop faal - as die skrip nie opgehaal kan word nie, val die kliënt terug na DIRECT en die werf sien weer jou ware adres. 'n VPN kan oop of geslote faal, afhangend van die kliënt en of 'n noodskakelaar of firewall-reël aktief is.

Toets die foutgeval doelbewus: stop die proxydiens en herlaai; as jy 'n foutbladsy kry eerder as 'n direkte laai, wys die PAC-URL na 'n onbereikbare gasheer om die terugval te sien. As die bladsy steeds deur jou gewone roete laai, bied die proxy geen beskerming teen sy eie onderbreking nie, en dit is 'n eienskap wat jy moet ken voordat jy daarop staatmaak.

Orde bepaal wat die werf sien. 'n Proxy wie se uitgaande verkeer deur die VPN loop, laat die werf die VPN-eindpunt se adres sien; plaas die proxy buite die tonnel (VPN na 'n proxy op 'n afgeleë gasheer) en die werf sien eerder daardie proxy se uitgangsadres. In albei gevalle kan die twee spronge verskillende dinge log.

Vyf kontroles, in volgorde

Die kontrolelys hieronder is die hele besluit op een plek. Dekking kom eerste omdat dit die meeste wanpassings uitskakel: as die program wat gedek moet word nie die instelling respekteer nie, red niks later in die lys dit nie.

Bevestig dan die resultaat met die program wat die verandering veroorsaak het. Laai 'n bladsy in die ingestelde blaaier, haal dieselfde bladsy met curl, en vergelyk die adres wat elkeen rapporteer. As hulle verskil, is 'n uitbreiding, 'n PAC-reël of 'n toepassingvlak-oorheersing steeds in werking, en geen mate van tonnelverstelling sal dit regstel nie.

Teken aan wat jy ingestel het: watter programme die proxy gebruik, of DNS plaaslik of op afstand is, of UDP geblokkeer is, en wat die foutgedrag is. Daardie klein inventaris is wat die volgende vergelyking moontlik maak, want “die IP het verander” het jou nooit gesê watter van hierdie vyf kontroles geslaag het nie.