Automatización L2TP en Android: el script puede pedirla, no crearla

El mito dice que L2TP en Android es una cosa más que un script de shell puede iniciar: añadir una ruta, llamar al servicio antiguo y listo. No puede serlo, porque cuatro capas distintas tienen que ponerse de acuerdo antes de que un túnel transporte un paquete. La capa IPsec protege el camino, L2TP transporta la sesión, PPP negocia el enlace y Android tiene que registrar el resultado como una VPN por la que pueda enrutar. He visto intentarlo dos veces con comandos copiados, y en ambas la ruta existía mientras nada estaba cifrado.

Qué consigue realmente cambiar una ruta

Añadir una ruta decide por dónde va un paquete a continuación. No negocia una asociación de seguridad, no abre una sesión L2TP y no ejecuta el intercambio PPP que produce una dirección, un par y los ajustes DNS. En un teléfono el resultado visible es tráfico que sale por el camino equivocado, o que sale y muere, sin ningún estado de túnel en ninguna parte.

Lo mismo vale para una llamada de servicio copiada de una versión anterior. La plomería VPN interna de Android no es una API de automatización publicada, y una transacción numerada de otra versión puede llegar a una operación distinta o exigir privilegios que el script no tiene. Una automatización que lleva una contraseña nunca debería depender de argumentos internos adivinados, porque el fallo es o un no-op silencioso o un perfil a medio crear que nadie limpia.

Cuatro dueños, y el script no es ninguno de ellos

Tómalos en orden. IPsec establece y mantiene el camino protegido y autentica a los pares. L2TP transporta la sesión sobre él, y esa estratificación es la razón por la que el estándar los trata como mecanismos separados y no como un solo protocolo. Dentro de eso, PPP negocia los parámetros de enlace que usará el cliente. Android es dueño entonces del lado de la plataforma: la interfaz VPN registrada, el alcance por aplicación, el estado always-on y el ciclo de vida que decide qué pasa cuando se mata la aplicación.

Un script solo puede ver la última de esas capas, y normalmente de forma indirecta. Puede pedir a un cliente que se conecte si ese cliente expone un control documentado, y puede vigilar después el estado de la interfaz. No puede sustituir a las tres capas inferiores, ni puede hacer que la plataforma trate una interfaz no registrada como una VPN.

Por qué un daemon tampoco es un atajo

Iniciar un daemon Linux privilegiado en el dispositivo parece la pieza que faltaba, y a menudo sí levanta un túnel. Lo que no hace es registrar ese túnel con Android. La interfaz existe dentro del kernel, pero la selección de VPN de la plataforma, el enrutamiento por aplicación, la política always-on y el ciclo de vida no la conocen, y los cambios de ruta y DNS del propio daemon compiten con el gestor de red por las mismas tablas.

El resultado es una conexión que funciona para el tráfico del daemon y misteriosamente no para la aplicación que te importaba, o una que sobrevive hasta que el sistema reevalúa sus redes. Ninguno de los dos resultados es un fallo de la plataforma; es la frontera entre poseer un socket y poseer la instalación VPN.

Cómo son las rutas compatibles

Si la organización puede pasar a un perfil que Android aprovisiona por sí misma, el camino de la plataforma es el honesto. Desde la API 30, VpnManager admite el aprovisionamiento y control de perfiles VPN de la plataforma, con un flujo de autorización ligado a la aplicación que llama. No es un conversor de L2TP: el modelo de perfil que aprovisiona para IKEv2 no traduce una configuración L2TP existente, y cambiar de protocolo es una migración, no un cambio de nombre. Las identidades, las rutas, el DNS privado y los permisos de acceso tienen que trasladarse a propósito.

Si el servicio debe seguir siendo L2TP/IPsec, la combinación compatible es un cliente y una versión del sistema que el operador documente de verdad, y su contrato de automatización si existe. Cuando no hay un control desatendido documentado, la respuesta correcta es una conexión manual compatible y no un script privilegiado frágil que da la casualidad de funcionar en una compilación.

Qué hace una automatización correcta

Dado un control documentado, la automatización tiene un trabajo pequeño y defendible: solicitar la conexión nombrada, esperar a que esté lista, detenerse si falla la autenticación o la configuración, ejecutar la carga de trabajo prevista y dejar la limpieza al componente que posee la conexión. Las credenciales se quedan con el cliente que sabe almacenarlas y rotarlas.

Anota qué componente posee cada capa antes de escribir la primera línea y comprueba el resultado contra esa lista:

• IPsec y PPP los maneja el cliente, no las rutas del script.
• La conexión aparece en el estado VPN de la plataforma, así que el alcance por aplicación y el always-on se le aplican.
• Ninguna llamada de servicio interno, número de transacción o argumento adivinado lleva una credencial.
• Un fallo en cualquier paso no deja un perfil medio registrado.