NetGuard zaberá VPN rozhranie Androidu, aby filtroval prevádzku, a môže odovzdávať podporované spojenia do koncového bodu SOCKS. Tieto dva fakty sa často čítajú ako „telefón je na VPN“, čo je záver, ktorý mechanizmus nepodporuje. Filter vidí pakety; proxy vidí len tie spojenia, ktoré mu boli skutočne odovzdané. Medzi týmito dvoma tvrdeniami stojí celá otázka pokrytia.

FAQ v pôvodnom projekte dokumentuje tak obmedzenie na jedinú službu, ako aj možnosť SOCKS. Existencia možnosti nie je dôkazom, že ju používa každý povolený paket, a práve z tejto medzery pramenia otázky pokrytia.

Dve cesty preposielania v jednej aplikácii

Strana TCP implementácie obsahuje obsluhu SOCKS spojení, takže povolené TCP spojenie možno vyjednať s proxy a preniesť cez ňu. Strana UDP má samostatnú cestu socketu a jej obsluha odosielania a prijímania nezávisí od tohto TCP vyjednania. Datagram, ktorý filter povolí, preto môže dosiahnuť bežnú sieť bez toho, aby kedy prešiel cez proxy. Nič z toho nie je chyba aplikácie; je to jednoducho to, čo obe cesty implementujú.

Toto rozlíšenie má dôsledok, ktorý ľudia opisujú nesprávne v oboch smeroch. Nazvať každý UDP paket únikom znamená ignorovať pravidlá blokovania, pretože odmietnutý datagram nikdy neodíde. Nazvať celé usporiadanie VPN znamená ignorovať povolenú priamu cestu, pretože časť prevádzky skutočne odchádza bez proxy. To, čo máte, je filtrované zariadenie s čiastočným proxy, a čestný opis je matica, nie štítok.

Inzerovať UDP neznamená implementovať ho

SOCKS server, ktorý tvrdí podporu UDP, nepridáva zodpovedajúcu obsluhu na strane klienta do aplikácie vo vašom telefóne. Teoretické vlastnosti protokolu a správanie nainštalovaného zostavenia sú rozdielne témy a vašu prevádzku opisuje len druhá z nich.

Skontrolujte verziu a konfiguráciu, ktorú skutočne používate, potom otestujte neškodný tok datagramov a sledujte, či sa objaví na proxy. Čokoľvek iné je odvodenie zo zoznamu funkcií, a zoznamy funkcií opisujú zámery, nie cesty kódu.

DNS je tretia cesta, nie detail

Preklad názvov pridáva do matice vlastnú vetvu. Lokálny DNS forwarder, bežná UDP požiadavka, cieľové meno hostiteľa rozlíšené samotnou proxy a šifrovaný resolver v prehliadači sú štyri odlišné usporiadania. Líšia sa v tom, kto požiadavku vidí a ktorá sieťová cesta ju nesie, a ich miešanie dáva test, ktorý o ostatných nič nedokazuje.

Rozhodnite sa vedome, ktorú chcete. Ak je požiadavkou, aby sa názvy prekladali cez tunel, samotné nastavenie prehliadača to nezabezpečí, a proxy, ktorá sama prekladá mená hostiteľov, mení odpoveď len pre spojenia, ktoré skutočne obsluhuje.

Transport cez proxy nie je automaticky súkromný

Obyčajný SOCKS nie je šifrované spojenie z telefónu na proxy. Ak sa koncový bod dosahuje inou chránenou cestou, pomenujte tú cestu a jej politiku zlyhania, pretože návrat k otvorenej sieti mení súkromné usporiadanie na verejné bez varovania. Dôležitá je aj samotná autentifikácia proxy: otvorený poslucháč na zdieľanom zariadení je služba, z ktorej nikto neskladá účty.

Usporiadania medzi profilmi si zaslúžia rovnaké skúmanie. VPN pracovného profilu chráni len prevádzku, ktorá používa jeho cestu, a súčasná existencia firewallu osobného profilu s pracovným tunelom nedokazuje, že nadväzujúce spojenie firewallu dosiahne tento tunel. Overujte dostupnosť a autentifikáciu, namiesto toho, aby ste predpokladali, že oba profily spolupracujú.

Auditujte pokrytie maticou, nie načítaním stránky

Pre autorizované hodnotenie vyberte neškodné príklady zastupujúce každú triedu, na ktorej vám záleží: požadované TCP, povolené UDP a DNS v oboch rodinách adries. Pri každom zaznamenajte, či bol proxovaný, zablokovaný alebo odoslaný priamo. Jediná tabuľka je výstup a je oveľa užitočnejšia než snímka obrazovky načítanej stránky.

Ak je požiadavkou, aby všetka vybraná prevádzka aplikácií prechádzala vzdialeným tunelom, zvoľte implementáciu s výslovne podporovaným kombinovaným filtrovaním a tunelovaním. Zostava len s TCP proxy zostáva užitočná pre užšie úlohy, ak sa s ostatnou prevádzkou zaobchádza zámerne a nie je zabudnutá.

Súvisiace články