Firefox lancé dans un namespace a transmis l’URL à une instance existante

Une commande s’exécute dans le namespace du VPN, une fenêtre Firefox apparaît, et la page sort malgré tout par la connexion ordinaire. La configuration du routage n’est probablement pas la première chose à reconstruire. Vérifiez si la commande a créé l’instance de navigateur attendue ou si elle a transmis l’URL à une instance qui tournait déjà ailleurs. Cette distinction explique le résultat en une étape et épargne une heure de nftables.

L’indice est que la fenêtre apparaît instantanément, sans démarrage à froid.

Une nouvelle fenêtre n’est pas une nouvelle instance

Les applications de bureau réutilisent couramment un processus existant. Un lanceur dans un namespace réseau ne déplace pas un destinataire déjà en cours vers ce namespace, car le destinataire n’a jamais fait partie du lancement. Le comportement de contrôle à distance de Firefox est lié aux profils : lancer contre un profil déjà utilisé transmet les arguments à son propriétaire. La nouvelle fenêtre est réelle ; le nouveau chemin réseau ne l’est pas.

La navigation privée et l’option de nouvelle fenêtre ne sont pas des contrôles d’isolation réseau.

Ce n’est pas non plus le cas d’une option de ligne de commande qui n’affecte que le mode fenêtre. Si le profil est occupé, la requête va au processus qui le possède, et ce processus conserve le namespace avec lequel il a démarré.

Forcez une instance séparée sur un profil séparé

Utilisez un profil dédié créé via le flux de travail des profils pris en charge par le navigateur, et lancez-le explicitement avec ce profil. Dans les versions de Firefox qui le prennent en charge, --new-instance demande une nouvelle instance plutôt qu’une fenêtre dans une instance existante. Consultez la sortie d’aide de la version installée, car les options disponibles varient selon la version.

N’essayez pas d’ouvrir le même profil actif simultanément, et ne traitez pas un avertissement de profil en cours d’utilisation comme une instruction de supprimer les fichiers de verrouillage.

Exécutez aussi le navigateur sous son utilisateur habituel non root. La configuration réseau nécessite souvent des droits administratifs, et il est tentant de donner les mêmes au navigateur parce qu’il fait partie de la même expérience. Le navigateur graphique n’en a pas besoin, et l’exécuter en root crée une classe distincte de problèmes de profil et de permissions. Gardez le privilège et le chemin réseau comme deux décisions indépendantes.

Vérifiez quel processus porte le trafic

Sous Linux, le namespace réseau d’un processus est visible via son lien de namespace. Lisez-le pour le processus que vous croyez à l’origine de la requête, puis pour le processus qui la fait réellement.

readlink /proc/ACTUAL_PID/ns/net

Les navigateurs exécutent plusieurs processus, donc l’identité compte : le processus de contenu qui établit la connexion n’est peut-être pas celui que vous avez inspecté en premier. Comparez le lien au namespace visé et confirmez avec une requête nouvelle et inoffensive que vous pouvez attribuer à une seule instance. L’attribution est tout le test. Si vous ne pouvez pas dire quel processus a établi la connexion, vous n’avez pas testé le namespace.

Quand le namespace est vraiment le mauvais

Parfois le lanceur échoue réellement et la nouvelle instance démarre dans le mauvais namespace. Vérifiez le service ou le wrapper qui l’a engendrée, car une unité ou une entrée de bureau peut perdre le namespace lorsqu’elle se réexécute via un bus de session. Testez ensuite à nouveau depuis un shell dans le bon namespace avant d’accuser le navigateur. Une variable à la fois est le seul moyen de garder cela diagnosticable.

Partager un affichage ne partage pas non plus un résolveur.

Si le processus est dans le bon namespace et que la résolution de noms échoue encore,examinez son environnement de résolveur comme un problème distinct. Aucun autre changement de routage ne peut déplacer une requête qui a été transmise à la mauvaise instance avant même d’avoir commencé.