Android OpenVPN: añadir una ruta privada sin rootear el teléfono

Necesitas una subred privada más —digamos 10.60.0.0/24— que el perfil no incluye ahora mismo. En un portátil añadirías una ruta y seguirías. En Android la VPN es una aplicación, el dispositivo tun pertenece a esa aplicación y no hay tabla de rutas que puedas editar sin root. La ruta tiene que existir igualmente, pero va dentro del perfil que carga el cliente, y solo funciona si el otro extremo está de acuerdo. Aquí están la edición, la reconexión, el lado del servidor y la reversión.

Antes de la edición: qué puede y qué no puede hacer una ruta

Una ruta responde a una pregunta: qué interfaz debe llevar el tráfico hacia este destino. No autoriza nada. Si el propietario de la red no ha aceptado que este teléfono pueda llegar a esa subred, una ruta correcta produce una configuración que parece correcta y un descarte silencioso en la puerta de enlace, y pasarás la hora siguiente editando el archivo equivocado.

Consigue ese acuerdo primero, por escrito si la red tiene un propietario. Luego anota lo que no estás haciendo: no asignas al teléfono una dirección dentro de esa LAN, no cambias el listener del servidor y no eliges un sitio por nombre de host. Son cuatro cambios distintos y solo el primero es tuyo.

Edita el perfil que el cliente carga de verdad

Para un cliente compatible que importa texto de opciones OpenVPN normal, la adición es una línea:

route 10.60.0.0 255.255.255.0

Añádela al cuerpo del perfil, cerca de las otras directivas de enrutamiento, y deja el endpoint, los certificados, el manejo de claves y las líneas de verificación del operador exactamente como estaban. No pegues un ejemplo antiguo entero para tomar prestada una línea: la compresión, las rutas de archivo absolutas y los ajustes de cifrado obsoletos viajan con él y te costarán una sesión de depuración aparte.

El paso que la gente se salta es la propiedad del archivo. Si la aplicación importó un perfil, la copia que usa es de la aplicación, y editar el original descargado no cambia nada. Usa el editor compatible del cliente, o vuelve a importar el archivo editado por la ruta de actualización, y confirma el nombre del perfil activo cuando existan varios nombres parecidos. Anota cuál cambiaste.

Si el perfil ya lleva route-nopull, no se instala ninguna ruta del servidor y cada prefijo que el teléfono necesita debe listarse explícitamente. Es un diseño legítimo, pero significa que una línea omitida se ve exactamente igual que una negativa del servidor.

Reconecta y verifica en el dispositivo

Desconecta primero y luego reconecta el perfil concreto que editaste, en lugar de dejar que la aplicación restaure la última sesión. Abre el registro de conexión y confirma que el cliente ha analizado la nueva línea; una directiva de ruta que el frontend ignora es un resultado habitual de editar la copia equivocada.

Prueba el destino por dirección, no por nombre. Una comprobación TCP a un puerto de servicio conocido informa más que un ping, porque muchos hosts responden a ICMP mientras el puerto de servicio está filtrado. Si la dirección responde y un nombre no, tienes una cuestión de resolver y no de enrutamiento, y la sección siguiente no es para ti.

Aquí también corresponden dos comprobaciones de alcance. El VPN por aplicación significa que puede haber una ruta de dirección mientras la aplicación con la que pruebas está fuera del conjunto incluido, así que prueba con una aplicación que esté realmente dentro. Y un prefijo IPv4 no dice nada sobre la ruta IPv6; si el servicio es dual-stack, añade la ruta IPv6 correspondiente o espera que el cliente prefiera una ruta que no pretendías.

Un resultado negativo conviene reconocerlo pronto: si una ruta de túnel completo ya cubre 0.0.0.0/0, el prefijo no falta y añadirlo otra vez no cambia nada. La cobertura duplicada no repara una denegación del servidor ni una respuesta ausente.

Termina el camino en el servidor

Tres cosas deben ser ciertas más allá del teléfono. La puerta de enlace necesita una ruta al destino y permiso para reenviar el origen del teléfono hacia él. El objetivo debe aceptar ese origen y devolver las respuestas por la puerta de enlace, o el diseño necesita una traducción deliberada en la salida. La opción route del manual de OpenVPN cubre la directiva del lado del cliente; el reenvío y el enrutamiento de retorno son ajustes separados en máquinas separadas.

Si el destino está detrás de otro cliente VPN en lugar de directamente detrás de la puerta de enlace, el servidor necesita una iroute para la subred de ese par. Esa directiva es propiedad del servidor y describe qué cliente posee un prefijo; un teléfono no puede aportarla desde su propio perfil, y ninguna cantidad de edición en el cliente la sustituye.

Comprueba el camino de retorno de forma explícita. Una respuesta que sale por la ruta por defecto en lugar del túnel produce el síntoma clásico de medio abierto: la conexión se establece en una dirección y no vuelve nada. La traducción de origen en la puerta de enlace es una corrección legítima cuando el objetivo no puede enrutar de vuelta, pero es una decisión de política con sus propias consecuencias.

Reversión y aceptación

Guarda el perfil anterior antes de editarlo. Si el cambio empeora las cosas, restaura esa copia por la misma ruta de reimportación, reconecta y confirma que vuelve el comportamiento antiguo: eso confirma que cambiaste lo que creías haber cambiado. Una reversión que no restaura el estado antiguo significa que la aplicación guarda una tercera copia que no has encontrado.

Acepta el cambio cuando se cumplan cuatro cosas, probadas en este orden tras una reconexión nueva: el destino responde en su puerto de servicio, el nombre privado resuelve si se espera uno, HTTPS sigue validando el nombre de host previsto y todo sigue funcionando tras un reinicio o un cambio de Wi-Fi a red móvil. La última comprobación es la que detecta una ruta que solo existe hasta que Android restablece el túnel.

• Confirma que el propietario de la red permite el destino antes de editar nada.
• Pon la ruta en el perfil que carga el cliente y luego reimporta y reconecta.
• Verifica por puerto de servicio, dentro del alcance por aplicación, para la familia de direcciones correcta.
• Corrige el reenvío, el enrutamiento de retorno y la iroute en el servidor, no en el teléfono.
• Guarda una copia de reversión y vuelve a probar tras un reinicio.