VPN edo proxy: zer estaltzen duen bakoitzak eta zer ez

VPN batek eta proxy aurreratuak biak aldatzen dute webgune batek ikusten duen helbidea, eta hor amaitzen dira konparazio gehienak. Zure konfigurazioa erabakitzen duen aldea estaldura da: proxy aurreratua zure aplikazioak erabiltzea aukeratzen duen bitartekaria da, webgune baten aurrean dagoen proxy alderantzizkoaren aldean, eta VPNak sistema eragileak tunel batera bideratzen duen guztia mugitzen du. Zifratzea, DNSaren kudeaketa eta hutsegite-jokabidea banaketa horretatik datoz. Exekutatu bost egiaztapen hauek hurrenez hurren, eta huts egiten duen lehenak esango dizu zein tresna behar duzun benetan.

Zein aplikazio estaltzen ditu bitartekariak?

Arakatzaileko proxy hedapen bat profil horretarako soilik da baliagarria. Posta-bezeroek, pakete-kudeatzaileek eta bigarren arakatzaile batek beren ezarpenekin jarraitzen dute, eta zenbait aplikaziok sistema-mailako proxy aldagaiak erabat alde batera uzten dituzte. VPNak bideratze-taulak tunelera bidaltzen duena estaltzen du, eta hori aplikazio guztiak edo tunel zatitu bateko azpimultzo bat izan daiteke, ibilbideen eta bezeroaren politikaren arabera.

Probatu garrantzia duten aplikazioak, orri-karga batetik orokortu beharrean. curl https://ifconfig.me ingurunearen proxy aldagaiei jarraitzen die; mahaigaineko aplikazio batek agian ez. Windowsen, netsh winhttp show proxy zerbitzuek erabiltzen duten WinHTTP proxya bistaratzen du, eta hori arakatzailearen ezarpen ezberdina da.

Zifratuta dago jauzia, eta non amaitzen da TLS?

Proxy protokoloa topagune bat da, ez bermea. SOCKS5ek TCP birbidaltzen du zifratu gabe, eta HTTP proxy arruntak eskaera-lerroa eta goiburuak testu garbian garraiatzen ditu. Proxy baten bidezko HTTPSek CONNECT erabiltzen du, beraz zure TLS saioa helmugan amaitzen da oraindik, ez proxyean. MDNren proxy zerbitzari eta tunelatze gidak protokoloaren aldetik deskribatzen du bereizketa hori.

VPNak zure gailuaren eta haren amaiera-puntuaren arteko segmentua zifratzen du. Amaiera-puntuaz haratago beste edozein saretan bezalako arauak aplikatzen dira, eta horregatik tunel batek bakarrik ez du babesten HTTP arruntez kredentzialak bidaltzen dituen aplikazio bat. Bi diseinuek ez dute ezkutatzen saioa hasitako konturik, cookierik edo arakatzailearen hatz-markarik.

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

Irteera zehatzak erakusten du curl-ek CONNECT bidali duen 443 portura edo GET arrunta URL osoarekin. socks5h:// erabiliz, ostalari-izena SOCKS5 eskaeraren barruan ematen zaio proxyari, eta hark ezin duen TLSa birbidaltzen du, beraz izena eta byte-kopurua ikusten ditu. http:// proxy baten bidez, https:// URL bat CONNECT da, beraz proxy horrek ere helmugaren izena eta bolumena ikusten ditu, baina ez eskaera edo erantzunaren gorputza.

Zein ebazlek ikusten du izena?

Izenen ebazpena lokalki gerta daiteke eskaera irten aurretik, edo urrunetik proxyean. Curl-ekin, socks5h:// ostalari-izena proxyari bidaltzen dio, eta socks5:// lehenengo lokalki ebazten du. Arakatzailearen proxy ezarpenek DNS aukera konparagarria eskaintzen dute, eta PAC fitxategiek ostalari ezberdinak modu ezberdinetan bidera ditzakete.

Bi protokoloek proxy bat saihets dezakete konfigurazio-akatsik gabe. WebRTCk STUN bidez biltzen ditu hautagaiak, eta QUICek HTTP/3 UDP gainean exekutatzen du, eta TCP proxy batek ezin du hori garraiatu. Arakatzailea TCPra itzuliko da UDP 443 blokeatuta badago, beraz UDP 443 ostatuko suebakian (edo routerrean sare oso baterako) blokeatzea, eta ez arakatzailearen bandera bat, da HTTP/3 proxyaren bidean mantentzeko modu fidagarria.

Egiaztatu ebazlea helmugaren ikuspegitik, ez zure eramangarriaren ikuspegitik. Proxyaren irteera-helbidea baina izen lokalki ebatzita dituen eskaera batek oraindik esaten dio tokiko ebazleari zein gune bisitatzen dituzun.

Zer gertatzen da bitartekariak huts egiten duenean?

Proxy esplizituak itxita huts egiten du: gelditu proxy prozesua eta arakatzaileak edo aplikazioak konexio-errore bat itzuliko du zuzenean joan beharrean. PAC eta WPAD konfigurazioak dira irekita huts egiten dutenak - scripta eskuratu ezin bada, bezeroa DIRECTera itzultzen da eta guneak zure benetako helbidea ikusten du berriro. VPNak irekita edo itxita huts egin dezake bezeroaren eta kill switch edo suebaki-arau bat aktibo dagoen ala ez arabera.

Probatu hutsegite-kasua nahita: gelditu proxy zerbitzua eta berriz kargatu; karga zuzenaren ordez errore-orri bat jasotzen baduzu, seinalatu PAC URLa iristezin den ostalari batera atzera-jausia ikusteko. Orria zure ohiko bideaz kargatzen bada oraindik, proxyak ez du babesik eskaintzen bere etenaren aurka, eta hori jakin beharreko ezaugarria da harengan fidatu aurretik.

Ordenak erabakitzen du guneak zer ikusten duen. Irteerako trafikoa VPN bidez doan proxy batek guneak VPNaren amaiera-puntuaren helbidea ikus dezan uzten du; jarri proxya tunelaren kanpoan (VPN urruneko ostalari bateko proxy batera) eta guneak proxy horren irteera-helbidea ikusiko du horren ordez. Edonola ere, bi jauziek gauza ezberdinak erregistra ditzakete.

Bost egiaztapen, hurrenez hurren

Beheko zerrenda egiaztatzea da erabaki osoa leku bakarrean. Estaldura dator lehenengo, desegokitasun gehienak kentzen dituelako: estali behar den aplikazioak ezarpena errespetatzen ez badu, zerrendan geroago datorren ezerk ez du salbatzen.

Ondoren berretsi emaitza aldaketa eragin zuen aplikazioarekin. Kargatu orri bat konfiguratutako arakatzailean, eskuratu orri bera curl-ekin, eta alderatu bakoitzak ematen duen helbidea. Ados ez badaude, hedapen bat, PAC arau bat edo aplikazio-mailako gainidazketa bat dago oraindik martxan, eta tunelaren doikuntza orok ez du konponduko.

Idatz ezazu zer konfiguratu duzun: zein aplikaziok erabiltzen duten proxya, DNSa lokala ala urrutikoa den, UDP blokeatuta dagoen eta hutsegite-jokabidea zein den. Inbentario txiki horrek egiten du posible hurrengo konparazioa, izan ere «IPa aldatu da» esaldiak ez zizun inoiz esan zein bost egiaztapen hauetatik pasa zen.