Firefox in ’n naamruimte begin en die URL aan ’n bestaande instansie oorhandig

’n Opdrag loop binne die VPN-naamruimte, ’n Firefox-venster verskyn, en die bladsy verlaat steeds die gewone verbinding. Die roete-opset is waarskynlik nie die eerste ding wat herbou moet word nie. Kyk of die opdrag die browser-instansie geskep het wat jy verwag het, of die URL oorhandig het aan een wat al elders geloop het. Daardie onderskeid verduidelik die uitslag in een stap en spaar ’n uur se nftables.

Die teken is dat die venster dadelik verskyn, sonder ’n koue begin.

’n Nuwe venster is nie ’n nuwe instansie nie

Werkskermprogramme hergebruik gereeld ’n bestaande proses. ’n Launcher binne een netwerk-naamruimte skuif nie ’n reeds lopende ontvanger na daardie naamruimte nie, want die ontvanger was nooit deel van die bekendstelling nie. Firefox se afstandbeheer-gedrag hou verband met profiele: as jy teen ’n profiel begin wat al in gebruik is, word die argumente aan die eienaar oorhandig. Die nuwe venster is eg, die nuwe netwerkpad is nie.

Privaat blaai en die nuwe-venster-opsie is nie netwerk-isolasie-beheermiddels nie.

Dit geld ook nie vir ’n opdragreël-vlag wat net die venstermodus raak nie. As die profiel beset is, gaan die versoek na die proses wat dit besit, en daardie proses hou die naamruimte waarin dit begin het.

Dwing ’n aparte instansie op ’n aparte profiel af

Gebruik ’n toegewyde profiel wat deur die browser se ondersteunde profielwerkvloei geskep is, en begin dit dan uitdruklik met daardie profiel. Op Firefox-bouwerke wat dit ondersteun, vra --new-instance ’n nuwe instansie eerder as ’n venster binne ’n bestaande een. Kyk na die geïnstalleerde bou se eie hulpuitset, want die beskikbare vlae verskil per weergawe.

Moenie probeer om dieselfde lewende profiel gelyktydig oop te maak nie, en moenie ’n profiel-in-gebruik-waarskuwing as ’n opdrag beskou om sluitlêers te verwyder nie.

Begin die browser ook onder sy gewone nie-root-gebruiker. Netwerkopset het dikwels administratiewe regte nodig, en dit is aanloklik om die browser dieselfde te gee omdat dit deel van dieselfde eksperiment is. Die grafiese browser het dit nie nodig nie, en om dit as root te begin skep ’n aparte klas profiel- en toestemmingsprobleme. Hou voorreg en netwerkpad as twee onafhanklike besluite.

Kyk watter proses die verkeer dra

Op Linux is ’n proses se netwerk-naamruimte sigbaar deur sy naamruimte-skakel. Lees dit vir die proses wat jy dink die versoek doen, en dan vir die proses wat dit werklik doen.

readlink /proc/ACTUAL_PID/ns/net

Browsers loop verskeie prosesse, so identiteit maak saak: die inhoudproses wat die verbinding maak, is dalk nie die een wat jy eerste ondersoek het nie. Vergelyk die skakel met die naamruimte wat jy bedoel het, en bevestig met ’n vars, onskadelike versoek wat jy aan een instansie kan toeskryf. Toeskrywing is die hele toets. As jy nie kan sê watter proses die verbinding gemaak het nie, het jy nie die naamruimte getoets nie.

Wanneer die naamruimte werklik verkeerd is

Soms het die launcher werklik gefaal en die nuwe instansie het in die verkeerde naamruimte begin. Kyk na die diens of wikkel wat dit geskep het, want ’n eenheid of ’n lessenaarinvoer kan die naamruimte verloor wanneer dit deur ’n sessiebus herbegin. Toets dan weer vanuit ’n skulp binne die korrekte naamruimte voordat jy die browser blameer. Een veranderlike op ’n slag is die enigste manier waarop dit diagnoseerbaar bly.

Om ’n skerm te deel deel nie ’n resolver nie.

As die proses in die regte naamruimte is en naamresolusie steeds misluk,ondersoek sy resolver-omgewing as ’n aparte probleem. ’n Verdere roete-verandering kan nie ’n versoek verskuif wat aan die verkeerde instansie oorhandig is voordat dit ooit begin het nie.