VPN kontraŭ prokura servilo: kion ĉiu kovras kaj kion ne

Kaj VPN kaj antaŭa prokura servilo ŝanĝas la adreson, kiun vidas retejo, kaj tie haltas la plej multaj komparoj. La diferenco, kiu decidas vian agordon, estas kovrado: antaŭa prokura servilo estas peranto, kiun via aplikaĵo mem elektas uzi, male al la malantaŭa prokura servilo, kiu staras antaŭ retejo, dum VPN movas ĉion, kion la operaciumo rutigas en tunelon. Ĉifrado, traktado de DNS kaj fiaskokonduto ĉiuj sekvas el tiu divido. Plenumu ĉi tiujn kvin kontrolojn laŭvice, kaj la unua, kiu malsukcesos, diros al vi, kiun ilon vi efektive bezonas.

Kiujn aplikaĵojn kovras la peranto?

Prokura etendaĵo en retumilo validas nur por tiu retumila profilo. Retpoŝtaj klientoj, pakaĵmastrumiloj kaj dua retumilo daŭre uzas siajn proprajn agordojn, kaj iuj aplikaĵoj tute ignoras la sistemajn prokurajn variablojn. VPN kovras tion, kion la rutiga tabelo sendas en la tunelon, kio povas esti ĉiuj aplikaĵoj aŭ subaro ĉe dividita tunelo depende de la itineroj kaj la klienta politiko.

Testu la aplikaĵojn, kiuj gravas, anstataŭ ĝeneraliĝi el unu paĝa ŝargo. curl https://ifconfig.me sekvas la prokurajn variablojn de la medio; labortabla aplikaĵo eble ne. En Windows, netsh winhttp show proxy presas la WinHTTP-prokuran servilon, kiun uzas servoj, kaj tio estas malsama agordo ol tiu de la retumilo.

Ĉu la salto estas ĉifrita, kaj kie finiĝas TLS?

Prokura protokolo estas renkontiĝejo, ne garantio. SOCKS5 plusendas TCP sen ĉifri ĝin, kaj ordinara HTTP-prokura servilo portas la petlinion kaj kapliniojn en klara teksto. HTTPS tra prokura servilo uzas CONNECT, do via TLS-sesio ankoraŭ finiĝas ĉe la celo, ne ĉe la prokura servilo. La MDN-gvidilo pri prokuraj serviloj kaj tunelado priskribas tiun distingon de la protokola flanko.

VPN ĉifras la segmenton inter via aparato kaj ĝia finpunkto. Preter la finpunkto validas la samaj reguloj kiel en iu ajn alia reto, kaj tial tunelo sola ne protektas aplikaĵon, kiu sendas legitimilojn per ordinara HTTP. Neniu el la du dezajnoj kaŝas ensalutitan konton, kuketon aŭ retumilan fingrospuron.

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

La detala eligo montras, ĉu curl sendis CONNECT al pordo 443 aŭ ordinaran GET kun plena URL. Kun socks5h:// la gastiga nomo transdoniĝas al la prokura servilo ene de la SOCKS5-peto, kaj ĝi poste plusendas TLS, kiun ĝi ne povas legi, do ĝi vidas la nomon kaj la bajtokalkulon. Tra http://-prokura servilo, https://-URL estas CONNECT, do ankaŭ tiu prokura servilo vidas la celan nomon kaj volumenon, sed ne la peton nek la respondan korpon.

Kiun solvilon vidas la nomon?

Nomresolvado povas okazi loke antaŭ ol la peto foriras, aŭ distance ĉe la prokura servilo. Kun curl, socks5h:// sendas la gastigan nomon al la prokura servilo, dum socks5:// unue solvas ĝin loke. La prokuraj agordoj de la retumilo proponas kompareblan DNS-opcion, kaj PAC-dosieroj povas rutigi malsamajn gastigantojn malsame.

Du protokoloj povas ĉirkaŭiri prokuran servilon sen ia ajn misagordo. WebRTC kolektas kandidatojn per STUN, kaj QUIC funkciigas HTTP/3 super UDP, kiun TCP-prokura servilo ne povas porti. Retumilo revenos al TCP, se UDP 443 estas blokita, do bloki UDP 443 en la fajroŝirmilo de la gastiganto (aŭ en la enkursigilo por tuta reto), ne retumila flago, estas la fidinda maniero teni HTTP/3 ene de la prokura vojo.

Kontrolu la solvilon el la perspektivo de la celo, ne de via tekkomputilo. Peto, kiu alvenas kun la elira adreso de la prokura servilo sed kun loke solvita nomo, tamen diras al la loka solvilo, kiujn retejojn vi vizitas.

Kio okazas, kiam la peranto fiaskas?

Eksplicita prokura servilo fiaskas fermite: haltigu la prokuran proceson kaj la retumilo aŭ aplikaĵo redonas konekteraron anstataŭ iri rekte. PAC- kaj WPAD-agordoj estas tiuj, kiuj fiaskas malfermite - se la skripto ne povas esti prenita, la kliento revenas al DIRECT kaj la retejo denove vidas vian veran adreson. VPN povas fiaski malfermite aŭ fermite depende de la kliento kaj ĉu mortiga ŝaltilo aŭ fajroŝirmila regulo estas aktiva.

Testu la fiaskan kazon intence: haltigu la prokuran servon kaj reŝargu; se vi ricevas erarpaĝon anstataŭ rekta ŝargo, direktu la PAC-URL al neatingebla gastiganto por vidi la retropaŝon. Se la paĝo ankoraŭ ŝargiĝas per via ordinara itinero, la prokura servilo ofertas neniun protekton kontraŭ sia propra elfalo, kaj tio estas eco, kiun vi devus koni antaŭ ol fidi ĝin.

La ordo decidas, kion vidas la retejo. Prokura servilo, kies elira trafiko iras tra la VPN, lasas la retejon vidi la adreson de la VPN-finpunkto; metu la prokuran servilon ekster la tunelo (VPN al prokura servilo sur fora gastiganto) kaj la retejo anstataŭe vidos la eliran adreson de tiu prokura servilo. Ĉiel ajn, la du saltoj povas registri malsamajn aferojn.

Kvin kontroloj, laŭvice

La kontrol-listo malsupre estas la tuta decido en unu loko. Kovrado venas unue ĉar ĝi forigas plej multajn miskongruojn: se la aplikaĵo, kiun oni devas kovri, ne respektas la agordon, nenio pli malsupre en la listo savas ĝin.

Poste konfirmu la rezulton per la aplikaĵo, kiu kaŭzis la ŝanĝon. Ŝargu paĝon en la agordita retumilo, prenu la saman paĝon per curl, kaj komparu la adreson, kiun ĉiu raportas. Se ili malkongruas, etendaĵo, PAC-regulo aŭ aplikaĵnivela superregado ankoraŭ funkcias, kaj nenia tunela agordado riparos ĝin.

Notu, kion vi agordis: kiuj aplikaĵoj uzas la prokuran servilon, ĉu DNS estas loka aŭ fora, ĉu UDP estas blokita, kaj kia estas la fiaskokonduto. Ĝuste tiu malgranda inventaro ebligas la sekvan komparon, ĉar “la IP ŝanĝiĝis” neniam diris al vi, kiun el ĉi tiuj kvin kontroloj vi trapasis.