VPN siempre activa en Android: cómo se resuelve primero el nombre del extremo
Android bloquea el tráfico antes de que exista el túnel, pero el cliente igualmente debe resolver su extremo. Este es el orden y dónde se bloquea.
El teléfono se reinicia, la opción siempre activa está habilitada, el bloqueo de conexiones sin VPN está activado y el túnel nunca sube. Nada está mal configurado: el bloqueo hace su trabajo, y el intento del propio cliente de alcanzar su extremo también está sujeto a él. El extremo debe resolverse antes de que exista el túnel, por un cliente al que se le permite hablar con la red mientras a ninguna otra aplicación se le permite. Entender qué componente lo hace, y en qué orden, convierte el misterio en una pregunta de configuración.
Qué pide realmente el constructor de VPN
Una aplicación VPN de Android no entrega a la plataforma la dirección de un servidor. Construye una interfaz local: direcciones y rutas para el túnel, los resolutores que las aplicaciones deben usar dentro, y luego establish() devuelve un descriptor de archivo que la aplicación lee y escribe como paquetes IP crudos. El extremo remoto no aparece nunca en ese constructor.
Ese es el hecho estructural clave. La plataforma crea una interfaz tun e impone la política sobre ella; la aplicación implementa el transporte en espacio de usuario, es decir, ella misma resuelve el nombre de su extremo y abre la conexión cifrada. Un extremo con nombre de host es posible, no porque la plataforma admita nombres, sino porque la plataforma nunca ve el extremo.
Un campo del constructor sí acepta direcciones: los servidores DNS. Deben ser direcciones numéricas de resolutor, normalmente las que el operador quiere consultar a través del túnel. Ese campo describe dónde envían las aplicaciones sus consultas una vez que el túnel está arriba. No dice nada sobre cómo encuentra el cliente el extremo, y tratar ambos como la misma configuración es donde empieza la confusión.
Dos preguntas de DNS, no una
La primera pregunta es: dónde envían las aplicaciones sus consultas cuando el túnel está arriba? La respuesta es una dirección de resolutor dentro del túnel, accesible por la interfaz tun, numérica por construcción.
La segunda pregunta es: cómo encuentra el cliente su propio extremo antes de que exista ese túnel. Esa búsqueda ocurre fuera del túnel, en la red subyacente, en el proceso del cliente. Puede usar un nombre y debe usar un resolutor al que el dispositivo llegue sin la VPN.
| Etapa | Quién resuelve | Ruta | Cómo se ve el fallo |
|---|---|---|---|
| Búsqueda del extremo | La aplicación VPN | Red subyacente, socket protegido | Nunca conecta; sin tráfico en la interfaz tun |
| Autenticación del par | Cliente y servidor | Transporte del túnel | Conecta y cae; error de certificado o clave |
| Búsqueda de nombre privado | Aplicaciones por el túnel | Resolutor dentro del tun | Túnel arriba, los sitios internos no resuelven |
Tres etapas, tres síntomas distintos. Un solo mensaje de error como no se puede conectar las funde, y por eso la gente termina editando el campo del servidor DNS para arreglar un problema que ocurre antes de que ese campo se lea.
Por qué el arranque puede bloquearse
Siempre activa con el bloqueo habilitado significa que el tráfico que no está dentro de la VPN se descarta, incluido el de la aplicación que posee la VPN. La salida es explícita: la aplicación llama a protect() sobre un socket, lo que lo vincula a la red subyacente para que evite el túnel y se le deje salir. Todo cliente VPN debe hacerlo con su propio transporte, o nunca podría alcanzar un servidor.
Piense ahora en un despliegue donde el único resolutor que conoce el nombre del extremo está dentro del túnel. El cliente necesita el túnel para resolver el nombre, y el nombre para construir el túnel. Es una dependencia circular real, y ninguna configuración del cliente la resuelve. Es un error de diseño, no un fallo del programa.
El momento expone la misma dependencia en formas más suaves. Al arrancar antes del primer desbloqueo, el dispositivo puede no tener todavía una red utilizable; en un portal cautivo la red existe pero bloquea todo salvo el portal; en un traspaso de Wi-Fi a móvil cambia la red subyacente del socket protegido y el cliente debe notarlo y volver a resolver. Cada uno es un evento de arranque y merece una prueba deliberada en lugar de descubrirse a las 3 de la madrugada.
Por qué fijar la respuesta no es una solución
El atajo tentador es resolver el nombre una vez y pegar la dirección resultante en un campo numérico, o codificarla en una compilación propia. Parece funcionar, y convierte un nombre en una instantánea. Cuando el operador mueve el extremo, por migración, un cambio de anycast o una nueva dirección regional, el cliente sigue marcando la vieja y nada en la interfaz explica por qué.
Los registros DNS llevan un tiempo de vida precisamente para que las respuestas puedan cambiar; el almacenamiento en caché se define por esa vida, no para siempre. Fijar una respuesta descarta el mecanismo que hace que un nombre sea mejor que una dirección, mientras conserva el costo operativo de haber usado un nombre.
Fijar la respuesta también suele ir con un segundo mal hábito: relajar las comprobaciones de identidad porque ahora la conexión falla de otra manera. La verificación de la identidad del servidor no forma parte del problema de arranque, y debilitarla cambia una molestia de DNS por un riesgo de interceptación.
Diseños que sobreviven a un reinicio
La disposición duradera no tiene nada de espectacular. Use un cliente que implemente bien los sockets protegidos y resuelva su extremo en la red subyacente, y dele un nombre de extremo que resuelva públicamente o mediante un resolutor accesible antes del túnel. Deje el bloqueo activado; desactivarlo por completo para que el DNS funcione elimina la propiedad por la que existe el despliegue.
Donde el extremo debe seguir siendo privado, proporcione una ruta de arranque explícita que la plataforma pueda usar, como un resolutor accesible sin el túnel o una conexión de gestión mantenida por el operador, y mantenga esa excepción estrecha y gobernada por política en lugar de por un interruptor de usuario. La documentación de Android VpnService es la referencia sobre lo que la plataforma garantiza en protección y ciclo de vida, y la referencia de VpnService.Builder confirma que el campo DNS acepta direcciones numéricas.
Después verifique en las tres etapas, en orden, en una conexión nueva tras un reinicio: el nombre del extremo resuelve, el túnel se establece y el par se autentica, y un nombre privado resuelve por el resolutor del túnel. Si la primera etapa falla, nada posterior puede funcionar.
- La resolución del extremo ocurre en la aplicación, fuera del túnel, en un socket protegido.
- El campo DNS del constructor es para las aplicaciones dentro del túnel, no para el extremo propio del cliente.
- Un resolutor accesible solo por el túnel es un bloqueo, no un arranque lento.
- Pruebe el extremo, la autenticación y la búsqueda privada por separado tras un reinicio.