VPN toujours active sur Android : comment le nom du point de sortie est résolu en premier
Android bloque le trafic avant que le tunnel existe, mais le client doit quand même résoudre son point de sortie. Voici l’ordre, et où cela se bloque.
Le téléphone redémarre, l’option toujours active est activée, le blocage des connexions sans VPN est activé, et le tunnel ne monte jamais. Rien n’est mal configuré : le blocage fait son travail, et la tentative du client lui-même d’atteindre son point de sortie y est soumise aussi. Le point de sortie doit être résolu avant que le tunnel existe, par un client autorisé à parler au réseau alors qu’aucune autre application ne l’est. Comprendre quel composant le fait, et dans quel ordre, transforme le mystère en question de configuration.
Ce que le constructeur de VPN demande réellement
Une application VPN Android ne remet pas au système une adresse de serveur. Elle construit une interface locale : des adresses et des routes pour le tunnel, les résolveurs que les applications doivent utiliser à l’intérieur, puis establish() renvoie un descripteur de fichier que l’application lit et écrit comme des paquets IP bruts. Le point de sortie distant n’apparaît jamais dans ce constructeur.
C’est le fait structurel décisif. La plateforme crée une interface tun et y applique une politique ; l’application implémente le transport en espace utilisateur, c’est-à-dire qu’elle résout elle-même le nom de son point de sortie et ouvre la connexion chiffrée. Un point de sortie avec un nom d’hôte est donc possible, non parce que la plateforme prend en charge les noms, mais parce que la plateforme ne voit jamais le point de sortie.
Un champ du constructeur prend des adresses : les serveurs DNS. Ce doivent être des adresses numériques de résolveur, généralement celles que l’opérateur veut interroger à travers le tunnel. Ce champ décrit où les applications envoient leurs requêtes une fois le tunnel monté. Il ne dit rien sur la façon dont le client trouve le point de sortie, et traiter les deux comme le même réglage est le début de la confusion.
Deux questions DNS, pas une
La première question est : où les applications envoient leurs requêtes une fois le tunnel monté ? La réponse est une adresse de résolveur à l’intérieur du tunnel, joignable par l’interface tun, numérique par construction.
La seconde question est : comment le client trouve-t-il son propre point de sortie avant que ce tunnel existe ? Cette recherche a lieu hors du tunnel, sur le réseau sous-jacent, dans le processus du client. Elle peut utiliser un nom et doit utiliser un résolveur que l’appareil atteint sans le VPN.
| Étape | Qui résout | Chemin | À quoi ressemble l~échec |
|---|---|---|---|
| Recherche du point de sortie | L~application VPN | Réseau sous-jacent, socket protégé | Ne se connecte jamais ; aucun trafic sur l~interface tun |
| Authentification du pair | Client et serveur | Transport du tunnel | Se connecte puis tombe ; erreur de certificat ou de clé |
| Recherche de nom privé | Applications via le tunnel | Résolveur dans le tun | Tunnel monté, les sites internes ne se résolvent pas |
Trois étapes, trois symptômes différents. Un seul message d’erreur comme impossible de se connecter les fond, et c’est pourquoi les gens finissent par modifier le champ du serveur DNS pour corriger un problème qui survient avant que ce champ soit lu.
Pourquoi l’amorçage peut se bloquer
Toujours active avec le blocage activé signifie que le trafic qui n’est pas dans le VPN est supprimé, y compris celui de l’application qui possède le VPN. La sortie est explicite : l’application appelle protect() sur un socket, ce qui le lie au réseau sous-jacent pour qu’il contourne le tunnel et soit autorisé à sortir. Chaque client VPN doit le faire pour son propre transport, sinon il n’atteindrait jamais un serveur.
Imaginez un déploiement où le seul résolveur qui connaît le nom du point de sortie est lui-même à l’intérieur du tunnel. Le client a besoin du tunnel pour résoudre le nom, et du nom pour construire le tunnel. C’est une vraie dépendance circulaire, et aucune configuration client ne la résout. C’est une erreur de conception, pas un bogue.
Le moment expose la même dépendance sous des formes plus douces. Au démarrage avant le premier déverrouillage, l’appareil peut ne pas avoir encore de réseau utilisable ; sur un portail captif, le réseau existe mais bloque tout sauf le portail ; lors d’un passage du Wi-Fi au mobile, le réseau sous-jacent du socket protégé change et le client doit le remarquer et résoudre à nouveau. Chacun est un événement d’amorçage et mérite un test délibéré plutôt qu’une découverte à 3 heures du matin.
Pourquoi figer la réponse n’est pas une correction
Le raccourci tentant est de résoudre le nom une fois et de coller l’adresse obtenue dans un champ numérique, ou de la coder en dur dans une compilation maison. Cela semble fonctionner, et cela transforme un nom en instantané. Quand l’opérateur déplace le point de sortie, par migration, changement anycast ou nouvelle adresse régionale, le client continue d’appeler l’ancienne et rien dans l’interface n’explique pourquoi.
Les enregistrements DNS portent une durée de vie précisément pour que les réponses puissent changer ; la mise en cache est définie par cette durée, pas pour toujours. Figer une réponse jette le mécanisme qui rend un nom meilleur qu’une adresse, tout en conservant le coût opérationnel d’avoir utilisé un nom.
Figer la réponse s’accompagne souvent d’une seconde mauvaise habitude : assouplir les contrôles d’identité parce que la connexion échoue maintenant autrement. La vérification de l’identité du serveur ne fait pas partie du problème d’amorçage, et l’affaiblir échange une gêne DNS contre un risque d’interception.
Des conceptions qui survivent à un redémarrage
La disposition durable est sans éclat. Utilisez un client qui implémente correctement les sockets protégés et résout son point de sortie sur le réseau sous-jacent, et donnez-lui un nom de point de sortie qui se résout publiquement ou via un résolveur joignable avant le tunnel. Laissez le blocage activé ; le désactiver entièrement pour que le DNS fonctionne supprime la propriété pour laquelle le déploiement existe.
Là où le point de sortie doit rester privé, fournissez un chemin d’amorçage explicite que la plateforme peut utiliser, comme un résolveur joignable sans le tunnel ou une connexion de gestion maintenue par l’opérateur, et gardez cette exception étroite et portée par la politique plutôt que par un interrupteur utilisateur. La documentation Android VpnService est la référence sur ce que la plateforme garantit en matière de protection et de cycle de vie, et la référence VpnService.Builder confirme que le champ DNS prend des adresses numériques.
Vérifiez ensuite les trois étapes, dans l’ordre, sur une connexion neuve après un redémarrage : le nom du point de sortie se résout, le tunnel s’établit et le pair s’authentifie, et un nom privé se résout via le résolveur du tunnel. Si la première étape échoue, rien de ce qui suit ne peut fonctionner.
- La résolution du point de sortie a lieu dans l’application, hors du tunnel, sur un socket protégé.
- Le champ DNS du constructeur sert aux applications dans le tunnel, pas au point de sortie du client.
- Un résolveur joignable seulement via le tunnel est un blocage, pas un démarrage lent.
- Testez le point de sortie, l’authentification et la recherche privée séparément après un redémarrage.