A NetGuard SOCKS módja a TCP-t fedi le, nem minden protokollt

A NetGuard elfoglalja az Android VPN-interfészét, hogy szűrje a forgalmat, és a támogatott kapcsolatokat átadhatja egy SOCKS végpontnak. Ezt a két tényt gyakran úgy olvassák, hogy „a telefon VPN-en van”, ami olyan következtetés, amelyet a mechanizmus nem támaszt alá. A szűrő csomagokat lát; a proxy csak azokat a kapcsolatokat látja, amelyeket ténylegesen átadtak neki. A két állítás között a lefedettség teljes kérdése áll.

Az eredeti projekt GYIK-je dokumentálja az egyetlen szolgáltatásra vonatkozó korlátot és a SOCKS lehetőségét is. A lehetőség léte nem bizonyíték arra, hogy minden engedélyezett csomag használja, és a lefedettség kérdései éppen ebből a résből erednek.

Két továbbítási útvonal egyetlen alkalmazásban

A megvalósítás TCP oldala tartalmazza a SOCKS kapcsolatok kezelését, így egy engedélyezett TCP kapcsolat egyeztethető a proxyval, és rajta keresztül továbbítható. Az UDP oldalnak külön socket-útvonala van, és annak küldési és fogadási kezelése nem függ ettől a TCP egyeztetéstől. Ezért egy datagram, amelyet a szűrő engedélyez, elérheti a közönséges hálózatot anélkül, hogy valaha is áthaladna a proxyn. Ebben semmi sem az alkalmazás hibája; egyszerűen ezt valósítja meg a két útvonal.

Ennek a megkülönböztetésnek van egy következménye, amelyet az emberek mindkét irányban rosszul fogalmaznak meg. Minden UDP csomag szivárgásnak nevezése figyelmen kívül hagyja a blokkolási szabályokat, mert az elutasított datagram soha nem lép ki. Az egész elrendezés VPN-nek nevezése figyelmen kívül hagyja az engedélyezett közvetlen útvonalat, mert a forgalom egy része mégis proxy nélkül lép ki. Amit Önnek van, az egy részleges proxyval szűrt eszköz, és az őszinte leírás egy mátrix, nem egy címke.

Az UDP hirdetése nem azonos annak megvalósításával

Egy SOCKS kiszolgáló, amely UDP-támogatást állít, nem adja hozzá a megfelelő kliensoldali kezelést a telefonján futó alkalmazáshoz. A protokoll elméleti jellemzői és a telepített build viselkedése külön témák, és csak a második írja le a forgalmát.

Ellenőrizze a valóban futtatott verziót és konfigurációt, majd teszteljen egy ártalmatlan datagram-folyamot, és figyelje meg, megjelenik-e a proxyn. Minden más következtetés egy funkciólistából, a funkciólisták pedig szándékokat írnak le, nem kódútvonalakat.

A DNS harmadik útvonal, nem részletkérdés

A névfeloldás saját ágat ad a mátrixhoz. Egy helyi DNS-továbbító, egy közönséges UDP-lekérdezés, a proxy által maga feloldott cél-gazdagnév és a böngészőben futó titkosított feloldó négy különböző elrendezés. Abban különböznek, hogy ki látja a lekérdezést, és melyik hálózati útvonal viszi, és ezek összekeverése olyan tesztet ad, amely semmit sem bizonyít a többiről.

Tudatosan döntse el, melyiket szeretné. Ha a követelmény az, hogy a nevek az alagúton keresztül oldódjanak fel, egy böngészőbeállítás önmagában nem fogja ezt nyújtani, és az a proxy, amely maga oldja fel a gazdagéneveket, csak azon kapcsolatok válaszát változtatja meg, amelyeket ténylegesen kezel.

A proxy átvitele nem lesz automatikusan privát

A sima SOCKS nem titkosított kapcsolat a telefon és a proxy között. Ha a végpont egy másik védett útvonalon érhető el, nevezze meg azt az útvonalat és annak hibaeset-politikáját, mert a nyitott hálózatra való visszaesés figyelmeztetés nélkül tesz egy privát elrendezést nyilvánossá. A proxy saját hitelesítése is számít: a megosztott eszközön futó nyitott figyelő olyan szolgáltatás, amelyről senki nem ad számot.

A profilok közötti elrendezések ugyanilyen vizsgálatot érdemelnek. Egy munka-profil VPN-je csak azt a forgalmat védi, amely az ő útvonalát használja, és egy személyes profil tűzfalának és egy munkacsatornának az együttes léte nem bizonyítja, hogy a tűzfal továbbkapcsolata eléri azt az alagutat. Ellenőrizze az elérhetőséget és a hitelesítést ahelyett, hogy feltételezné a két profil együttműködését.

Auditálja a lefedettséget mátrixszal, ne oldalbetöltéssel

Jogosult értékeléshez válasszon ártalmatlan példákat, amelyek minden fontos osztályt képviselnek: szükséges TCP, engedélyezett UDP és DNS mindkét címcsaládban. Mindegyiknél jegyezze fel, hogy proxyn ment át, blokkolva lett vagy közvetlenül elküldve. Ez az egyetlen táblázat a szállítandó eredmény, és sokkal hasznosabb egy betöltött oldal képernyőképénél.

Ha a követelmény az, hogy minden kiválasztott alkalmazásforgalom távoli alagúton haladjon át, válasszon olyan megvalósítást, amely kifejezetten támogatja a kombinált szűrést és alagútkezelést. A csak TCP-proxyt tartalmazó összeállítás szűkebb feladatokra továbbra is hasznos, feltéve hogy a többi forgalmat szándékosan kezelik, nem pedig elfelejtik.