Firefox gestart in een namespace gaf de URL door aan een bestaande instantie

Een opdracht draait in de VPN-namespace, er verschijnt een Firefox-venster, en de pagina vertrekt toch via de gewone verbinding. De routeringsopzet is waarschijnlijk niet het eerste dat opnieuw moet worden opgebouwd. Controleer of de opdracht de browserinstantie heeft gemaakt die u verwachtte, of de URL heeft doorgegeven aan een exemplaar dat al ergens anders draaide. Dat onderscheid verklaart het resultaat in één stap en bespaart een uur nftables.

Het teken is dat het venster meteen verschijnt, zonder koude start.

Een nieuw venster is geen nieuwe instantie

Desktopapplicaties hergebruiken routineus een bestaand proces. Een launcher binnen één netwerknamespace verplaatst een al draaiende ontvanger niet naar die namespace, omdat de ontvanger nooit deel uitmaakte van de start. Het remote-gedrag van Firefox is aan profielen gekoppeld: starten tegen een profiel dat al in gebruik is, geeft de argumenten door aan de eigenaar. Het nieuwe venster is echt; het nieuwe netwerkpad niet.

Privénavigatie en de optie voor een nieuw venster zijn geen controles voor netwerkisolatie.

Dat geldt ook niet voor een opdrachtregelvlag die alleen de venstermodus beïnvloedt. Als het profiel bezet is, gaat het verzoek naar het proces dat het bezit, en dat proces behoudt de namespace waarin het begon.

Dwing een aparte instantie op een apart profiel af

Gebruik een toegeweid profiel dat is gemaakt via de ondersteunde profielworkflow van de browser, en start het expliciet met dat profiel. In Firefox-builds die dat ondersteunen, vraagt --new-instance om een nieuwe instantie in plaats van een venster binnen een bestaande. Bekijk de eigen help-uitvoer van de geïnstalleerde build, want de beschikbare vlaggen verschillen per versie.

Probeer hetzelfde actieve profiel niet tegelijkertijd te openen, en behandel een waarschuwing dat het profiel in gebruik is niet als een instructie om vergrendelingsbestanden te verwijderen.

Draai de browser ook onder zijn gewone niet-rootgebruiker. Netwerkconfiguratie vereist vaak beheerdersrechten, en het is verleidelijk om de browser dezelfde te geven omdat hij deel uitmaakt van hetzelfde experiment. De grafische browser heeft ze niet nodig, en hem als root draaien creëert een aparte klasse van profiel- en rechtenproblemen. Houd privilege en netwerkpad als twee onafhankelijke beslissingen.

Controleer welk proces het verkeer draagt

Op Linux is de netwerknamespace van een proces zichtbaar via zijn namespacelink. Lees die voor het proces waarvan u denkt dat het het verzoek doet, en daarna voor het proces dat het echt doet.

readlink /proc/ACTUAL_PID/ns/net

Browsers draaien meerdere processen, dus identiteit is belangrijk: het inhoudsproces dat de verbinding maakt is misschien niet degene die u eerst hebt onderzocht. Vergelijk de link met de namespace die u bedoelde, en bevestig met een vers, onschadelijk verzoek dat u aan één instantie kunt toeschrijven. De toeschrijving is de hele test. Als u niet kunt zeggen welk proces de verbinding heeft gemaakt, hebt u de namespace niet getest.

Wanneer de namespace echt verkeerd is

Soms faalt de launcher echt en begint de nieuwe instantie in de verkeerde namespace. Controleer de dienst of wrapper die hem heeft gestart, want een unit of een bureaubladvermelding kan de namespace verliezen wanneer die opnieuw wordt uitgevoerd via een sessiebus. Test daarna opnieuw vanuit een shell in de juiste namespace voordat u de browser de schuld geeft. Eén variabele tegelijk is de enige manier waarop dit diagnosabel blijft.

Een scherm delen deelt ook geen resolver.

Als het proces in de juiste namespace zit en naamresolutie nog steeds mislukt,onderzoek dan zijn resolver-omgeving als een apart probleem. Een andere routeringswijziging kan een verzoek niet verplaatsen dat aan de verkeerde instantie is doorgegeven voordat het überhaupt begon.