VPN vagy proxy: melyik mit fed le, és mit nem

A VPN és a forward proxy is megváltoztatja a címet, amelyet egy webhely lát, és itt véget is ér a legtöbb összehasonlítás. A beállítást eldöntő különbség a lefedettség: a forward proxy olyan közvetítő, amelyet az alkalmazás maga választ, ellentétben a webhely előtt álló reverse proxyval, a VPN pedig mindent mozgat, amit az operációs rendszer egy alagútba irányít. A titkosítás, a DNS-kezelés és a hibaeset viselkedése mind ebből a felosztásból következik. Hajtsa végre ezt az öt ellenőrzést sorrendben, és az első, amelyik megbukik, megmutatja, melyik eszközre van valójában szüksége.

Mely alkalmazásokat fedi le a közvetítő?

A böngésző proxykiegészítője csak arra a böngészőprofilra érvényes. A levelezőkliensek, a csomagkezelők és egy második böngésző továbbra is a saját beállításaikat használják, és egyes alkalmazások teljesen figyelmen kívül hagyják a rendszer proxyváltozóit. A VPN azt fedi le, amit a routingtábla az alagútba küld, ez lehet az összes alkalmazás vagy megosztott alagút esetén egy részhalmaz, az útvonalaktól és a kliensházirendtől függően.

Tesztelje azokat az alkalmazásokat, amelyek számítanak, ne egyetlen oldalbetöltésből általánosítson. A curl https://ifconfig.me követi a környezet proxyváltozóit; egy asztali alkalmazás talán nem. Windowson a netsh winhttp show proxy kiírja a szolgáltatások által használt WinHTTP proxyt, és ez más beállítás, mint a böngészőé.

Titkosított-e az ugrás, és hol végződik a TLS?

A proxyprotokoll találkozóhely, nem garancia. A SOCKS5 titkosítás nélkül továbbítja a TCP-t, a sima HTTP proxy pedig a kérés sort és a fejléceket nyílt szövegként viszi. A proxyzott HTTPS CONNECT-et használ, így a TLS-munkamenet továbbra is a célállomáson végződik, nem a proxyn. Az MDN útmutatója a proxyszerverekről és az alagutazásról a protokoll oldaláról írja le ezt a különbséget.

A VPN titkosítja az eszköze és végpontja közötti szakaszt. A végponton túl ugyanazok a szabályok érvényesek, mint bármely más hálózaton, ezért egy alagút önmagában nem védi meg azt az alkalmazást, amely sima HTTP-n küld hitelesítő adatokat. Egyik kialakítás sem rejti el a bejelentkezett fiókot, a cookie-t vagy a böngészőujjlenyomatot.

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

A részletes kimenet megmutatja, hogy a curl CONNECT-et küldött-e a 443-as portra, vagy sima GET-et teljes URL-lel. A socks5h:// esetén a proxy a hosztnevet a SOCKS5-kérésen belül kapja meg, majd olyan TLS-t továbbít, amelyet nem tud olvasni, így látja a nevet és a bájtszámot. Egy http:// proxyn keresztül a https:// URL CONNECT, így az a proxy is látja a cél nevét és forgalmának méretét, de a kérést és a válasz törzsét nem.

Melyik feloldó látja a nevet?

A névfeloldás helyben is történhet, mielőtt a kérés elindul, vagy távolról a proxyn. A curl esetében a socks5h:// a hosztnevet a proxynak küldi, míg a socks5:// először helyben oldja fel. A böngésző proxybeállításai hasonló DNS-lehetőséget kínálnak, és a PAC-fájlok a különböző hosztokat különbözőképpen irányíthatják.

Két protokoll minden hibás beállítás nélkül megkerülheti a proxyt. A WebRTC STUN-on keresztül gyűjti a jelölteket, a QUIC pedig HTTP/3-at futtat UDP fölött, amelyet egy TCP-proxy nem tud továbbítani. A böngésző visszatér a TCP-re, ha az UDP 443 blokkolva van, ezért az UDP 443 blokkolása a gazdagép tűzfalán (vagy az útválasztón egy egész hálózat számára), nem pedig egy böngészőkapcsoló, a megbízható módja annak, hogy a HTTP/3 a proxy útvonalán maradjon.

A feloldót a cél szemszögéből ellenőrizze, ne a laptopjáéból. Egy kérés, amely a proxy kimenő címével, de helyben feloldott névvel érkezik, még mindig elmondja a helyi feloldónak, mely oldalakat látogatja.

Mi történik, amikor a közvetítő meghibásodik?

A kifejezett proxy zárt módban hibázik: állítsa le a proxyfolyamatot, és a böngésző vagy az alkalmazás kapcsolódási hibát ad vissza ahelyett, hogy közvetlenül menne. A PAC- és WPAD-beállítások azok, amelyek nyílt módban hibáznak - ha a szkript nem kérhető le, a kliens visszaesik a DIRECT-re, és a webhely újra a valódi címét látja. A VPN a klienstől és attól függően hibázhat nyíltan vagy zártan, hogy aktív-e egy kill switch vagy tűzfalszabály.

Tesztelje szándékosan a hibaesetet: állítsa le a proxyszolgáltatást, és töltse újra; ha hibaoldalt kap a közvetlen betöltés helyett, irányítsa a PAC URL-t egy elérhetetlen gazdagépre, hogy lássa a visszaesést. Ha az oldal továbbra is a szokásos útvonalán töltődik be, a proxy semmilyen védelmet nem nyújt a saját kiesésével szemben, és ezt a tulajdonságot érdemes ismerni, mielőtt támaszkodik rá.

A sorrend dönti el, mit lát a webhely. Az a proxy, amelynek kimenő forgalma a VPN-en halad át, a webhelynek a VPN végpontjának címét mutatja; tegye a proxyt az alagúton kívülre (VPN egy távoli gazdagépen lévő proxyhoz), és a webhely helyette annak a proxynak a kimenő címét látja. Mindkét esetben a két ugrás különböző dolgokat naplózhat.

Öt ellenőrzés, sorrendben

Az alábbi ellenőrzőlista az egész döntés egy helyen. A lefedettség azért jön először, mert kiküszöböli a legtöbb eltérést: ha a lefedendő alkalmazás nem tartja be a beállítást, semmi a lista későbbi részén nem menti meg.

Ezután erősítse meg az eredményt azzal az alkalmazással, amely a változást kiváltotta. Töltsön be egy oldalt a beállított böngészőben, kérje le ugyanazt az oldalt curl-lel, és hasonlítsa össze a címeket, amelyeket jelentenek. Ha eltérnek, még mindig játékban van egy kiegészítő, egy PAC-szabály vagy egy alkalmazásszintű felülírás, és semmilyen alagúthangolás nem javítja meg.

Jegyezze fel, mit állított be: mely alkalmazások használják a proxyt, a DNS helyi-e vagy távoli, blokkolva van-e az UDP, és mi a hibaeset viselkedése. Ez a kis leltár teszi lehetővé a következő összehasonlítást, mert „megváltozott az IP” soha nem mondta meg, hogy ezek közül az öt ellenőrzés közül melyik sikerült.