VPN ali proxy: kaj vsak pokriva in česa ne

Tako VPN kot neposredni proxy spreminjata naslov, ki ga vidi spletno mesto, in tu se večina primerjav ustavi. Razlika, ki odloči o vaši nastavitvi, je pokritost: neposredni proxy je posrednik, ki se ga vaša aplikacija sama odloči uporabljati, v nasprotju z obratnim proxyjem, ki stoji pred spletnim mestom, VPN pa premakne vse, kar operacijski sistem usmeri v tunel. Šifriranje, ravnanje z DNS in vedenje ob napaki izhajajo iz te delitve. Izvedite teh pet preverjanj po vrsti in prvo, ki spodleti, vam bo povedalo, katero orodje v resnici potrebujete.

Katere aplikacije pokriva posrednik?

Razširitev proxyja v brskalniku velja le za ta profil brskalnika. Poštni odjemalci, upravitelji paketov in drug brskalnik še naprej uporabljajo svoje nastavitve, nekatere aplikacije pa sistemske spremenljivke proxyja povsem prezrejo. VPN pokriva, kar usmerjevalna tabela pošlje v tunel, to pa so lahko vse aplikacije ali podmnožica pri razdeljenem tunelu, odvisno od poti in politike odjemalca.

Preizkusite aplikacije, ki so pomembne, namesto da posplošujete iz enega nalaganja strani. curl https://ifconfig.me sledi spremenljivkam proxyja v okolju; namizna aplikacija morda ne. V Windows netsh winhttp show proxy izpiše proxy WinHTTP, ki ga uporabljajo storitve, in to je druga nastavitev kot v brskalniku.

Je skok šifriran in kje se konča TLS?

Protokol proxyja je zbirno mesto, ne jamstvo. SOCKS5 posreduje TCP brez šifriranja, običajni proxy HTTP pa prenaša vrstico zahteve in glave kot čisto besedilo. HTTPS prek proxyja uporablja CONNECT, zato se vaša seja TLS še vedno konča na cilju in ne na proxyju. Vodnik MDN o strežnikih proxy in tuneliranju opisuje to razliko s strani protokola.

VPN šifrira odsek med vašo napravo in njeno končno točko. Za končno točko veljajo enaka pravila kot v katerem koli drugem omrežju, zato tunel sam ne zaščiti aplikacije, ki pošilja poverilnice po običajnem HTTP. Nobena od obeh zasnov ne skrije prijavljenega računa, piškotka ali prstnega odtisa brskalnika.

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

Podroben izpis pokaže, ali je curl poslal CONNECT na vrata 443 ali običajen GET s polnim URL-jem. S socks5h:// proxy prejme ime gostitelja znotraj zahteve SOCKS5 in nato posreduje TLS, ki ga ne more brati, zato vidi ime in število bajtov. Prek proxyja http:// je naslov https:// CONNECT, zato tudi ta proxy vidi ime in obseg cilja, ne pa zahteve ali telesa odgovora.

Kateri razreševalnik vidi ime?

Razreševanje imen lahko poteka lokalno, preden zahteva odide, ali na daljavo na proxyju. Pri curl socks5h:// pošlje ime gostitelja proxyju, medtem ko ga socks5:// najprej razreši lokalno. Nastavitve proxyja v brskalniku ponujajo primerljivo možnost DNS, datoteke PAC pa lahko različne gostitelje usmerjajo na različne načine.

Dva protokola lahko obideta proxy brez kakršne koli napačne konfiguracije. WebRTC zbira kandidate prek STUN, QUIC pa poganja HTTP/3 prek UDP, česar proxy TCP ne more prenesti. Brskalnik se bo vrnil na TCP, če je UDP 443 blokiran, zato je blokiranje UDP 443 na požarnem zidu gostitelja (ali na usmerjevalniku za celo omrežje), in ne zastavica v brskalniku, zanesljiv način, da HTTP/3 ostane na poti proxyja.

Razreševalnik preverite z vidika cilja, ne svojega prenosnika. Zahteva, ki prispe z izhodnim naslovom proxyja, a z lokalno razrešenim imenom, še vedno pove lokalnemu razreševalniku, katere strani obiskujete.

Kaj se zgodi, ko posrednik odpove?

Izrecni proxy odpove zaprto: ustavite proces proxyja in brskalnik ali aplikacija vrne napako povezave, namesto da bi šla neposredno. Nastavitve PAC in WPAD so tiste, ki odpovejo odprto - če scenarija ni mogoče pridobiti, odjemalec pade nazaj na DIRECT in spletno mesto spet vidi vaš pravi naslov. VPN lahko odpove odprto ali zaprto, odvisno od odjemalca in tega, ali je aktiven kill switch ali pravilo požarnega zidu.

Preizkusite primer napake namerno: ustavite storitev proxyja in znova naložite; če dobite stran z napako namesto neposrednega nalaganja, usmerite URL PAC na nedosegljivega gostitelja, da vidite nadomestno vedenje. Če se stran še vedno naloži po vaši običajni poti, proxy ne ponuja nobene zaščite pred lastno motnjo, in to je lastnost, ki bi jo morali poznati, preden se nanj zanesete.

Vrstni red odloči, kaj vidi spletno mesto. Proxy, katerega odhodni promet gre skozi VPN, pusti spletnemu mestu naslov končne točke VPN; postavite proxy izven tunela (VPN do proxyja na oddaljenem gostitelju) in spletno mesto bo namesto tega videlo izhodni naslov tega proxyja. V vsakem primeru lahko dva skoka beležita različne stvari.

Pet preverjanj, po vrsti

Kontrolni seznam spodaj je celotna odločitev na enem mestu. Pokritost je prva, ker odpravi večino neskladij: če aplikacija, ki mora biti pokrita, nastavitve ne upošteva, je nič pozneje na seznamu ne reši.

Nato potrdite rezultat z aplikacijo, ki je sprožila spremembo. Naložite stran v nastavljenem brskalniku, pridobite isto stran s curl in primerjajte naslov, ki ga poroča vsak. Če se ne ujemata, še vedno deluje razširitev, pravilo PAC ali prepis na ravni aplikacije, in nobeno uglaševanje tunela tega ne bo popravilo.

Zapišite, kaj ste nastavili: katere aplikacije uporabljajo proxy, ali je DNS lokalni ali oddaljen, ali je UDP blokiran in kakšno je vedenje ob napaki. Prav ta majhen seznam omogoča naslednjo primerjavo, ker „IP se je spremenil“ vam ni nikoli povedalo, katero od teh petih preverjanj je uspelo.