¿Marcador VPN en el dispositivo o dirección de salida: cuál demuestra qué?
Un marcador de red leído en el dispositivo y una dirección observada por un servidor son pruebas distintas. Decida cuál necesita la pregunta que hace.
La aplicación del teléfono y el servidor remoto parten de hechos distintos, y ninguno puede tomar prestados los del otro. La aplicación puede preguntar al sistema operativo por la red que utiliza, mientras que el servidor solo sabe lo que llega por la conexión. Ejecutar su propio punto final reescribe el segundo y deja intacto el primero. Cuál de los dos responde a su pregunta depende de la pregunta misma.
Dos puntos de observación, dos tipos de prueba
La prueba local describe el dispositivo. Abarca la interfaz que transporta el tráfico, el transporte que informa la plataforma y aquello que la aplicación que llama puede consultar. La prueba remota describe la conexión: dirección de origen, protocolo, tiempos y todo lo que la aplicación decida enviar. Ningún punto de observación es un superconjunto del otro.
Mezclar los dos produce afirmaciones que suenan exactas y no se pueden comprobar. Un marcador demuestra algo sobre un objeto de red del dispositivo, no sobre cómo clasifica la petición un servicio remoto.
Antes de discutir sobre la detección, anote a qué punto se refiere la pregunta. ¿Se trata de si una aplicación concreta puede saber que un túnel está activo, o de si un servicio puede inferir de dónde vino la petición? Son investigaciones separadas, y la respuesta a una no dice nada sobre la otra.
Qué puede informar una interfaz local de plataforma
Android ofrece un marcador concreto. El objeto NetworkCapabilities puede informar TRANSPORT_VPN, y hasTransport comprueba si ese transporte está presente en el objeto. La aplicación obtiene el objeto del servicio de conectividad y lo lee, sujeto al permiso de estado de red.
El resultado es información local de la plataforma, no una consulta a los rangos de direcciones de un proveedor. Describe la red que usa la aplicación que llama.
Dos límites importan. Una regla de túnel dividido que excluye una aplicación puede dar en el mismo teléfono una respuesta distinta de la que ve un colega, porque la aplicación puede estar vinculada en otro lugar. El marcador también existe porque el sistema operativo modela interfaces VPN, no porque lo recoja una aplicación concreta. Si una aplicación lee el campo, lo reenvía o lo ignora es una propiedad de esa aplicación. Su manifiesto y su documentación son las únicas fuentes fiables para esa pregunta.
adb shell dumpsys connectivity | grep -i -m5 vpnQué puede ver un servicio remoto
Un servidor ve la dirección de origen de la conexión, el transporte y los tiempos, y puede enriquecer la dirección con datos de registro o de enrutamiento. También puede recibir todo lo que envíe la aplicación, incluida la ubicación cuando la aplicación la pide y el usuario acepta. Esos canales son separados, y solo uno se parece a una consulta de dirección.
Una dirección registrada en un proveedor de alojamiento sugiere un túnel, mientras que una registrada en una red residencial sugiere una conexión doméstica. Ambas son indicios estadísticos, no hechos sobre el dispositivo.
Una dirección residencial no sitúa a la persona en esa dirección, y una dirección de alojamiento no nombra al operador ni al país. Un servicio que trata la inferencia como certeza a veces se equivocará sin poder detectarlo. Si el requisito es fiabilidad y no una heurística, los datos de dirección no pueden aportarla, y un diseño que lo dice es más honesto que uno que oculta la conjetura.
| Prueba | Qué responde | Qué no puede mostrar |
|---|---|---|
| Marcador local de transporte | Si este objeto de red es una VPN | Quién opera la salida o dónde está el dispositivo |
| Dirección de origen remota | Qué dirección llegó al servicio | Si el dispositivo también lleva un túnel |
| Carga útil de la aplicación | Qué eligió enviar la aplicación | Todo lo que la aplicación no envió |
Por qué una salida autoalojada cambia solo un lado
Ejecutar su propio punto final cambia la dirección de origen que observa un servicio remoto, lo que puede moverla fuera de los rangos que ese servicio asocia con proveedores comerciales. No cambia nada en el modelo de red local, porque el túnel sigue siendo un túnel y el sistema operativo aún lo informa.
Un lado de la prueba se mueve; el otro permanece fijo. La brecha entre ambos es donde se rompen las expectativas.
Un navegador es un tercer caso con sus propias interfaces y restricciones. El contenido web no puede leer un objeto nativo de capacidades, y tratar una función del sistema operativo móvil como disponible para una página web es un error de categoría. Si la pregunta concierne a un sitio web, estudie qué puede obtener realmente un sitio web en lugar de transliterar una API de plataforma.
Decida con la pregunta que hace
Si la pregunta es si una aplicación concreta puede observar el estado del túnel, la interfaz de plataforma es el lugar correcto donde mirar, y la respuesta está en el código y los permisos de esa aplicación. Si la pregunta es qué puede inferir un servicio, los metadatos de conexión son la prueba. Una cuestión legal o contractual no la resuelve ninguno de los dos.
Nombre la pregunta en una frase antes de recoger nada. Esa frase decide qué punto de observación importa y evita que la investigación derive hacia otra discusión.
Etiquete cada observación según su fuente cuando la reporte, porque una afirmación sin etiqueta no se puede revisar. Un marcador local y una inferencia de dirección son ambos útiles y ninguno es concluyente, por eso fusionarlos en un solo veredicto es un error.
Cuando un servicio rechaza una conexión autorizada, use su vía de revisión admitida en lugar de cambiar un ajuste local para ocultar una señal. Eliminar una observación nunca demuestra que las demás hayan desaparecido.