Serveur VPN Android : root ne rend pas le téléphone joignable
Trois problèmes distincts décident si un téléphone peut servir des clients VPN : le chemin entrant, le modèle de privilèges et le transfert. Root ne touche que le deuxième.
Root change les opérations réseau qu'un processus est autorisé à tenter. Il ne donne pas au téléphone une adresse joignable publiquement, ne réserve pas de mappage entrant chez l'opérateur et ne maintient pas un démon actif après un redémarrage. Si vous décidez si un téléphone Android peut servir de serveur VPN, séparez trois questions : le client visé peut-il seulement atteindre l'écouteur, quel modèle de privilèges l'implémentation du serveur exige-t-elle, et que faut-il transférer une fois le tunnel monté.
Qui doit atteindre le téléphone, et depuis où
Un client sur le même LAN autorisé et un client en données mobiles testent deux réseaux différents. Tranchez d'abord lequel est visé, car les réponses ne se transposent pas. En Wi-Fi, le trafic entrant non sollicité a généralement besoin d'un mappage sur le routeur amont et d'un chemin public utilisable au-delà. En cellulaire, le NAT de niveau opérateur signifie que l'IPv4 entrant est souvent indisponible, quoi que le téléphone autorise.
Ce dernier point est précisément celui que root ne peut pas toucher. Le pare-feu local du téléphone et le NAT de l'opérateur sont des systèmes différents, et changer le premier n'a aucun effet sur le second. Une adresse d'interface privée, une icône de données mobiles ou une socket en écoute ne prouvent pas la joignabilité. Si le chemin de l'opérateur offre bien de l'IPv6 routable globalement, il vous faut tout de même une politique d'écoute et de pare-feu délibérée pour lui ; posséder une adresse n'est pas la même chose qu'accepter des connexions.
| Client path | What actually decides reachability |
|---|---|
| Same LAN | The phone's listener and its local firewall |
| Wi-Fi, from the internet | A mapping on the upstream router plus a usable public path beyond it |
| Cellular IPv4 | The carrier's NAT, which the handset does not control |
| Cellular IPv6 | Address, listener and firewall policy together |
Servir et transférer sont deux réussites différentes
Une poignée de main VPN terminée prouve que le tunnel existe. Elle ne prouve pas que le client atteint un LAN derrière le téléphone, ni que le téléphone peut servir de sortie internet. Ce sont des configurations distinctes, bâties sur le plan d'adressage interne, les routes, le comportement de retour et une politique de transfert étroitement délimitée pour la tâche que vous voulez réellement.
Le mode de défaillance est prévisible : la poignée de main réussit, le client affiche connecté, et rien ne se charge. Avant de déboguer le client, décidez lequel des deux rôles vous construisez. L'accès distant à un appareil du réseau du téléphone et la sortie internet par tunnel complet exigent des règles de transfert différentes, et accorder les deux quand vous en vouliez un élargit l'exposition sans ajouter la capacité demandée.
Le modèle de privilèges est un choix, pas root ou rien
Un démon OpenVPN classique utilisant un périphérique TUN du noyau a besoin des capacités correspondantes, d'un accès au nœud du périphérique et de la coopération de la politique de sécurité d'Android. Root n'est pas une exemption générale de SELinux ; un processus privilégié reste contraint par la politique de la plateforme. C'est pourquoi un binaire qui tourne sans souci sur un serveur Linux peut échouer sur un téléphone sans erreur évidente sur les permissions.
Une implémentation de passerelle en espace utilisateur peut avoir un modèle de privilèges tout autre, si bien que l'affirmation courante selon laquelle tout serveur VPN sur Android exige root est trop large. Ce que root vous achète, c'est la possibilité de tenter plus d'opérations, pas la garantie qu'elles seront permises ni que le résultat sera joignable.
L'enregistrement du service VPN propre à Android est encore un autre mécanisme. Il donne à une application une interface client gérée avec un cycle de vie défini ; ce n'est pas un installateur de serveur général, et démarrer un démon depuis un terminal ne lui donne pas une gestion permanente, une politique par application ni un chemin de récupération propre.
Si vous voulez un point de sortie, changez l'architecture
Lorsque le but est simplement une sortie internet distante via le téléphone plutôt qu'une compatibilité avec un profil OpenVPN existant, un nœud de sortie pris en charge dans un réseau superposé est la conception la mieux adaptée. Tailscale documente un rôle de nœud de sortie Android avec ses propres étapes d'enregistrement, d'autorisation et de sélection de client.
Le compromis est réel et mérite d'être dit clairement : vous acceptez un autre protocole, un autre modèle de confiance et une dépendance à ce compte et à ce service de coordination. Il ne fait pas rejoindre le réseau superposé à un client OpenVPN non modifié, et il ne vous donne pas un écouteur OpenVPN sur une adresse publique.
Ce dont le déploiement a encore besoin
Quelle que soit la voie choisie, les bases opérationnelles décident s'il tient une semaine. Gardez les identifiants du serveur privés, délivrez des identités client distinctes et planifiez la révocation avant d'en avoir besoin. Décidez comment arrivent les mises à jour, ce qui maintient le service en marche en arrière-plan et comment il récupère après un redémarrage ou un changement de réseau.
Évitez les raccourcis qui semblent commodes : un binaire statique obsolète, des noms d'interface codés en dur et un script de démarrage qui vide la politique de pare-feu existante. Ensuite, n'acceptez le résultat qu'au vu d'un test concret : un client distant autorisé atteint la ressource visée, les destinations interdites restent indisponibles, et l'appareil revient de lui-même après l'événement de cycle de vie pris en charge. L'accès root est un ingrédient possible de ce résultat, et rarement le décisif.