Automação de L2TP no Android: um script pode pedir, não construir

O mito é que L2TP no Android é mais uma coisa que um script shell pode iniciar: adicionar uma rota, chamar o serviço antigo, pronto. Não pode ser, porque quatro camadas diferentes precisam concordar antes de um túnel transportar um pacote. A camada IPsec protege o caminho, L2TP transporta a sessão, PPP negocia o link e o Android precisa registrar o resultado como uma VPN em torno da qual possa encaminhar. Já vi isso ser tentado duas vezes com comandos copiados, e nas duas a rota existia enquanto nada estava cifrado.

O que uma mudança de rota realmente consegue

Adicionar uma rota decide para onde um pacote vai em seguida. Não negocia uma associação de segurança, não abre uma sessão L2TP e não executa a troca PPP que produz um endereço, um par e configurações de DNS. Num telefone, o resultado visível é tráfego que sai pelo caminho errado, ou sai e morre, sem nenhum estado de túnel em lugar algum.

O mesmo vale para uma chamada de serviço copiada de uma versão anterior. O encanamento interno de VPN do Android não é uma API de automação publicada, e uma transação numerada de outra versão pode atingir outra operação ou exigir privilégios que o script não tem. Uma automação que carrega uma senha nunca deve depender de argumentos internos adivinhados, porque o modo de falha é ou um no-op silencioso ou um perfil meio criado que ninguém limpa.

Quatro donos, e o script não é nenhum deles

Pegue-os em ordem. O IPsec estabelece e mantém o caminho protegido e autentica os pares. O L2TP transporta a sessão por cima dele, e esse empilhamento é o motivo pelo qual o padrão os trata como mecanismos separados, e não como um só protocolo. Dentro disso, o PPP negocia os parâmetros de link que o cliente usará. Depois o Android é dono do lado da plataforma: a interface VPN registrada, o escopo por aplicativo, o estado always-on e o ciclo de vida que decide o que acontece quando o app é morto.

Um script só consegue ver a última dessas camadas, e normalmente de forma indireta. Ele pode pedir a um cliente que se conecte se esse cliente expõe um controle documentado, e pode observar o estado da interface depois. Não pode substituir as três camadas debaixo, nem pode fazer a plataforma tratar uma interface não registrada como VPN.

Por que um daemon também não é atalho

Iniciar um daemon Linux privilegiado no aparelho parece a peça que falta, e muitas vezes ele realmente levanta um túnel. O que ele não faz é registrar esse túnel no Android. A interface existe dentro do kernel, mas a seleção de VPN da plataforma, o roteamento por aplicativo, a política always-on e o ciclo de vida não sabem dela, e as mudanças de rota e DNS do próprio daemon competem com o gerenciador de rede pelas mesmas tabelas.

O resultado é uma conexão que funciona para o tráfego do daemon e misteriosamente não para o aplicativo com que você se importava, ou uma que sobrevive até o sistema reavaliar suas redes. Nenhum dos dois resultados é um bug da plataforma; é a fronteira entre possuir um socket e possuir o recurso de VPN.

Como são as rotas suportadas

Se a organização pode passar para um perfil que o próprio Android provisiona, o caminho da plataforma é o honesto. A partir da API 30, o VpnManager suporta o provisionamento e o controle de perfis de VPN da plataforma por aplicativos, com um fluxo de autorização ligado ao aplicativo que chama. Não é um conversor de L2TP: o modelo de perfil que provisiona para IKEv2 não traduz uma configuração L2TP existente, e mudar de protocolo é uma migração, não uma renomeação. Identidades, rotas, DNS privado e permissões de acesso precisam ser transferidos de propósito.

Se o serviço precisa continuar em L2TP/IPsec, a combinação suportada é um cliente e uma versão de sistema que o operador realmente documenta, e seu contrato de automação se existir. Quando não há um controle não assistido documentado, a resposta correta é uma conexão manual suportada, não um script privilegiado frágil que por acaso funciona numa build.

O que uma automação correta faz

Com um controle documentado, a automação tem um trabalho pequeno e defensável: solicitar a conexão nomeada, esperar a prontidão, parar em falha de autenticação ou configuração, executar a carga de trabalho pretendida e deixar a limpeza para o componente que possui a conexão. As credenciais ficam com o cliente que sabe armazená-las e rotacioná-las.

Anote qual componente possui cada camada antes de escrever a primeira linha, e verifique o resultado contra isso:

• IPsec e PPP são tratados pelo cliente, não pelas rotas do script.
• A conexão aparece no estado de VPN da plataforma, então o escopo por aplicativo e o always-on se aplicam a ela.
• Nenhuma chamada de serviço interna, número de transação ou argumento adivinhado carrega uma credencial.
• Uma falha em qualquer etapa não deixa um perfil meio registrado.