Export VPN Android : ce qui passe réellement sur un nouveau téléphone
Un export VPN Android transmet des réglages et parfois une clé, mais jamais l'autorisation de l'appareil. Vérifiez ce qui passe vraiment avant d'effacer l'ancien téléphone.
Exporter un profil VPN depuis Android ressemble à une étape de sauvegarde, et le menu qui le propose ne fait rien pour corriger cette impression. Ce que vous emportez, c'est une entrée de parseur, une clé que le système d'exploitation ne rendra peut-être jamais, et une autorisation délivrée à ce téléphone précis. Séparez ces trois éléments et la question utile apparaît : quelle pièce manque encore sur l'appareil neuf ?
Le fichier est la partie facile. Les deux autres décident si la migration fonctionne.
Ce que contient réellement un profil exporté
Ouvrez le fichier dans un éditeur de texte avant de lui faire confiance. Un profil OpenVPN est un petit langage de configuration : remote, proto, data-ciphers et souvent des blocs <ca>, <cert>, <key> ou <tls-crypt> en ligne que le client remet à sa pile TLS. Une configuration WireGuard est plus plate : [Interface] contient PrivateKey et Address, puis un [Peer] par point de terminaison portant PublicKey, AllowedIPs et Endpoint. IKEv2 arrive sous forme de .mobileconfig avec des dictionnaires de charge utile au lieu de blocs de clés.
Aucun de ces textes n'est un identifiant à lui seul. L'identifiant, c'est la clé privée, et chaque format la colle en ligne ou pointe vers un alias qui ne se résout qu'à l'intérieur du client qui l'a créé.
Où vit réellement la clé sur Android
Android conserve les données des applications sous /data/data/<package>, lisibles par le seul UID de cette application. Il n'existe aucun moyen pris en charge de copier le répertoire privé d'une autre application depuis un téléphone non rooté, et adb backup a cessé d'être une réponse générale lorsque Android 12 l'a déprécié et que les clients ont commencé à déclarer allowBackup="false". Un export depuis un client Android signifie donc ce que ce client implémente, pas une copie du système de fichiers.
La couche d'identité se trouve sous l'application. Si un client a importé votre clé dans Android Keystore, le matériel y est généré ou enveloppé, et les exports ultérieurs peuvent porter une référence à un alias Keystore au lieu des octets. Les clés adossées au matériel sont conçues pour que même l'application propriétaire ne puisse pas les lire, comme le décrit Keystore documentation, si bien qu'un profil pointant vers cet alias s'importe proprement sur le même téléphone et échoue partout ailleurs.
Ce n'est pas un export cassé. C'est la propriété que l'on a demandé à la plateforme de fournir.
Ce qu'un profil ne peut pas transporter
Comparez les objets à ce qu'une destination acceptera :
| Objet | Transféré ? | Pourquoi |
|---|---|---|
| Protocole et point de terminaison | Oui, si le client de destination le prend en charge | Texte en clair dans le profil |
| Certificat CA et vérification du nom d'hôte | Généralement | Matériel public, mais le nom d'hôte doit toujours correspondre au certificat |
| Certificat client | Oui, sauf s'il est lié à un appareil | Les certificats sont portables ; l'émetteur décide combien d'appareils peuvent en utiliser un |
| Clé privée | Seulement si elle a été générée hors du Keystore | Les clés adossées au matériel ne peuvent pas être exportées, seulement remplacées |
| Compte, MFA, session SSO | Non | Les jetons expirent et restent liés à l'appareil qui les a obtenus |
| Routes, DNS et portée des applications | Uniquement comme texte de configuration | Android les applique à la connexion via VpnService.Builder |
| Liste d'applications en tunnel divisé | Rarement | Les noms de paquets diffèrent entre appareils, et la liste est un état du client |
Deux lignes causent l'essentiel de la confusion. Une clé générée sur l'appareil et marquée non exportable disparaît vraiment avec les données de l'application, donc le remplacement est une nouvelle clé plus un certificat émis pour elle. Un jeton de session copié sur un nouveau téléphone meurt généralement au premier rafraîchissement, ce qui se lit comme un import raté.
L'import est une analyse, puis une demande de consentement
Côté réception, l'import est une analyse suivie d'une validation. Le client lit la configuration, vérifie que chaque bloc référencé existe, puis écrit la définition du tunnel dans son propre bac à sable, et c'est pourquoi le fichier choisi dans Téléchargements n'est pas ce qui se connecte ensuite.
Vient ensuite une étape d'autorisation qu'aucun fichier ne peut sauter. Android exige que l'application appelle VpnService.prepare() et reçoive votre consentement avant de pouvoir établir un tunnel, si bien qu'un profil tout juste importé affiche encore une fois la boîte de dialogue système. Le tunnel est ensuite construit explicitement via addAddress, addRoute, addDnsServer et addAllowedApplication ou addDisallowedApplication pour le routage par application. Rien de tout cela n'est impliqué par un point de terminaison, donc le même profil peut produire un ensemble de routes effectives différent dans deux clients.
Les configurations à base de certificats ajoutent une bifurcation. Quand le serveur émet un certificat pour un appareil précis, comme le font MDM et l'enrôlement SCEP, le réutiliser sur un second téléphone fonctionne jusqu'à ce que le serveur impose une session par identité, ou échoue à la poignée de main TLS. Vérifiez la politique de l'émetteur avant de prévoir une réutilisation.
Vérifiez le nouvel appareil avant de retirer l'ancien
Gardez l'ancien téléphone connecté jusqu'à ce que le nouveau ait passé quelque chose de mieux qu'une icône verte. Confirmez l'adresse de sortie depuis le nouvel appareil et le résolveur DNS qu'il a réellement utilisé. Si split tunneling compte, lancez une application qui doit contourner le tunnel et une qui ne doit pas, puis regardez laquelle atteint votre fournisseur d'accès.
Une vérification tranche l'adresse de sortie. Ouvrez https://ifconfig.me dans le navigateur du téléphone, puis exécutez curl -s https://ifconfig.me depuis un ordinateur portable sur le même Wi-Fi et comparez les deux réponses avec l'adresse attribuée par votre fournisseur.
C'est seulement alors que vous retirez l'ancienne identité, et vous le faites via l'émetteur : révoquez le certificat ou retirez l'appareil du compte. Supprimer un fichier des Téléchargements ne termine rien, car deux appareils portant le même certificat paraissent identiques dans le journal du serveur.
Si l'export s'avère non portable, la solution est un nouvel enrôlement plutôt qu'un paquet de configuration public. Demandez un profil pour un second appareil, ou générez la paire de clés sur le nouveau téléphone et soumettez la CSR ; plus lent, et c'est la voie que l'émetteur prend en charge.
Passez la liste de contrôle avant de supprimer quoi que ce soit : le nouvel appareil se connecte, l'adresse de sortie et le DNS concordent, la portée par application est celle voulue, l'ancienne identité est révoquée, et tout fichier de configuration conservé se trouve dans un stockage chiffré.