Automatización L2TP en Android: o script pode solicitala, non creala

O mito é que L2TP en Android é unha cousa máis que un script de shell pode iniciar: engadir unha ruta, chamar ao servizo antigo, feito. Non pode ser, porque catro capas diferentes teñen que poñerse de acordo antes de que un túnel transporte un paquete. A capa IPsec protexe o camiño, L2TP transporta a sesión, PPP negocia a ligazón e Android ten que rexistrar o resultado como unha VPN á que poida enrutar. Vin isto intentado dúas veces con comandos copiados, e nas dúas a ruta existía mentres nada estaba cifrado.

Que consegue realmente cambiar unha ruta

Engadir unha ruta decide por onde vai un paquete a continuación. Non negocia unha asociación de seguridade, non abre unha sesión L2TP e non executa o intercambio PPP que produce un enderezo, un par e axustes DNS. Nun teléfono o resultado visible é tráfico que sae polo camiño equivocado, ou que sae e morre, sen ningún estado de túnel en ningures.

O mesmo vale para unha chamada de servizo copiada dunha versión anterior. A fontanería VPN interna de Android non é unha API de automatización publicada, e unha transacción numerada doutra versión pode dar cunha operación distinta ou requirir privilexios que o script non ten. Unha automatización que leva un contrasinal nunca debería depender de argumentos internos adiviñados, porque o fallo é ou un no-op silencioso ou un perfil a medio crear que ninguén limpa.

Catro propietarios, e o script non é ningún deles

Tómaos en orde. IPsec establece e mantén o camiño protexido e autentica os pares. L2TP transporta a sesión por riba, e esa estratificación é a razón pola que o estándar os trata como mecanismos separados e non como un protocolo. Dentro diso, PPP negocia os parámetros de ligazón que usará o cliente. Android posúe entón o lado da plataforma: a interface VPN rexistrada, o ámbito por aplicación, o estado always-on e o ciclo de vida que decide que pasa cando se mata a aplicación.

Un script só pode ver a última desas capas, e normalmente de forma indirecta. Pode pedirlle a un cliente que se conecte se ese cliente expón un control documentado, e pode vixiar despois o estado da interface. Non pode substituír as tres capas inferiores, nin pode facer que a plataforma trate unha interface non rexistrada como unha VPN.

Por que un daemon tampouco é un atallo

Iniciar un daemon Linux privilexiado no dispositivo parece a peza que faltaba, e a miúdo si levanta un túnel. O que non fai é rexistrar ese túnel con Android. A interface existe dentro do kernel, pero a selección VPN da plataforma, o enrutamento por aplicación, a política always-on e o ciclo de vida non a coñecen, e os cambios de ruta e DNS do propio daemon compiten co xestor de rede polas mesmas táboas.

O resultado é unha conexión que funciona para o tráfico do daemon e misteriosamente non para a aplicación que che importaba, ou unha que sobrevive ata que o sistema reavalia as súas redes. Ningún dos dous resultados é un erro da plataforma; é a fronteira entre posuír un socket e posuír a instalación VPN.

Como son as rutas compatibles

Se a organización pode pasar a un perfil que Android aprovisiona por si mesmo, o camiño da plataforma é o honesto. Desde a API 30, VpnManager admite o aprovisionamento e control de perfís VPN da plataforma por parte das aplicacións, cun fluxo de autorización ligado á aplicación que chama. Non é un conversor de L2TP: o modelo de perfil que aprovisiona para IKEv2 non traduce unha configuración L2TP existente, e cambiar de protocolo é unha migración, non un cambio de nome. As identidades, as rutas, o DNS privado e os permisos de acceso teñen que trasladarse a propósito.

Se o servizo debe seguir sendo L2TP/IPsec, a combinación compatible é un cliente e unha versión do sistema que o operador documente de verdade, e o seu contrato de automatización se existe. Cando non hai un control desatendido documentado, a resposta correcta é unha conexión manual compatible e non un script privilexiado fráxil que dá a casualidade de funcionar nunha compilación.

Que fai unha automatización correcta

Dado un control documentado, a automatización ten un traballo pequeno e defendible: solicitar a conexión nomeada, agardar a que estea lista, deter-se se falla a autenticación ou a configuración, executar a carga de traballo prevista e deixar a limpeza ao compoñente que posúe a conexión. As credenciais quedan co cliente que sabe almacenalas e rota-las.

Anota que compoñente posúe cada capa antes de escribir a primeira liña, e comproba o resultado contra esa lista:

• IPsec e PPP manéxaos o cliente, non as rutas do script.
• A conexión aparece no estado VPN da plataforma, así que o ámbito por aplicación e o always-on sé lle aplican.
• Ningunha chamada de servizo interno, número de transacción ou argumento adiviñado leva unha credencial.
• Un fallo en calquera paso non deixa un perfil medio rexistrado.