Ein Befehl läuft im VPN-Namespace, ein Firefox-Fenster erscheint, und die Seite verlässt den Rechner trotzdem über die gewöhnliche Verbindung. Das Routing-Setup ist wahrscheinlich nicht das Erste, was neu aufgebaut werden muss. Prüfen Sie, ob der Befehl die erwartete Browserinstanz erzeugt oder die URL an eine übergeben hat, die bereits woanders lief. Dieser Unterschied erklärt das Ergebnis in einem Schritt und spart eine Stunde nftables.

Das Erkennungszeichen ist, dass das Fenster sofort erscheint, ohne Kaltstart.

Ein neues Fenster ist keine neue Instanz

Desktop-Anwendungen verwenden routinemäßig einen bestehenden Prozess weiter. Ein Starter in einem Netzwerk-Namespace verschiebt keinen bereits laufenden Empfänger in diesen Namespace, denn der Empfänger war nie Teil des Starts. Das Remoting-Verhalten von Firefox hängt an Profilen: Ein Start gegen ein bereits benutztes Profil übergibt die Argumente an dessen Eigentümer. Das neue Fenster ist echt; der neue Netzwerkpfad nicht.

Privates Surfen und die Option für ein neues Fenster sind keine Kontrollen zur Netzwerktrennung.

Das gilt auch nicht für ein Kommandozeilen-Flag, das nur den Fenstermodus betrifft. Ist das Profil belegt, geht die Anfrage an den Prozess, der es besitzt, und dieser Prozess behält den Namespace, in dem er gestartet ist.

Erzwingen Sie eine getrennte Instanz in einem getrennten Profil

Verwenden Sie ein eigenes Profil, das über den unterstützten Profil-Workflow des Browsers angelegt wurde, und starten Sie ihn ausdrücklich mit diesem Profil. In Firefox-Builds, die das unterstützen, verlangt --new-instance eine neue Instanz statt eines Fensters in einer bestehenden. Prüfen Sie die eigene Hilfeausgabe der installierten Build, denn die verfügbaren Flags unterscheiden sich je nach Version.

Versuchen Sie nicht, dasselbe aktive Profil gleichzeitig zu öffnen, und behandeln Sie eine Warnung, dass das Profil in Benutzung sei, nicht als Anweisung, Sperrdateien zu löschen.

Starten Sie den Browser außerdem unter seinem gewöhnlichen Nicht-root-Benutzer. Die Netzwerkeinrichtung braucht oft administrative Rechte, und es ist verlockend, dem Browser dieselben zu geben, weil er Teil desselben Experiments ist. Der grafische Browser braucht sie nicht, und der Start als root erzeugt eine eigene Klasse von Profil- und Berechtigungsproblemen. Halten Sie Privileg und Netzwerkpfad als zwei unabhängige Entscheidungen.

Prüfen Sie, welcher Prozess den Verkehr trägt

Unter Linux ist der Netzwerk-Namespace eines Prozesses über seinen Namespace-Link sichtbar. Lesen Sie ihn für den Prozess, von dem Sie glauben, dass er die Anfrage stellt, und dann für den Prozess, der sie tatsächlich stellt.

readlink /proc/ACTUAL_PID/ns/net

Browser laufen mit mehreren Prozessen, deshalb zählt die Identität: Der Inhaltsprozess, der die Verbindung aufbaut, ist vielleicht nicht der, den Sie zuerst geprüft haben. Vergleichen Sie den Link mit dem beabsichtigten Namespace und bestätigen Sie mit einer frischen, harmlosen Anfrage, die Sie einer Instanz zuordnen können. Die Zuordnung ist der ganze Test. Wenn Sie nicht sagen können, welcher Prozess die Verbindung aufgebaut hat, haben Sie den Namespace nicht getestet.

Wenn der Namespace wirklich falsch ist

Manchmal ist der Starter tatsächlich gescheitert, und die neue Instanz startete im falschen Namespace. Prüfen Sie den Dienst oder Wrapper, der sie erzeugt hat, denn eine Unit oder ein Desktop-Eintrag kann den Namespace verlieren, wenn sie über einen Sitzungsbus neu ausgeführt wird. Testen Sie dann erneut aus einer Shell im richtigen Namespace, bevor Sie den Browser beschuldigen. Eine Variable nach der anderen ist der einzige Weg, das diagnostizierbar zu halten.

Einen Bildschirm zu teilen teilt keinen Resolver.

Wenn der Prozess im richtigen Namespace ist und die Namensauflösung weiterhin fehlschlägt,untersuchen Sie seine Resolver-Umgebung als separates Problem. Eine weitere Routing-Änderung kann eine Anfrage nicht verschieben, die an die falsche Instanz übergeben wurde, bevor sie überhaupt begann.

Ähnliche Artikel