VPN sempre activa a Android: com es resol primer el nom de l’extrem
Android bloqueja el trànsit abans que existeixi el túnel, però el client igualment ha de resoldre el seu extrem. Aquí hi ha l’ordre i on s’encalla.
El telèfon es reinicia, la opció sempre activa està habilitada, el bloqueig de connexions sense VPN està activat i el túnel no s’aixeca mai. No hi ha res mal configurat: el bloqueig fa la seva feina i l’intent del client d’arribar al seu extrem també hi està subjecte. Cal resoldre l’extrem abans que existeixi el túnel, per part d’un client a qui es permet parlar amb la xarxa mentre a cap altra aplicació no se li permet. Entendre quina peça ho fa i en quin ordre converteix això d’un misteri en una pregunta de configuració.
Què demana realment el constructor de VPN
Una aplicació VPN d’Android no lliura al sistema una adreça de servidor. Construeix una interfície local: adreces i rutes per al túnel, els resoledors que les aplicacions han d’utilitzar a dins, i després establish() retorna un descriptor de fitxer que l’aplicació llegeix i escriu com a paquets IP crus. L’extrem remot no apareix mai en aquest constructor.
Aquest és el fet estructural clau. La plataforma crea una interfície tun i hi aplica la política; l’aplicació implementa el transport en espai d’usuari, és a dir, és ella mateixa qui resol el nom del seu extrem i obre la connexió xifrada. Per tant, un extrem amb nom d’amfitrió és possible, no perquè la plataforma admeti noms, sinó perquè la plataforma no veu mai l’extrem.
Un camp del constructor sí que pren adreces: els servidors DNS. Han de ser adreces numèriques de resoledor, normalment les que l’operador vol que es consultin a través del túnel. Aquest camp descriu on envien les aplicacions les consultes un cop el túnel està aixecat. No diu res sobre com troba el client el seu extrem, i tractar les dues coses com la mateixa configuració és on comença la confusió.
Dues preguntes DNS, no una
La primera pregunta és: on envien les aplicacions les consultes quan el túnel està aixecat? La resposta és una adreça de resoledor dins del túnel, abastable per la interfície tun, numèrica per construcció.
La segona pregunta és: com troba el client el seu propi extrem abans que aquest túnel existeixi? Aquesta cerca passa fora del túnel, a la xarxa subjacent, dins del procés del client. Pot utilitzar un nom i ha d’utilitzar un resoledor al qual el dispositiu arribi sense la VPN.
| Etapa | Qui resol | Camí | Com es veu el fracàs |
|---|---|---|---|
| Cerca de l’extrem | L’aplicació VPN | Xarxa subjacent, sòcol protegit | No connecta mai; cap trànsit a la interfície tun |
| Autenticació del parell | Client i servidor | Transport del túnel | Connecta i cau; error de certificat o clau |
| Cerca de nom privat | Aplicacions pel túnel | Resoledor dins del tun | Túnel aixecat, els llocs interns no es resolen |
Tres etapes, tres símptomes diferents. Un sol missatge d’error com no es pot connectar les ajunta, i per això la gent acaba editant el camp del servidor DNS per arreglar un problema que passa abans que aquell camp es llegeixi.
Per què l’arrencada es pot encallar
Sempre activa amb el bloqueig habilitat vol dir que es descarta el trànsit que no és dins de la VPN, inclòs el de l’aplicació que posseeix la VPN. La sortida és explícita: l’aplicació crida protect() sobre un sòcol, cosa que el lliga a la xarxa subjacent perquè salti el túnel i se’l deixi sortir. Cada client VPN ho ha de fer pel seu propi transport, o no arribaria mai a cap servidor.
Penseu ara en un desplegament on l’únic resoledor que coneix el nom de l’extrem és dins del túnel. El client necessita el túnel per resoldre el nom, i el nom per construir el túnel. És una dependència circular real, i cap configuració del client la resol. És un error de disseny, no un error de programari.
El moment ho exposa en formes més suaus. En arrencar abans del primer desbloqueig, el dispositiu pot no tenir encara xarxa útil; en un portal captiu la xarxa existeix però bloqueja tot excepte el portal; en un canvi de Wi-Fi a mòbil, la xarxa subjacent del sòcol protegit canvia i el client ho ha de notar i tornar a resoldre. Cadascun és un esdeveniment d’arrencada i val la pena provar-lo expressament en lloc de descobrir-lo a les 3 de la matinada.
Per què fixar la resposta no és cap solució
La drecera temptadora és resoldre el nom un cop i enganxar l’adreça resultant en un camp numèric, o codificar-la en una compilació pròpia. Sembla que funcioni, i converteix un nom en una instantània. Quan l’operador mou l’extrem, per migració, un canvi d’anycast o una adreça regional nova, el client continua marcant la vella i res a la interfície n’explica el motiu.
Els registres DNS porten un temps de vida precisament perquè les respostes puguin canviar; la memòria cau es defineix per aquesta vida, no per sempre. Fixar una resposta llença el mecanisme que fa que un nom sigui millor que una adreça, mentre conserva el cost operatiu d’haver utilitzat un nom.
Fixar-la també sol anar amb un segon mal hàbit: relaxar les comprovacions d’identitat perquè ara la connexió falla d’una altra manera. La verificació de la identitat del servidor no forma part del problema d’arrencada, i afeblir-la canvia un inconvenient de DNS per un risc d’intercepció.
Dissenys que sobreviuen a un reinici
La disposició duradora no té res d’espectacular. Feu servir un client que implementi bé els sòcols protegits i resolgui el seu extrem a la xarxa subjacent, i doneu-li un nom d’extrem que es resolgui públicament o mitjançant un resoledor abastable abans del túnel. Deixeu el bloqueig activat; desactivar-lo del tot perquè el DNS funcioni elimina la propietat per la qual existeix el desplegament.
On l’extrem ha de romandre privat, proporcioneu un camí d’arrencada explícit que la plataforma pugui utilitzar, com un resoledor abastable sense el túnel o una connexió de gestió mantinguda per l’operador, i manteniu aquesta excepció estreta i governada per política en lloc de per un interruptor d’usuari. La documentació d’Android VpnService és la referència del que la plataforma garanteix sobre protecció i cicle de vida, i la referència de VpnService.Builder confirma que el camp DNS pren adreces numèriques.
Després verifiqueu en les tres etapes, en ordre, en una connexió nova després d’un reinici: el nom de l’extrem es resol, el túnel s’estableix i el parell s’autentica, i un nom privat es resol pel resoledor del túnel. Si la primera etapa falla, res posterior pot funcionar, i la correcció pertany al camí d’arrencada, mai al camp del resoledor.
- La resolució de l’extrem passa a l’aplicació, fora del túnel, en un sòcol protegit.
- El camp DNS del constructor és per a les aplicacions dins del túnel, no per a l’extrem propi del client.
- Un resoledor abastable només pel túnel és un bloqueig, no un inici lent.
- Proveu l’extrem, l’autenticació i la cerca privada per separat després d’un reinici.