Libertine offre-t-il à Ubuntu Touch un VPN pour tout le téléphone ?
Un paquet de bureau dans un conteneur répond à une autre question qu’un tunnel pour tout le téléphone. Suivez où vivent le réseau, l’identité et la politique de panne.
Sur Ubuntu Touch, deux questions sont posées comme une seule : ce paquet de bureau fonctionnera-t-il, et le téléphone aura-t-il un VPN. Le conteneur répond à la première. Rien en lui ne répond à la seconde, car un conteneur a sa propre vision du système de fichiers, tandis que la pile réseau et sa politique appartiennent au téléphone. Suivez où vit chaque pièce avant de promettre un flux de travail.
Deux questions qui n’en font qu’une en apparence
Exécuter une application de bureau dans un conteneur est une réussite d’empaquetage. Faire en sorte que le gestionnaire de connexions du téléphone établisse un tunnel, le maintienne pendant la veille et décide de ce qui se passe en cas de coupure relève du travail de plateforme. Un installateur qui se termine dans le conteneur prouve seulement que les dépendances y ont été résolues. Il ne dit rien sur la présence d’un greffon VPN approuvé sur le téléphone, sur la survie du tunnel à un redémarrage, ni sur les applications qui l’utilisent.
Gardez les deux dans des phrases séparées dans toute évaluation. Les fondre, c’est ainsi qu’une démonstration de laboratoire devient un engagement de support que personne ne peut tenir.
Ce que la frontière du conteneur fournit réellement
Un conteneur Libertine est un environnement inscriptible superposé à un téléphone dont le système de base est en lecture seule. C’est pourquoi y installer un paquet fonctionne tout court, et pourquoi la même installation sur le système de base ne fonctionne pas. Il exécute aussi les applications au premier plan, intégrées à l’écran du téléphone, et il n’est explicitement pas un moyen d’exécuter des logiciels serveur ni de maintenir un processus vivant en arrière-plan. Ces contraintes comptent pour un client VPN, censé rester actif.
libertine-container-manager list
libertine-container-manager info -i <container-id>
libertine-launch -i <container-id> bash
La liste montre quels conteneurs existent, et la commande info rapporte la distribution et l’état d’installation. La commande launch vous donne un interpréteur à l’intérieur, ce qui est le bon endroit pour inspecter ce que le paquet a réellement installé. Ce qu’elle ne vous donne pas, c’est autorité sur le réseau du téléphone. Un binaire dans le conteneur qui veut créer un tunnel a besoin d’une interface privilégiée, et cette interface appartient à la plateforme, pas au conteneur.
Où vit l’état réseau du téléphone
Les noms, les routes et les profils de connexion sont gérés par le service réseau du téléphone, hors de tout conteneur. Une entrée de tunnel n’y apparaît que lorsque la plateforme prend en charge ce type de VPN et que l’opérateur a installé le greffon correspondant.
nmcli connection show
ip route get 10.42.0.10
ip -br addr show
La liste des connexions est la réponse qui fait autorité à la question de savoir s’il existe un profil VPN sur ce téléphone. Si votre tunnel est absent de cette liste, aucun travail dans le conteneur ne le fera apparaître. La recherche de route répond à une question plus étroite : quelle interface ce téléphone utiliserait pour une destination. C’est la vérification à répéter après chaque changement, car un profil peut exister et n’être malgré tout pas le chemin qu’emprunte une application donnée.
Lisez un flux de travail de bout en bout
Choisissez la tâche réelle, comme atteindre une base de données privée avec un client de bureau. Suivez ensuite le flux : l’application démarre dans le conteneur, résout le nom d’hôte via le résolveur qu’utilise le téléphone, ouvre une socket, et le routage du téléphone décide quelle interface la porte. Chaque étape a un propriétaire. Le conteneur possède l’application, la plateforme possède le résolveur et le routage, et le point d’extrémité VPN possède l’authentification. Une défaillance à une étape est une défaillance de cette étape, pas de l’idée entière.
Testez séparément le nom d’hôte privé et l’adresse privée. Un nom qui résout vers une adresse publique et une adresse qui s’achemine dans un tunnel sont des observations différentes, et les confondre produit un rapport impossible à reproduire.
Que consigner lorsque la réponse est non
Parfois la conclusion honnête est que ce téléphone, sur cette version, ne peut pas porter le flux de travail. Écrivez-le avec les preuves : quels types de connexion la plateforme propose, quels clients ont été essayés et à quelle étape l’échec est survenu.
Indiquez ensuite l’alternative retenue, qu’il s’agisse d’un autre appareil, d’une autre méthode d’accès ou d’une tâche plus étroite qui reste dans le conteneur sans toucher aux réseaux privés.
Résistez à la tentation de remonter le système de base ou d’accorder des privilèges inexpliqués pour reproduire une ancienne recette. Un téléphone qui démarre n’est pas la même chose qu’un téléphone dont vous pouvez encore raisonner la politique réseau six mois plus tard.