El modo SOCKS de NetGuard cubre TCP, no todos los protocolos

NetGuard ocupa la interfaz VPN de Android para filtrar el tráfico, y puede entregar las conexiones admitidas a un punto de conexión SOCKS. Estos dos hechos suelen leerse como «el teléfono está en una VPN», una conclusión que el mecanismo no respalda. El filtro ve paquetes; el proxy solo ve las conexiones que realmente se le entregaron. Entre ambas afirmaciones está toda la cuestión de la cobertura.

Las preguntas frecuentes del proyecto original documentan tanto la limitación a un solo servicio como la opción SOCKS. La existencia de la opción no es prueba de que cada paquete permitido la use, y de esa brecha surgen las preguntas sobre la cobertura.

Dos rutas de reenvío dentro de una aplicación

El lado TCP de la implementación contiene el manejo de conexiones SOCKS, así que una conexión TCP permitida puede negociarse con el proxy y transportarse a través de él. El lado UDP tiene una ruta de socket aparte, y su manejo de envío y recepción no depende de esa negociación TCP. Por tanto, un datagrama que el filtro permite puede llegar a la red ordinaria sin pasar nunca por el proxy. Nada de eso es un defecto de la aplicación; es simplemente lo que implementan las dos rutas.

Esta distinción tiene una consecuencia que la gente describe mal en ambas direcciones. Llamar fuga a cada paquete UDP ignora las reglas de bloqueo, porque un datagrama denegado nunca sale. Llamar VPN a toda la disposición ignora la ruta directa permitida, porque parte del tráfico sí sale sin proxy. Lo que tienes es un dispositivo filtrado con proxificación parcial, y la descripción honesta es una matriz, no una etiqueta.

Anunciar UDP no es implementarlo

Un servidor SOCKS que afirma admitir UDP no añade a la aplicación de tu teléfono el manejo correspondiente del lado del cliente. Las características teóricas del protocolo y el comportamiento de la compilación instalada son temas distintos, y solo el segundo describe tu tráfico.

Comprueba la versión y la configuración que realmente ejecutas, luego prueba un flujo de datagramas inofensivo y observa si aparece en el proxy. Cualquier otra cosa es una inferencia a partir de una lista de funciones, y las listas de funciones describen intenciones, no rutas de código.

DNS es una tercera ruta, no un detalle

La resolución de nombres añade su propia rama a la matriz. Un reenviador DNS local, una consulta UDP ordinaria, un nombre de host de destino resuelto por el propio proxy y un resolutor cifrado en el navegador son cuatro disposiciones distintas. Difieren en quién ve la consulta y en qué ruta de red la transporta, y mezclarlas produce una prueba que no demuestra nada sobre las demás.

Decide deliberadamente cuál quieres. Si el requisito es que los nombres se resuelvan por el túnel, una configuración del navegador por sí sola no lo logrará, y un proxy que resuelve él mismo los nombres de host solo cambia la respuesta para las conexiones que realmente maneja.

El transporte por el proxy no es privado automáticamente

SOCKS simple no es un enlace cifrado entre el teléfono y el proxy. Si se llega al punto de conexión por otra ruta protegida, nombra esa ruta y su política de fallo, porque una caída a la red abierta convierte una disposición privada en pública sin aviso. La autenticación del propio proxy también importa: un oyente abierto en un dispositivo compartido es un servicio del que nadie responde.

Las disposiciones entre perfiles merecen la misma revisión. Una VPN de perfil de trabajo solo protege el tráfico que usa su ruta, y la coexistencia de un cortafuegos de perfil personal con un túnel de trabajo no demuestra que la conexión posterior del cortafuegos llegue a ese túnel. Verifica la accesibilidad y la autenticación en lugar de suponer que los dos perfiles cooperan.

Audita la cobertura con una matriz, no con una carga de página

Para una evaluación autorizada, elige ejemplos inofensivos que representen cada clase que te importe: TCP necesario, UDP permitido y DNS en ambas familias de direcciones. Para cada uno, registra si se proxificó, se bloqueó o se envió directamente. Esa única tabla es el entregable, y es mucho más útil que una captura de pantalla de una página que se cargó.

Si el requisito es que todo el tráfico de aplicaciones seleccionado atraviese un túnel remoto, elige una implementación con filtrado y tunelización combinados explícitamente admitidos. Una composición de proxy solo TCP sigue siendo útil para tareas más estrechas, siempre que el otro tráfico se maneje a propósito y no se olvide.