VPN eller proxy: kva kvar av dei dekkjer, og kva dei ikkje dekkjer

Både ein VPN og ein forward-proxy endrar adressa ein nettstad ser, og der stoppar dei fleste samanlikningane. Skilnaden som avgjer oppsettet ditt, er dekninga: ein forward-proxy er eit mellomledd som applikasjonen din sjølv vel å bruke, i motsetnad til reverse-proxyen som står framom ein nettstad, medan ein VPN flyttar alt operativsystemet ruter inn i ein tunnel. Kryptering, DNS-handtering og oppførsel ved feil følgjer alle av denne delinga. Køyr desse fem sjekkane i rekkjefølgje, og den første som feilar fortel deg kva verktøy du faktisk treng.

Kva appar dekkjer mellomleddet?

Ei nettlesar-proxyutviding gjeld berre for den nettlesarprofilen. E-postklientar, pakkehandsamarar og ein annan nettlesar held fram med eigne innstillingar, og nokre applikasjonar ignorerer proxyvariablane til systemet heilt. Ein VPN dekkjer det rutetabellen sender inn i tunnelen, og det kan vere alle applikasjonar eller eit delsett ved split-tunnel avhengig av ruter og klientpolitikk.

Test applikasjonane som betyr noko i staden for å generalisere frå éi sideinnlasting. curl https://ifconfig.me følgjer proxyvariablane i miljøet; ein skrivebordsapp gjer det kanskje ikkje. På Windows skriv netsh winhttp show proxy ut WinHTTP-proxyen som tenester brukar, og det er ei anna innstilling enn nettlesaren si.

Er hoppet kryptert, og kvar sluttar TLS?

Ein proxyprotokoll er ein møtestad, ikkje ei garanti. SOCKS5 sender TCP vidare utan å kryptere det, og ein vanleg HTTP-proxy transporterer førespurnadslinja og hovuda i klartekst. HTTPS gjennom ein proxy brukar CONNECT, så TLS-økta di sluttar framleis ved målet og ikkje ved proxyen. MDN-veiledninga om proxyservarar og tunnellering skildrar denne skilnaden frå protokollsida.

Ein VPN krypterer strekninga mellom eininga di og endepunktet hennar. Utanfor endepunktet gjeld dei same reglane som på eitkvart anna nettverk, og difor vernar ein tunnel åleine ikkje ein applikasjon som sender påloggingsinformasjon over vanleg HTTP. Ingen av dei to designa skjuler ein innlogga konto, ein cookie eller eit nettlesaravtrykk.

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

Den detaljerte utdataen viser om curl sende CONNECT til port 443 eller ein vanleg GET med full URL. Med socks5h:// får proxyen vertsnamnet inne i SOCKS5-førespurnaden og sender deretter vidare TLS som han ikkje kan lese, så han ser namnet og talet på byte. Gjennom ein http://-proxy er ein https://-URL ein CONNECT, så den proxyen ser også namnet og volumet til målet, men ikkje førespurnaden eller svarinnhaldet.

Kva resolver ser namnet?

Namneoppslag kan skje lokalt før førespurnaden forlèt maskina, eller eksternt hos proxyen. Med curl sender socks5h:// vertsnamnet til proxyen, medan socks5:// først løyser det lokalt. Proxyinnstillingane i nettlesaren tilbyr eit samanliknbart DNS-alternativ, og PAC-filer kan rute ulike vertar på ulike måtar.

To protokollar kan omgå ein proxy utan nokon feilkonfigurasjon. WebRTC samlar kandidatar via STUN, og QUIC køyrer HTTP/3 over UDP, som ein TCP-proxy ikkje kan transportere. Nettlesaren fell tilbake til TCP om UDP 443 er blokkert, så å blokkere UDP 443 i brannmuren til verten (eller på rutaren for eit heilt nettverk), og ikkje eit nettlesarflagg, er den pålitelege måten å halde HTTP/3 på proxyvegen.

Sjekk resolveren frå perspektivet til målet, ikkje frå laptoppen din. Ein førespurnad som kjem med utgangsadressa til proxyen, men med eit lokalt løyst namn, fortel framleis den lokale resolveren kva nettstader du besøkjer.

Kva skjer når mellomleddet sviktar?

Ein eksplisitt proxy sviktar lukka: stopp proxyprosessen, og nettlesaren eller appen returnerer ein tilkoplingsfeil i staden for å gå direkte. PAC- og WPAD-oppsett er dei som sviktar ope - om skriptet ikkje kan hentast, fell klienten tilbake til DIRECT, og nettstaden ser den verkelege adressa di igjen. Ein VPN kan svikte ope eller lukka avhengig av klienten og om ein kill switch eller brannmurregel er aktiv.

Test feiltilfellet med vilje: stopp proxydenesta og last inn på nytt; får du ei feilside i staden for ei direkte innlasting, peik PAC-URL-en mot ein utilgjengeleg vert for å sjå fallbacken. Om sida framleis blir lasta inn via den vanlege ruta di, tilbyr proxyen inga vern mot sin eigen driftsstans, og det er ein eigenskap du bør kjenne før du stolar på han.

Rekkjefølgja avgjer kva nettstaden ser. Ein proxy der den utgåande trafikken går gjennom VPN-en, lèt nettstaden sjå adressa til VPN-endepunktet; set du proxyen utanfor tunnelen (VPN til ein proxy på ein ekstern vert), ser nettstaden i staden utgangsadressa til den proxyen. Uansett kan dei to hoppa logge ulike ting.

Fem sjekkar, i rekkjefølgje

Sjekklista nedanfor er heile avgjerda på ein stad. Dekninga kjem først fordi ho fjernar dei fleste avvika: om appen som skal dekkjast ikkje respekterer innstillinga, reddar ingenting lenger ned på lista han.

Stadfest deretter resultatet med appen som utløyste endringa. Last ei side i den konfigurerte nettlesaren, hent den same sida med curl, og samanlikn adressa kvar av dei rapporterer. Om dei er usamde, er ei utviding, ein PAC-regel eller ei overstyring på appnivå framleis i spel, og inga mengd tunneltilpassing vil rette det.

Noter kva du konfigurerte: kva appar som brukar proxyen, om DNS er lokalt eller eksternt, om UDP er blokkert, og kva oppførselen ved feil er. Nettopp denne vesle oversikta gjer den neste samanlikninga mogleg, fordi «IP-en endra seg» aldri fortalde deg kven av desse fem sjekkane som vart bestått.