Automatisation L2TP sur Android : un script peut demander, pas créer

Le mythe veut que L2TP sur Android soit une chose de plus qu'un script shell peut lancer : ajouter une route, appeler l'ancien service, terminé. Cela ne peut pas être, car quatre couches différentes doivent s'accorder avant qu'un tunnel transporte un paquet. La couche IPsec protège le chemin, L2TP transporte la session, PPP négocie la liaison, et Android doit enregistrer le résultat comme un VPN autour duquel il peut router. J'ai vu cela tenté deux fois avec des commandes copiées, et les deux fois la route existait alors que rien n'était chiffré.

Ce qu'un changement de route accomplit réellement

Ajouter une route décide où va un paquet ensuite. Cela ne négocie pas une association de sécurité, n'ouvre pas de session L2TP et n'exécute pas l'échange PPP qui produit une adresse, un pair et des réglages DNS. Sur un téléphone, le résultat visible est un trafic qui part par le mauvais chemin, ou qui part et meurt, sans aucun état de tunnel nulle part.

Il en va de même pour un appel de service copié d'une version antérieure. La plomberie VPN interne d'Android n'est pas une API d'automatisation publiée, et une transaction numérotée d'une autre version peut frapper une opération différente ou exiger des privilèges que le script n'a pas. Une automatisation qui transporte un mot de passe ne devrait jamais dépendre d'arguments internes devinés, car le mode de défaillance est soit un no-op silencieux, soit un profil à moitié créé que personne ne nettoie.

Quatre propriétaires, et le script n'en est aucun

Prenez-les dans l'ordre. IPsec établit et maintient le chemin protégé et authentifie les pairs. L2TP transporte la session par-dessus, et cette superposition est pourquoi la norme les traite comme des mécanismes distincts plutôt qu'un protocole. À l'intérieur, PPP négocie les paramètres de liaison que le client utilisera. Android possède ensuite le côté plateforme : l'interface VPN enregistrée, la portée par application, l'état always-on et le cycle de vie qui décide de ce qui se passe quand l'application est tuée.

Un script ne peut voir que la dernière de ces couches, et généralement indirectement. Il peut demander à un client de se connecter si ce client expose un contrôle documenté, et il peut ensuite surveiller l'état de l'interface. Il ne peut pas remplacer les trois couches en dessous, et il ne peut pas faire que la plateforme traite une interface non enregistrée comme un VPN.

Pourquoi un démon n'est pas non plus un raccourci

Démarrer un démon Linux privilégié sur l'appareil ressemble à la pièce manquante, et cela monte souvent un tunnel. Ce que cela ne fait pas, c'est enregistrer ce tunnel auprès d'Android. L'interface existe dans le noyau, mais la sélection VPN de la plateforme, le routage par application, la politique always-on et le cycle de vie ne la connaissent pas, et les changements de route et de DNS du démon lui-même rivalisent avec le gestionnaire de réseau pour les mêmes tables.

Le résultat est une connexion qui fonctionne pour le trafic du démon et mystérieusement pas pour l'application qui vous importait, ou une qui survit jusqu'à ce que le système réévalue ses réseaux. Aucun des deux résultats n'est un bug de la plateforme ; c'est la frontière entre posséder un socket et posséder la fonction VPN.

À quoi ressemblent les voies prises en charge

Si l'organisation peut passer à un profil qu'Android provisionne lui-même, la voie de la plateforme est l'honnête. Depuis l'API 30, VpnManager prend en charge le provisionnement et le contrôle des profils VPN de la plateforme par les applications, avec un flux d'autorisation attaché à l'application appelante. Ce n'est pas un convertisseur L2TP : le modèle de profil qu'il provisionne pour IKEv2 ne traduit pas une configuration L2TP existante, et changer de protocole est une migration, pas un renommage. Les identités, les routes, le DNS privé et les permissions d'accès doivent être transférés délibérément.

Si le service doit rester en L2TP/IPsec, la combinaison prise en charge est un client et une version d'OS que l'opérateur documente réellement, et son contrat d'automatisation s'il existe. Quand il n'y a pas de contrôle sans surveillance documenté, la bonne réponse est une connexion manuelle prise en charge plutôt qu'un script privilégié fragile qui se trouve fonctionner sur une seule build.

Ce que fait une automatisation correcte

Avec un contrôle documenté, l'automatisation a une tâche petite et défendable : demander la connexion nommée, attendre qu'elle soit prête, s'arrêter en cas d'échec d'authentification ou de configuration, exécuter la charge de travail prévue et laisser le nettoyage au composant qui possède la connexion. Les identifiants restent avec le client qui sait les stocker et les faire tourner.

Notez quel composant possède chaque couche avant d'écrire la première ligne, et vérifiez le résultat par rapport à cela :

• IPsec et PPP sont gérés par le client, pas par les routes du script.
• La connexion apparaît dans l'état VPN de la plateforme, donc la portée par application et l'always-on s'y appliquent.
• Aucun appel de service interne, numéro de transaction ou argument deviné ne transporte d'identifiant.
• Un échec à n'importe quelle étape ne laisse pas de profil à moitié enregistré.