Android 12 et IKEv1 VPN : version de lancement, IKEv2 et applications tierces

Deux téléphones affichent tous deux Android 12 dans les Paramètres, et un seul d’entre eux démarre encore l’ancien profil IPsec XAuth que propose votre passerelle. La différence n’est pas un réglage accessible à l’utilisateur : le garde qui contrôle le chemin natif IKEv1 regarde le niveau SDK avec lequel l’appareil a été livré, pas seulement la version qu’il exécute aujourd’hui. Ce seul détail décide si une comparaison de parc a un sens, et il décide aussi laquelle des trois voies de migration vous est réellement nécessaire.

Deux téléphones Android 12 ne sont pas le même cas de test

Le changement AOSP qui a empêché les nouveaux appareils de démarrer les anciens profils IKEv1 compare DEVICE_INITIAL_SDK_INT à Android S, soit API 31. Sur le chemin de démarrage natif, un profil éligible déclenche une erreur d’opération non prise en charge avant même qu’une connexion utile existe. Un téléphone livré avec Android 11 puis mis à jour passe encore ce garde ; un modèle lancé avec Android 12 non.

Vous pouvez lire les deux nombres sur un appareil avec le débogage activé :

adb shell getprop ro.product.first_api_level
adb shell getprop ro.build.version.sdk
adb shell getprop ro.build.version.release

La première valeur est le niveau de lancement qui intéresse le garde, la seconde ce que le téléphone exécute aujourd’hui. Quand la propriété manque, appuyez-vous sur la documentation de support du modèle plutôt que de deviner à partir du nom commercial, et ne supposez pas que la compilation du fabricant conserve tous les chemins de compatibilité de sa version de base.

Une autre distinction épargne une heure de support perdue : un profil enregistré encore listé dans les réglages VPN ne prouve rien sur le fait que la plateforme le démarrera. Ressaisir la PSK ou modifier des routes ne peut pas supprimer un contrôle de prise en charge de protocole exécuté plus tôt, et l’échec ressemble à un problème d’identifiants alors qu’il n’en est pas un.

Voie un : garder la pile native là où elle fonctionne encore

L’ancienne pile est celle qui lit les profils IPsec XAuth PSK, IPsec Hybrid RSA et L2TP/IPsec PSK depuis l’écran VPN du système. Sur un appareil livré sous API 31, elle reste une voie viable après une mise à jour, ce qui explique qu’un pilote sur un téléphone plus ancien puisse réussir alors qu’un nouveau ne démarre pas le même profil.

La comparaison qui compte se fait par classe d’appareil, pas par version d’Android : listez les modèles du parc, lisez leurs niveaux d’API de lancement et séparez-les entre appareils qui démarrent encore le profil et appareils qui ne peuvent pas. Toute autre approche produit une politique de support qui se contredit dès qu’un utilisateur achète un nouveau téléphone.

Voie deux : les profils IKEv2 de la plateforme

Le modèle public d’approvisionnement d’Android pour IKEv2 est un autre objet, pas un profil IKEv1 renommé. L’API de plateforme pour les profils IKEv2 est arrivée avec API 30 et attend IKEv2 avec la méthode d’authentification proposée par la passerelle, généralement par certificat ou EAP. Il n’existe pas de mise à niveau compatible au niveau du fil d’IKEv1 XAuth ou Hybrid vers IKEv2 : la passerelle doit être configurée pour le nouveau protocole et le profil doit porter l’identité correspondante.

C’est la voie à la plus longue durée de vie, et aussi celle qui révèle le vrai travail. La validation d’identité, l’authentification des utilisateurs, le DNS, les routes de tunnel divisé et l’autorisation des ressources doivent tous survivre à la migration ; ne réussir que la poignée de main laisse les utilisateurs connectés à un tunnel qui n’atteint rien.

Le déploiement passe généralement par un MDM ou une configuration gérée plutôt que par la saisie de champs par l’utilisateur. Si cette infrastructure n’existe pas encore, le plan de migration doit l’inclure, car ressaisir un profil IKEv2 à la main sur chaque appareil n’est pas une opération qu’un service d’assistance peut absorber.

Voie trois : une application cliente tierce

Certaines applications VPN embarquent leur propre implémentation du protocole et ne dépendent pas du tout de la pile native. Cela en fait un palliatif légitime pour un parc qui ne peut pas migrer vite, mais la question de compatibilité se déplace vers l’application : si elle implémente exactement le mode IKEv1 que parle votre passerelle, avec l’authentification et les suites de chiffrement qu’elle exige.

Traitez la matrice de support de l’application comme l’autorité, pas la description de la boutique, et testez un appareil réel contre la passerelle réelle avant de la recommander. Rooter un téléphone pour restaurer un chemin de plateforme supprimé n’est pas non plus une solution maintenue ; cela déplace le problème vers une configuration non prise en charge que la prochaine mise à jour système peut casser silencieusement.

Choisissez selon ce que la passerelle peut offrir

La décision se resserre quand vous savez deux choses : quels appareils ont été lancés avec API 31 ou après, et si la passerelle peut offrir un service IKEv2 avec le même modèle d’enrôlement. Si oui, migrez et cessez d’investir dans l’ancien profil. Si non, gardez IKEv1 pour les appareils qui le démarrent encore, et donnez aux nouveaux appareils un client tiers comme exception documentée et limitée dans le temps, pas comme contournement tacite.

Deux points rendent le plan défendable. Premièrement, consignez la raison de chaque exception avec le modèle et le niveau de lancement, pour qu’un auditeur voie que la frontière est un garde de plateforme et non une préférence inexpliquée. Deuxièmement, traitez la migration comme un travail planifié : IKEv1 est déprécié dans la voie des normes (RFC 9395), ce qui signifie que les appareils restants continueront de diminuer et que les exceptions devraient expirer avec eux.