El mode SOCKS del NetGuard cobreix TCP, no tots els protocols

El NetGuard ocupa la interfície VPN d'Android per filtrar el trànsit, i pot lliurar les connexions admeses a un punt de terminació SOCKS. Aquests dos fets sovint es llegeixen com «el telèfon és en una VPN», una conclusió que el mecanisme no permet. El filtre veu els paquets; el proxy només veu les connexions que realment se li van lliurar. Entre aquestes dues afirmacions hi ha tota la qüestió de la cobertura.

Les FAQ del projecte original documenten tant la limitació a un sol servei com l'opció SOCKS. L'existència de l'opció no és prova que cada paquet permès la faci servir, i d'aquest buit surten les preguntes sobre la cobertura.

Dos camins de reenviament dins d'una aplicació

El costat TCP de la implementació conté la gestió de connexions SOCKS, així que una connexió TCP permesa es pot negociar amb el proxy i transportar a través d'ell. El costat UDP té un camí de sòcol separat, i la seva gestió d'enviament i recepció no depèn d'aquesta negociació TCP. Per tant, un datagrama que el filtre permet pot arribar a la xarxa ordinària sense passar mai pel proxy. Res d'això no és un defecte de l'aplicació; és simplement el que implementen els dos camins.

Aquesta distinció té una conseqüència que la gent descriu malament en totes dues direccions. Anomenar cada paquet UDP una fuita ignora les regles de bloqueig, perquè un datagrama denegat no surt mai. Anomenar tota la disposició una VPN ignora el camí directe permès, perquè part del trànsit sí que surt sense proxy. El que tens és un dispositiu filtrat amb proxificació parcial, i la descripció honesta és una matriu, no una etiqueta.

Anunciar UDP no és implementar-lo

Un servidor SOCKS que afirma suportar UDP no afegeix la gestió corresponent al costat client de l'aplicació del teu telèfon. Les característiques teòriques del protocol i el comportament de la compilació instal·lada són temes diferents, i només el segon descriu el teu trànsit.

Comprova la versió i la configuració que realment executes, després prova un flux de datagrames inofensiu i observa si apareix al proxy. Qualsevol altra cosa és una inferència a partir d'una llista de funcions, i les llistes de funcions descriuen intencions, no camins de codi.

DNS és un tercer camí, no un detall

La resolució de noms afegeix la seva pròpia branca a la matriu. Un reenviador DNS local, una consulta UDP ordinària, un nom d'amfitrió de destinació resolt pel mateix proxy i un resolutor xifrat al navegador són quatre disposicions diferents. Difereixen en qui veu la consulta i en quin camí de xarxa la transporta, i barrejar-les produeix una prova que no demostra res sobre les altres.

Decideix deliberadament quina vols. Si el requisit és que els noms es resolguin pel túnel, només una configuració del navegador no ho lliurarà, i un proxy que resol els noms d'amfitrió ell mateix només canvia la resposta per a les connexions que realment gestiona.

El transport pel proxy no és privat automàticament

Un SOCKS simple no és un enllaç xifrat entre el telèfon i el proxy. Si s'arriba al punt de terminació per un altre camí protegit, anomena aquest camí i la seva política de fallada, perquè una caiguda a la xarxa oberta converteix una disposició privada en pública sense avís. L'autenticació del propi proxy també importa: un oient obert en un dispositiu compartit és un servei del qual ningú no respon.

Les disposicions entre perfils mereixen la mateixa atenció. Una VPN de perfil de treball només protegeix el trànsit que fa servir el seu camí, i la coexistència d'un tallafoc de perfil personal amb un túnel de treball no demostra que la connexió posterior del tallafoc arribi a aquest túnel. Verifica l'abastabilitat i l'autenticació en lloc de suposar que els dos perfils cooperen.

Audita la cobertura amb una matriu, no amb una càrrega de pàgina

Per a una avaluació autoritzada, tria exemples inofensius que representin cada classe que t'importi: TCP necessari, UDP permès i DNS en les dues famílies d'adreces. Per a cada un, anota si es va proxificar, es va bloquejar o es va enviar directament. Aquesta única taula és el lliurable, i és molt més útil que una captura de pantalla d'una pàgina que s'ha carregat.

Si el requisit és que tot el trànsit d'aplicacions seleccionat travessi un túnel remot, tria una implementació amb filtratge i tunelatge combinats explícitament suportats. Una composició de proxy només TCP continua sent útil per a tasques més estretes, sempre que l'altre trànsit es gestioni a propòsit i no s'oblidi.