Servidor VPN en Android: root non fai que o teléfono sexa accesible
Tres problemas distintos deciden se un teléfono pode atender clientes VPN: a ruta de entrada, o modelo de privilexios e o reenvío. Root só toca o do medio.
Root cambia que operacións de rede pode tentar un proceso. Non lle dá ao teléfono un enderezo accesible publicamente, non reserva unha asignación entrante no operador nin mantén vivo un demonio tras un reinicio. Se estás a decidir se un teléfono Android pode actuar como servidor VPN, separa tres preguntas: pode o cliente previsto chegar ao escoitador, que modelo de privilexios necesita a implementación do servidor e que hai que reenviar cando o túnel xa está levantado?
Quen ten que chegar ao teléfono, e desde onde
Un cliente na mesma LAN permitida e un cliente con datos móbiles proban dúas redes distintas. Resolve primeiro a prevista, porque as respostas non se trasladan. En Wi-Fi, o tráfico entrante non solicitado adoita necesitar unha asignación no router superior e unha ruta pública utilizábel máis aló. Na rede celular, o NAT de nivel de operador fai que a IPv4 entrante frecuentemente non estea dispoñible, faga o que faga o teléfono.
Ese último punto é o que root non pode tocar. A devasa local do teléfono e o NAT do operador son sistemas distintos, e cambiar o primeiro non ten efecto sobre o segundo. Un enderezo de interface privado, unha icona de datos móbiles ou un socket á escoita non son proba de accesibilidade. Se a ruta do operador si ofrece IPv6 encamiñábel globalmente, aínda necesitas unha política deliberada de escoita e de devasa para ela; ter un enderezo non é o mesmo que aceptar conexións.
| 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 e reenviar son dous éxitos distintos
Un handshake VPN completado demostra que o túnel existe. Non demostra que o cliente poida chegar a unha LAN detrás do teléfono, nin que o teléfono poida actuar como saída a internet. Son configuracións separadas construídas sobre o plano de enderezos interno, as rutas, o comportamento de retorno e unha política de reenvío estreita para a tarefa que realmente queres.
O modo de fallo é previsible: o handshake ten éxito, o cliente mostra conectado e non se carga nada. Antes de depurar o cliente, decide cal dos dous papeis estás a construír. O acceso remoto a un dispositivo na rede do teléfono e a saída a internet por túnel completo necesitan regras de reenvío distintas, e conceder ambas cando querías unha amplía a exposición sen engadir a capacidade que pediches.
O modelo de privilexios é unha elección, non root ou nada
Un demonio OpenVPN convencional que usa un dispositivo TUN do núcleo necesita as capacidades correspondentes, acceso ao nodo do dispositivo e a cooperación da política de seguridade de Android. Root non é unha exención xeral de SELinux; un proceso privilexiado segue limitado pola política da plataforma. Por iso un binario que funciona sen problemas nun servidor Linux pode fallar nun teléfono sen un erro evidente sobre permisos.
Unha implementación de pasarela en espazo de usuario pode ter un modelo de privilexios completamente distinto, así que a afirmación común de que todo servidor VPN en Android necesita root é demasiado ampla. O que root che compra é a capacidade de tentar máis operacións, non a garantía de que se permitan nin de que o resultado sexa accesible.
O propio rexistro do servizo VPN de Android é outro mecanismo á parte. Dá a unha aplicación unha interface de cliente xestionada cun ciclo de vida definido; non é un instalador xeral de servidores, e iniciar un demonio desde un terminal non lle dá xestión permanente, política por aplicación nin unha ruta de recuperación propia.
Se queres un punto de saída, cambia a arquitectura
Cando o obxectivo é simplemente unha saída remota a internet a través do teléfono en vez de compatibilidade cun perfil OpenVPN existente, un nodo de saída admitido nunha rede superposta é o deseño máis axeitado. Tailscale documenta un papel de nodo de saída para Android cos seus propios pasos de rexistro, autorización e selección de cliente.
O intercambio é real e merece dicirse claro: aceptas outro protocolo, outro modelo de confianza e unha dependencia desa conta e servizo de coordinación. Non fai que un cliente OpenVPN sen modificar se una á rede superposta, nin che dá un escoitador OpenVPN nun enderezo público.
Que necesita aínda o despregamento
Escollas a ruta que escollas, o básico operativo decide se sobrevive unha semana. Mantén privadas as credenciais do servidor, emite identidades de cliente distintas e planifica a revocación antes de necesitala. Decide como chegan as actualizacións, que mantén o servizo en marcha en segundo plano e como se recupera tras un reinicio ou un cambio de rede.
Evita os atallos que parecen cómodos: un binario estático obsoleto, nomes de interface codificados a man e un script de arranque que baleira a política de devasa existente. Despois acepta o resultado só ante unha proba concreta: un cliente remoto autorizado chega ao recurso previsto, os destinos prohibidos seguen non dispoñibles e o dispositivo volve por si só tras o evento de ciclo de vida admitido. O acceso root é un ingrediente posible dese resultado, e raramente o decisivo.