NetGuards SOCKS-modus dekt TCP, niet elk protocol
NetGuard filtert via Androids VPN-interface en kan ondersteunde verbindingen aan SOCKS overdragen. UDP, DNS en bereikbaarheid tussen profielen vragen een eigen controle.
NetGuard bezet Androids VPN-interface om verkeer te filteren, en kan ondersteunde verbindingen aan een SOCKS-eindpunt overdragen. Deze twee feiten worden vaak gelezen als „de telefoon zit op een VPN”, een conclusie die het mechanisme niet ondersteunt. Het filter ziet pakketten; de proxy ziet alleen de verbindingen die er daadwerkelijk aan zijn overgedragen. Tussen die twee uitspraken staat de hele vraag naar dekking.
De FAQ van het bovenliggende project documenteert zowel de beperking tot één dienst als de SOCKS-optie. Het bestaan van de optie is geen bewijs dat elk toegestaan pakket hem gebruikt, en juist uit die kloof komen de dekkingsvragen.
Twee doorstuurpaden binnen één app
De TCP-kant van de implementatie bevat SOCKS-verbindingsafhandeling, dus een toegestane TCP-verbinding kan met de proxy worden onderhandeld en erdoorheen worden gedragen. De UDP-kant heeft een apart socketpad, en de afhandeling van verzenden en ontvangen hangt niet van die TCP-onderhandeling af. Een datagram dat het filter toestaat, kan daardoor het gewone netwerk bereiken zonder ooit door de proxy te gaan. Niets daarvan is een defect in de app; het is simpelweg wat de twee paden implementeren.
Dit onderscheid heeft een gevolg dat mensen in beide richtingen verkeerd beschrijven. Elk UDP-pakket een lek noemen negeert de blokkeerregels, omdat een geweigerd datagram het apparaat nooit verlaat. De hele opzet een VPN noemen negeert het toegestane directe pad, omdat een deel van het verkeer inderdaad zonder proxy naar buiten gaat. Wat u hebt, is een gefilterd apparaat met gedeeltelijke proxy, en de eerlijke beschrijving is een matrix, geen label.
UDP adverteren is het niet implementeren
Een SOCKS-server die UDP-ondersteuning claimt, voegt de bijbehorende clientafhandeling niet toe aan de app op uw telefoon. De theoretische kenmerken van het protocol en het gedrag van de geïnstalleerde build zijn verschillende onderwerpen, en alleen het tweede beschrijft uw verkeer.
Controleer de versie en configuratie die u werkelijk draait, test dan een onschadelijke datagramstroom en kijk of die bij de proxy verschijnt. Al het andere is een gevolgtrekking uit een functielijst, en functielijsten beschrijven bedoelingen, geen codepaden.
DNS is een derde pad, geen detail
Naamresolutie voegt zijn eigen tak aan de matrix toe. Een lokale DNS-doorstuurserver, een gewone UDP-query, een bestemmingshostnaam die de proxy zelf oplost en een versleutelde resolver in de browser zijn vier verschillende opzetten. Ze verschillen in wie de query ziet en welk netwerkpad hem draagt, en ze door elkaar halen levert een test op die niets over de andere bewijst.
Beslis bewust welke u wilt. Als de eis is dat namen via de tunnel worden opgelost, levert een browserinstelling alleen dat niet, en een proxy die hostnamen zelf oplost verandert het antwoord alleen voor de verbindingen die hij werkelijk afhandelt.
Het transport via de proxy is niet automatisch privé
Gewone SOCKS is geen versleutelde verbinding van telefoon naar proxy. Als het eindpunt via een ander beschermd pad wordt bereikt, benoem dat pad en het faalbeleid ervan, want een terugval naar het open netwerk maakt een particuliere opzet zonder waarschuwing openbaar. De authenticatie van de proxy zelf telt ook: een open luisteraar op een gedeeld apparaat is een dienst waar niemand verantwoording voor aflegt.
Opzetten tussen profielen verdienen hetzelfde onderzoek. Een werkprofiel-VPN beschermt alleen het verkeer dat zijn pad gebruikt, en het naast elkaar bestaan van een firewall in het persoonlijke profiel en een werktunnel bewijst niet dat de vervolgverbinding van de firewall die tunnel bereikt. Controleer bereikbaarheid en authenticatie in plaats van aan te nemen dat de twee profielen samenwerken.
Controleer de dekking met een matrix, niet met een paginalading
Kies voor een geautoriseerde evaluatie onschadelijke voorbeelden die elke klasse vertegenwoordigen die voor u belangrijk is: vereist TCP, toegestaan UDP en DNS in beide adresfamilies. Noteer voor elk of het via de proxy ging, werd geblokkeerd of direct werd verzonden. Die ene tabel is het resultaat, en die is veel nuttiger dan een schermafbeelding van een pagina die is geladen.
Als de eis is dat al het geselecteerde applicatieverkeer een externe tunnel moet passeren, kies dan een implementatie met uitdrukkelijk ondersteunde gecombineerde filtering en tunneling. Een samenstelling met alleen TCP-proxy blijft nuttig voor smallere taken, mits het overige verkeer met opzet wordt behandeld en niet vergeten.