OpenVPN en Android no añade una ruta sin dirección de túnel

Su perfil de OpenVPN en Android no añade una ruta porque el teléfono no tiene ninguna dirección en la interfaz virtual, así que no hay nada hacia lo que una ruta pueda apuntar. Las rutas solo responden a dónde deben ir los paquetes. La dirección de túnel responde quién es el teléfono dentro del túnel, y el cliente debe aportar una antes de que la interfaz pueda existir. Recorra las cuatro comprobaciones siguientes en orden y deténgase en el primer fallo, porque editar rutas antes de que exista la dirección oculta el problema real.

Lea el fallo en el orden en que lo ejecuta el cliente

El VpnService.Builder de Android mantiene separados ambos conceptos: addAddress() pone una dirección en la interfaz que construye la aplicación, addRoute() añade un prefijo de destino y establish() se niega a crear la interfaz hasta que se ha añadido al menos una dirección. Un cliente OpenVPN asigna el perfil y las opciones que empuja el servidor exactamente a esas llamadas, así que una conexión que nunca analiza una dirección no puede construir la interfaz en absoluto.

Por eso la línea de registro que está leyendo puede nombrar una ruta mientras la causa está un paso antes. El cliente solo llega a la fase de ruta después de que exista la interfaz; sin dirección, la llamada de ruta falla de inmediato o nunca se ejecuta. Cuando el registro dice que no puede añadir una ruta, empiece por la dirección y no por la sintaxis de la ruta.

Comprobación 1: ¿el servidor pone una dirección en la respuesta?

En un servicio OpenVPN enrutado la dirección procede del grupo del servidor o de una asignación por cliente, y la topología decide qué forma tiene. En un servidor OpenVPN 2.4 o posterior, un servicio con topología de subred tiene este aspecto:

topology subnet
server 10.8.0.0 255.255.255.0
client-config-dir ccd

Con esa forma el servidor empuja algo como ifconfig 10.8.0.6 255.255.255.0. Un despliegue anterior con topology net30 empuja en cambio una dirección de par, por ejemplo ifconfig 10.8.0.6 10.8.0.5, así que un perfil trasladado entre ambos modelos puede parecer correcto mientras lleva la máscara de red equivocada.

Busque en el registro de conexión del cliente el conjunto de opciones empujadas. Si no contiene ninguna línea ifconfig, el servidor nunca envió una dirección o el cliente rechazó la opción. En un servidor que usa client-config-dir, el archivo nombrado según el nombre común del certificado debe existir y llevar la asignación:

# ccd/phone-anna
ifconfig-push 10.8.0.6 255.255.255.0

Comprobación 2: ¿el cliente conserva la dirección que recibió?

Un filtro demasiado amplio es la segunda causa habitual. pull-filter existe en OpenVPN 2.4 y posteriores, y cuando varios filtros coinciden con la misma opción gana el último que coincide, así que un catch-all final elimina la dirección sin error:

# removes every pushed option, including the address
pull-filter ignore "ifconfig"
pull-filter ignore "route"

Estreche el filtro a la opción que realmente quiere eliminar y deje la dirección en paz:

# keeps the pushed address, drops one unwanted LAN route
pull-filter ignore "route 10.60.0.0"

El consejo de desactivar todos los pull suele venir de alguien que intenta quitarse de encima una sola ruta. route-nopull es el interruptor más estrecho: conserva ifconfig y las demás opciones empujadas mientras rechaza las rutas empujadas y las opciones de tipo DHCP. Úselo cuando eso sea de verdad lo que quiere, y responda la cuestión de la dirección por separado.

Comprobación 3: ¿la dirección es suya para escribirla?

El direccionamiento manual solo es legítimo cuando el operador le entrega el valor. Si escribe una usted mismo, tiene que venir de la subred del cliente VPN, ser única entre las sesiones activas y coincidir con la topología que ejecuta el servidor. Copiar la dirección de un puente de escritorio o de un equipo de la LAN remota falla por ambos motivos: el teléfono reclamaría una dirección que ya existe en otro sitio, y la puerta de enlace no tendría ruta de vuelta hacia ella.

El prefijo de la LAN remota en una ruta es un destino, nunca la identidad del teléfono. Una ruta para 10.60.0.0/24 dice llegue a esa red por el túnel; no dice nada sobre qué dirección 10.60.0.x debería tener el teléfono, y el teléfono no debería tener ninguna de ellas. Las asignaciones estáticas pertenecen al lado del servidor, donde no pueden chocar con el grupo dinámico.

Dos sesiones con una misma identidad exponen la misma colisión. Si el mismo certificado se conecta dos veces y el servidor empuja una dirección fija a ambas, la segunda sesión duplica la primera, y la solución son identidades distintas o asignaciones distintas en lugar de una edición en el cliente.

Comprobación 4: ¿algo más ocupa la ranura del túnel?

Android permite un solo servicio VPN activo a la vez. Otra aplicación VPN, o una entrada de VPN siempre activa dejada habilitada para un perfil que ya no funciona, puede ocupar esa ranura antes de que su cliente OpenVPN llame a establish(). Entonces la interfaz nunca aparece aunque el perfil sea válido, así que desconecte la otra VPN, desactive el ajuste de siempre activa y vuelva a conectarse antes de tocar el perfil.

Un servicio que exige puente Ethernet es el otro callejón sin salida. Una aplicación Android sin root puede crear un túnel IP, no un segmento Ethernet puenteado, así que ninguna dirección que escriba hará funcionar un servidor dev tap; el operador tiene que ofrecer un servicio enrutado. Cuando informe del problema, incluya el nombre y la versión del cliente, el conjunto de opciones empujadas, la topología y el paso exacto en el que debería haber aparecido la dirección.

Si las cuatro comprobaciones pasan y la dirección está presente, es única y tiene la máscara correcta, la cuestión de la ruta pasa a ser la habitual: qué prefijos autoriza el servidor y cómo debe delimitar el cliente. Anote la dirección de túnel, su máscara de red y la topología antes de cambiar cualquier otra cosa, porque esos tres valores son los que el operador necesita comparar con la vista del servidor.