Servidor VPN a Android: root no fa que el telèfon sigui abastable
Tres problemes separats decideixen si un telèfon pot servir clients VPN: el camí d'entrada, el model de privilegis i l'encaminament. Root només toca el del mig.
Root canvia quines operacions de xarxa pot intentar un procés. No dona al telèfon una adreça abastable públicament, no reserva un mapatge d'entrada al proveïdor i no manté un dimoni viu després d'un reinici. Si decidiu si un telèfon Android pot fer de servidor VPN, separeu tres preguntes: pot el client previst arribar a l'oient, quin model de privilegis necessita la implementació del servidor i què cal encaminar quan el túnel ja és actiu.
Qui ha d'arribar al telèfon i des d'on
Un client a la mateixa LAN permesa i un client amb dades mòbils proven dues xarxes diferents. Decidiu primer quina és la prevista, perquè les respostes no es traslladen. A Wi-Fi, el trànsit d'entrada no sol·licitat normalment necessita un mapatge al router superior i un camí públic utilitzable més enllà. A la xarxa cel·lular, el NAT de nivell d'operador fa que l'IPv4 d'entrada sovint no estigui disponible, faci el que faci el telèfon.
Aquest darrer punt és el que root no pot tocar. El tallafoc local del telèfon i el NAT de l'operador són sistemes diferents, i canviar el primer no afecta el segon. Una adreça d'interfície privada, una icona de dades mòbils o un sòcol que escolta no són proves d'abastabilitat. Si el camí de l'operador ofereix IPv6 enrutables globalment, encara necessiteu una política deliberada d'oient i de tallafoc; tenir una adreça no és el mateix que acceptar connexions.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
Servir i encaminar són dos èxits diferents
Un handshake VPN complet prova que el túnel existeix. No prova que el client pugui arribar a una LAN darrere del telèfon, ni que el telèfon pugui fer de sortida a internet. Són configuracions separades construïdes sobre el pla d'adreces intern, les rutes, el comportament de retorn i una política d'encaminament estreta per a la tasca que realment voleu.
El mode de fallada és previsible: l'handshake té èxit, el client mostra connectat i no es carrega res. Abans de depurar el client, decidiu quina de les dues funcions esteu construint. L'accés remot a un dispositiu de la xarxa del telèfon i la sortida a internet per túnel complet necessiten regles d'encaminament diferents, i concedir les dues quan volíeu una amplia l'exposició sense afegir la capacitat que vau demanar.
El model de privilegis és una elecció, no root o res
Un dimoni OpenVPN convencional que utilitza un dispositiu TUN del nucli necessita les capacitats corresponents, accés al node del dispositiu i la cooperació de la política de seguretat d'Android. Root no és una exempció general de SELinux; un procés privilegiat continua limitat per la política de la plataforma. Per això un binari que funciona bé en un servidor Linux pot fallar en un telèfon sense cap error evident sobre permisos.
Una implementació de passarel·la en espai d'usuari pot tenir un model de privilegis completament diferent, així que l'afirmació habitual que tot servidor VPN a Android necessita root és massa àmplia. Root us dona la capacitat d'intentar més operacions, no la garantia que es permetin ni que el resultat sigui abastable.
El registre del servei VPN propi d'Android és encara un altre mecanisme. Dona a una aplicació una interfície de client gestionada amb un cicle de vida definit; no és un instal·lador general de servidors, i iniciar un dimoni des d'un terminal no li dona gestió permanent, política per aplicació ni un camí de recuperació propi.
Si voleu un punt de sortida, canvieu l'arquitectura
Quan l'objectiu és simplement una sortida remota a internet a través del telèfon i no la compatibilitat amb un perfil OpenVPN existent, un node de sortida recolzat en una xarxa superposada és el disseny més adequat. Tailscale documenta un rol de node de sortida per a Android amb els seus propis passos de registre, autorització i selecció de client.
L'intercanvi és real i val la pena dir-lo clarament: accepteu un protocol diferent, un model de confiança diferent i una dependència d'aquell compte i servei de coordinació. No fa que un client OpenVPN sense modificar s'uneixi a la xarxa superposada ni us dona un oient OpenVPN en una adreça pública.
Què necessita encara el desplegament
Prengueu la ruta que prengueu, les bases operatives decideixen si sobreviu una setmana. Manteniu privades les credencials del servidor, emetiu identitats de client diferents i planifiqueu la revocació abans de necessitar-la. Decidiu com arriben les actualitzacions, què manté el servei en marxa en segon pla i com es recupera després d'un reinici o d'un canvi de xarxa.
Eviteu les dreceres que semblen còmodes: un binari estàtic obsolet, noms d'interfície codificats a mà i un script d'inici que esborra la política de tallafoc existent. Després accepteu el resultat només amb una prova concreta: un client remot autoritzat arriba al recurs previst, les destinacions prohibides segueixen no disponibles i el dispositiu torna sol després de l'esdeveniment de cicle de vida admès. L'accés root és un ingredient possible d'aquest resultat, i poques vegades el decisiu.