O modo SOCKS de NetGuard cobre TCP, non todos os protocolos

NetGuard ocupa a interface VPN de Android para filtrar o tráfico, e pode entregar as conexións admitidas a un punto final SOCKS. Estes dous feitos adoitan lerse como «o teléfono está nunha VPN», unha conclusión que o mecanismo non apoia. O filtro ve paquetes; o proxy só ve as conexións que realmente se lle entregaron. Entre ambas as afirmacións está toda a cuestión da cobertura.

As preguntas frecuentes do proxecto orixinal documentan tanto a limitación a un só servizo como a opción SOCKS. A existencia da opción non é proba de que cada paquete permitido a use, e desa fenda xorden as preguntas sobre a cobertura.

Dúas rutas de reenvío dentro dunha aplicación

O lado TCP da implementación contén o manexo de conexións SOCKS, así que unha conexión TCP permitida pode negociarse co proxy e transportarse a través del. O lado UDP ten unha ruta de socket aparte, e o seu manexo de envío e recepción non depende desa negociación TCP. Por tanto, un datagrama que o filtro permite pode chegar á rede ordinaria sen pasar nunca polo proxy. Nada diso é un defecto da aplicación; é simplemente o que implementan as dúas rutas.

Esta distinción ten unha consecuencia que a xente describe mal en ambas as direccións. Chamar fuga a cada paquete UDP ignora as regras de bloqueo, porque un datagrama denegado nunca sae. Chamar VPN a toda a disposición ignora a ruta directa permitida, porque parte do tráfico si sae sen proxy. O que tes é un dispositivo filtrado con proxificación parcial, e a descrición honesta é unha matriz, non unha etiqueta.

Anunciar UDP non é implementalo

Un servidor SOCKS que afirma admitir UDP non engade á aplicación do teu teléfono o manexo correspondente do lado do cliente. As características teóricas do protocolo e o comportamento da compilación instalada son temas distintos, e só o segundo describe o teu tráfico.

Comproba a versión e a configuración que realmente executas, despois proba un fluxo de datagramas inofensivo e observa se aparece no proxy. Calquera outra cousa é unha inferencia a partir dunha lista de funcións, e as listas de funcións describen intencións, non rutas de código.

DNS é unha terceira ruta, non un detalle

A resolución de nomes engade a súa propia rama á matriz. Un reenviador DNS local, unha consulta UDP ordinaria, un nome de host de destino resolto polo propio proxy e un resolvedor cifrado no navegador son catro disposicións distintas. Diferéncianse en quen ve a consulta e en que ruta de rede a transporta, e mesturalas produce unha proba que non demostra nada sobre as demais.

Decide deliberadamente cal queres. Se o requisito é que os nomes se resolvan polo túnel, unha configuración do navegador por si soa non o acadará, e un proxy que resolve el mesmo os nomes de host só cambia a resposta para as conexións que realmente manexa.

O transporte polo proxy non é privado automaticamente

SOCKS simple non é unha ligazón cifrada entre o teléfono e o proxy. Se se chega ao punto final por outra ruta protexida, nomea esa ruta e a súa política de fallo, porque unha caída á rede aberta converte unha disposición privada en pública sen aviso. A autenticación do propio proxy tamén importa: un oínte aberto nun dispositivo compartido é un servizo do que ninguén responde.

As disposicións entre perfís merecen a mesma revisión. Unha VPN de perfil de traballo só protexe o tráfico que usa a súa ruta, e a coexistencia dun cortalumes de perfil persoal cun túnel de traballo non demostra que a conexión posterior do cortalumes chegue a ese túnel. Verifica a accesibilidade e a autenticación en lugar de supor que os dous perfís cooperan.

Audita a cobertura cunha matriz, non cunha carga de páxina

Para unha avaliación autorizada, escolle exemplos inofensivos que representen cada clase que te importe: TCP necesario, UDP permitido e DNS en ambas as familias de enderezos. Para cada un, rexistra se se proxificou, se se bloqueou ou se se enviou directamente. Esa única táboa é o entregable, e é moito máis útil que unha captura de pantalla dunha páxina que se cargou.

Se o requisito é que todo o tráfico de aplicacións seleccionado atravese un túnel remoto, escolle unha implementación con filtrado e tunnelización combinados explicitamente admitidos. Unha composición de proxy só TCP segue sendo útil para tarefas máis estreitas, sempre que o outro tráfico se manexe a propósito e non se esqueza.