Režim SOCKS v NetGuardu pokrývá TCP, ne každý protokol

NetGuard zabírá VPN rozhraní Androidu, aby filtroval provoz, a může předávat podporovaná spojení do koncového bodu SOCKS. Tyto dva fakty se často čtou jako „telefon je na VPN“, což je závěr, který mechanismus nepodporuje. Filtr vidí pakety; proxy vidí jen spojení, která mu byla skutečně předána. Mezi těmito dvěma tvrzeními stojí celá otázka pokrytí.

FAQ v původním projektu dokumentuje jak omezení na jedinou službu, tak volbu SOCKS. Existence volby není důkazem, že ji používá každý povolený paket, a právě z této mezery pramení otázky pokrytí.

Dvě cesty předávání v jedné aplikaci

Strana TCP implementace obsahuje obsluhu SOCKS spojení, takže povolené TCP spojení lze vyjednat s proxy a přenést přes ně. Strana UDP má samostatnou cestu socketu a její obsluha odesílání a přijímání na tomto TCP vyjednání nezávisí. Datagram, který filtr povolí, tedy může dosáhnout běžné sítě, aniž by kdy prošel proxy. Nic z toho není vada aplikace; je to prostě to, co obě cesty implementují.

Toto rozlišení má důsledek, který lidé popisují chybně v obou směrech. Nazvat každý UDP paket únikem znamená ignorovat pravidla blokování, protože zamítnutý datagram nikdy neodejde. Nazvat celé uspořádání VPN znamená ignorovat povolenou přímou cestu, protože část provozu skutečně odchází bez proxy. To, co máte, je filtrované zařízení s částečným proxováním, a poctivý popis je matice, nikoli štítek.

Inzerovat UDP neznamená jej implementovat

SOCKS server, který tvrdí, že podporuje UDP, nepřidává odpovídající obsluhu na straně klienta do aplikace ve vašem telefonu. Teoretické vlastnosti protokolu a chování nainstalovaného sestavení jsou různá témata a váš provoz popisuje jen to druhé.

Zkontrolujte verzi a konfiguraci, kterou skutečně používáte, poté otestujte neškodný tok datagramů a sledujte, zda se objeví na proxy. Cokoli jiného je odvození ze seznamu funkcí, a seznamy funkcí popisují záměry, nikoli cesty kódu.

DNS je třetí cesta, ne detail

Překlad názvů přidává do matice svou vlastní větev. Místní DNS forwarder, běžný UDP dotaz, cílové jméno hostitele rozlišené samotnou proxy a šifrovaný resolver v prohlížeči jsou čtyři odlišná uspořádání. Liší se v tom, kdo dotaz vidí a která síťová cesta ho nese, a jejich míchání dává test, který o ostatních nic nedokazuje.

Rozhodněte se vědomě, které chcete. Pokud je požadavkem, aby se názvy překládaly tunelem, samotné nastavení prohlížeče to nezajistí, a proxy, která sama překládá jména hostitelů, mění odpověď jen pro spojení, která skutečně obsluhuje.

Přenos přes proxy není automaticky soukromý

Obyčejný SOCKS není šifrované spojení z telefonu k proxy. Pokud se koncový bod dosahuje jinou chráněnou cestou, pojmenujte ji a její politiku selhání, protože návrat k otevřené síti mění soukromé uspořádání na veřejné bez varování. Vlastní autentizace proxy je také důležitá: otevřený posluchač na sdíleném zařízení je služba, ze které nikdo neskládá účty.

Uspořádání mezi profily si zaslouží stejné zkoumání. VPN pracovního profilu chrání jen provoz, který používá její cestu, a souběh firewallu osobního profilu s pracovním tunelem nedokazuje, že navazující spojení firewallu dosáhne tohoto tunelu. Ověřujte dostupnost a autentizaci, místo abyste předpokládali, že oba profily spolupracují.

Auditujte pokrytí maticí, ne načtením stránky

Pro autorizované hodnocení vyberte neškodné příklady zastupující každou třídu, na které vám záleží: požadované TCP, povolené UDP a DNS v obou rodinách adres. U každého zaznamenejte, zda byl proxován, zablokován nebo odeslán přímo. Jediná tabulka je výstup a je mnohem užitečnější než snímek obrazovky načtené stránky.

Pokud je požadavkem, aby veškerý vybraný provoz aplikací procházel vzdáleným tunelem, zvolte implementaci s výslovně podporovaným kombinovaným filtrováním a tunelováním. Sestava s proxy jen pro TCP zůstává užitečná pro užší úkoly, pokud se s ostatním provozem zachází záměrně, a ne aby se na něj zapomnělo.