Servidor VPN en Android: root no hace que el teléfono sea accesible
Tres problemas distintos deciden si un teléfono puede atender clientes VPN: la ruta de entrada, el modelo de privilegios y el reenvío. Root solo toca el del medio.
Root cambia qué operaciones de red puede intentar un proceso. No le da al teléfono una dirección accesible públicamente, no reserva un mapeo entrante en el operador ni mantiene vivo un demonio tras un reinicio. Si estás decidiendo si un teléfono Android puede actuar como servidor VPN, separa tres preguntas: ¿puede el cliente previsto llegar al escucha, qué modelo de privilegios necesita la implementación del servidor y qué hay que reenviar cuando el túnel ya está levantado?
Quién tiene que llegar al teléfono, y desde dónde
Un cliente en la misma LAN permitida y un cliente con datos móviles prueban dos redes distintas. Resuelve primero la prevista, porque las respuestas no se trasladan. En Wi-Fi, el tráfico entrante no solicitado suele necesitar un mapeo en el router superior y una ruta pública utilizable más allá. En la red celular, el NAT de nivel de operador hace que la IPv4 entrante con frecuencia no esté disponible, haga lo que haga el teléfono.
Ese último punto es el que root no puede tocar. El cortafuegos local del teléfono y el NAT del operador son sistemas distintos, y cambiar el primero no tiene efecto sobre el segundo. Una dirección de interfaz privada, un icono de datos móviles o un socket a la escucha no son prueba de accesibilidad. Si la ruta del operador sí ofrece IPv6 enrutable globalmente, aún necesitas una política deliberada de escucha y de cortafuegos para ella; tener una dirección no es lo mismo que aceptar conexiones.
| 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 y reenviar son dos éxitos distintos
Un handshake VPN completado demuestra que el túnel existe. No demuestra que el cliente pueda llegar a una LAN detrás del teléfono, ni que el teléfono pueda actuar como salida a internet. Son configuraciones separadas construidas sobre el plan de direcciones interno, las rutas, el comportamiento de retorno y una política de reenvío estrecha para la tarea que realmente quieres.
El modo de fallo es previsible: el handshake tiene éxito, el cliente muestra conectado y no carga nada. Antes de depurar el cliente, decide cuál de los dos roles estás construyendo. El acceso remoto a un dispositivo en la red del teléfono y la salida a internet por túnel completo necesitan reglas de reenvío distintas, y conceder ambas cuando querías una amplía la exposición sin añadir la capacidad que pediste.
El modelo de privilegios es una elección, no root o nada
Un demonio OpenVPN convencional que usa un dispositivo TUN del núcleo necesita las capacidades correspondientes, acceso al nodo del dispositivo y la cooperación de la política de seguridad de Android. Root no es una exención general de SELinux; un proceso privilegiado sigue limitado por la política de la plataforma. Por eso un binario que funciona sin problemas en un servidor Linux puede fallar en un teléfono sin un error evidente sobre permisos.
Una implementación de puerta de enlace en espacio de usuario puede tener un modelo de privilegios completamente distinto, así que la afirmación común de que todo servidor VPN en Android necesita root es demasiado amplia. Lo que root te compra es la capacidad de intentar más operaciones, no la garantía de que se permitan ni de que el resultado sea accesible.
El propio registro del servicio VPN de Android es otro mecanismo aparte. Da a una aplicación una interfaz de cliente gestionada con un ciclo de vida definido; no es un instalador general de servidores, y arrancar un demonio desde una terminal no le da gestión permanente, política por aplicación ni una ruta de recuperación propia.
Si quieres un punto de salida, cambia la arquitectura
Cuando el objetivo es simplemente una salida remota a internet a través del teléfono en vez de compatibilidad con un perfil OpenVPN existente, un nodo de salida admitido en una red superpuesta es el diseño más adecuado. Tailscale documenta un rol de nodo de salida para Android con sus propios pasos de registro, autorización y selección de cliente.
El intercambio es real y merece decirse claro: aceptas otro protocolo, otro modelo de confianza y una dependencia de esa cuenta y servicio de coordinación. No hace que un cliente OpenVPN sin modificar se una a la red superpuesta, ni te da un escucha OpenVPN en una dirección pública.
Qué necesita todavía el despliegue
Elijas la ruta que elijas, lo básico operativo decide si sobrevive una semana. Mantén privadas las credenciales del servidor, emite identidades de cliente distintas y planifica la revocación antes de necesitarla. Decide cómo llegan las actualizaciones, qué mantiene el servicio en marcha en segundo plano y cómo se recupera tras un reinicio o un cambio de red.
Evita los atajos que parecen cómodos: un binario estático obsoleto, nombres de interfaz codificados a mano y un script de arranque que vacía la política de cortafuegos existente. Luego acepta el resultado solo ante una prueba concreta: un cliente remoto autorizado llega al recurso previsto, los destinos prohibidos siguen no disponibles y el dispositivo vuelve por sí solo tras el evento de ciclo de vida admitido. El acceso root es un ingrediente posible de ese resultado, y rara vez el decisivo.