VPN sempre activa en Android: como se resolve primeiro o nome do extremo
Android bloquea o tráfico antes de que exista o túnel, pero o cliente ten que resolver o seu extremo igualmente. Aquí está a orde e onde se bloquea.
O teléfono reiníciase, a opción sempre activa está habilitada, o bloqueo de conexións sen VPN está activado e o túnel nunca sobe. Nada está mal configurado: o bloqueo fai o seu traballo, e o intento do propio cliente de acadar o seu extremo tamén está suxeito a el. O extremo debe resolverse antes de que exista o túnel, por un cliente ao que se lle permite falar coa rede mentres a ningunha outra aplicación se lle permite. Entender que compoñente o fai, e en que orde, converte o misterio nunha pregunta de configuración.
Que pide realmente o construtor de VPN
Unha aplicación VPN de Android non entrega á plataforma o enderezo dun servidor. Constrúe unha interface local: enderezos e rutas para o túnel, os resolutores que as aplicacións deben usar dentro, e despois establish() devolve un descritor de ficheiro que a aplicación le e escribe como paquetes IP crus. O extremo remoto non aparece nunca nese construtor.
Ese é o feito estrutural clave. A plataforma crea unha interface tun e impón a política sobre ela; a aplicación implementa o transporte en espazo de usuario, é dicir, ela mesma resolve o nome do seu extremo e abre a conexión cifrada. Un extremo con nome de host é posible, non porque a plataforma admita nomes, senón porque a plataforma nunca ve o extremo.
Un campo do construtor si acepta enderezos: os servidores DNS. Deben ser enderezos numéricos de resolutor, normalmente os que o operador quere consultar a través do túnel. Ese campo describe onde envían as aplicacións as súas consultas unha vez que o túnel está arriba. Non di nada sobre como atopa o cliente o extremo, e tratar ambos como a mesma configuración é onde comeza a confusión.
Dúas preguntas de DNS, non unha
A primeira pregunta é: onde envían as aplicacións as súas consultas cando o túnel está arriba? A resposta é un enderezo de resolutor dentro do túnel, accesible pola interface tun, numérico por construción.
A segunda pregunta é: como atopa o cliente o seu propio extremo antes de que exista ese túnel? Esa busca ocorre fóra do túnel, na rede subxacente, no proceso do cliente. Pode usar un nome e debe usar un resolutor ao que o dispositivo chegue sen a VPN.
| Etapa | Quen resolve | Ruta | Como se ve o fallo |
|---|---|---|---|
| Busca do extremo | A aplicación VPN | Rede subxacente, socket protexido | Nunca conecta; sen tráfico na interface tun |
| Autenticación do par | Cliente e servidor | Transporte do túnel | Conecta e cae; erro de certificado ou clave |
| Busca de nome privado | Aplicacións polo túnel | Resolutor dentro do tun | Túnel arriba, os sitios internos non resolven |
Tres etapas, tres síntomas distintos. Unha soa mensaxe de erro como non se pode conectar xúntaas, e por iso a xente acaba editando o campo do servidor DNS para arranxar un problema que ocorre antes de que ese campo se lea.
Por que o arranque pode bloquearse
Sempre activa co bloqueo habilitado significa que o tráfico que non está dentro da VPN se descarta, incluído o da aplicación que posúe a VPN. A saída é explícita: a aplicación chama a protect() sobre un socket, o que o vincula á rede subxacente para que evite o túnel e se lle deixe saír. Todo cliente VPN debe facelo co seu propio transporte, ou nunca podería acadar un servidor.
Pense agora nun despregamento onde o único resolutor que coñece o nome do extremo está dentro do túnel. O cliente necesita o túnel para resolver o nome, e o nome para construír o túnel. É unha dependencia circular real, e ningunha configuración do cliente a resolve. É un erro de deseño, non un fallo do programa.
O momento expón a mesma dependencia en formas máis suaves. Ao arrancar antes do primeiro desbloqueo, o dispositivo pode non ter aínda unha rede utilizábel; nun portal cativo a rede existe pero bloquea todo agás o portal; nun traspaso de Wi-Fi a móbil cambia a rede subxacente do socket protexido e o cliente debe notalo e volver resolver. Cada un é un evento de arranque e merece unha proba deliberada en lugar de descubrirse ás 3 da madrugada.
Por que fixar a resposta non é unha solución
O atallo tentador é resolver o nome unha vez e pegar o enderezo resultante nun campo numérico, ou codificalo nunha compilación propia. Parece funcionar, e converte un nome nunha instantánea. Cando o operador move o extremo, por migración, un cambio de anycast ou un novo enderezo rexional, o cliente segue marcando o vello e nada na interface explica por que.
Os rexistros DNS levan un tempo de vida precisamente para que as respostas poidan cambiar; a caché defínese por esa vida, non para sempre. Fixar unha resposta descarta o mecanismo que fai que un nome sexa mellor ca un enderezo, mentres conserva o custo operativo de ter usado un nome.
Fixar a resposta tamén adoita ir cun segundo mal hábito: relaxar as comprobacións de identidade porque agora a conexión falla doutro xeito. A verificación da identidade do servidor non forma parte do problema de arranque, e debilitada cambia unha molestia de DNS por un risco de interceptación.
Deseños que sobreviven a un reinicio
A disposición duradeira non ten nada de espectacular. Use un cliente que implemente ben os sockets protexidos e resolva o seu extremo na rede subxacente, e déalle un nome de extremo que resolva publicamente ou mediante un resolutor accesible antes do túnel. Deixe o bloqueo activado; desactivalo por completo para que o DNS funcione elimina a propiedade pola que existe o despregamento.
Onde o extremo debe seguir sendo privado, proporcione unha ruta de arranque explícita que a plataforma poida usar, como un resolutor accesible sen o túnel ou unha conexión de xestión mantida polo operador, e manteña esa excepción estreita e gobernada por política en lugar de por un interruptor de usuario. A documentación de Android VpnService é a referencia sobre o que a plataforma garante en protección e ciclo de vida, e a referencia de VpnService.Builder confirma que o campo DNS acepta enderezos numéricos.
Despois verifique nas tres etapas, en orde, nunha conexión nova tras un reinicio: o nome do extremo resolve, o túnel establécese e o par autentícase, e un nome privado resolve polo resolutor do túnel. Se a primeira etapa falla, nada posterior pode funcionar.
- A resolución do extremo ocorre na aplicación, fóra do túnel, nun socket protexido.
- O campo DNS do construtor é para as aplicacións dentro do túnel, non para o extremo propio do cliente.
- Un resolutor accesible só polo túnel é un bloqueo, non un arranque lento.
- Probe o extremo, a autenticación e a busca privada por separado tras un reinicio.