Firefox startad i ett namespace lämnade över URL:en till en befintlig instans

Ett kommando körs inne i VPN-namespacet, ett Firefox-fönster dyker upp, och sidan lämnar ändå datorn via den vanliga anslutningen. Routinginställningen är förmodligen inte det första som behöver byggas om. Kontrollera om kommandot skapade den webbläsarinstans du förväntade dig, eller lämnade över URL:en till en som redan körde någon annanstans. Den skillnaden förklarar resultatet i ett steg och sparar en timme nftables.

Tecknet är att fönstret dyker upp direkt, utan kallstart.

Ett nytt fönster är inte en ny instans

Skrivbordsprogram återanvänder rutinmässigt en befintlig process. En startare inne i ett nätverksnamespace flyttar inte en redan körande mottagare till det namespacet, eftersom mottagaren aldrig var en del av starten. Firefox fjärrstyrningsbeteende hänger samman med profiler: start mot en profil som redan används lämnar över argumenten till ägaren. Det nya fönstret är verkligt; den nya nätverksvägen är det inte.

Privat surfning och alternativet för nytt fönster är inte kontroller för nätverksisolering.

Det gäller inte heller en kommandoradsflagga som bara påverkar fönsterläget. Om profilen är upptagen går begäran till processen som äger den, och den processen behåller det namespace den startade i.

Tvinga en separat instans på en separat profil

Använd en dedikerad profil som skapats via webbläsarens stödda profilflöde och starta den uttryckligen med den profilen. I Firefox-byggen som stöder det begär --new-instance en ny instans i stället för ett fönster i en befintlig. Titta på hjälputdata från det installerade bygget självt, eftersom tillgängliga flaggor varierar mellan versioner.

Försök inte öppna samma aktiva profil samtidigt, och behandla inte en varning om att profilen används som en instruktion att radera låsfilerna.

Kör också webbläsaren under sin vanliga icke-root-användare. Nätverkskonfiguration kräver ofta administrativa rättigheter, och det är frestande att ge webbläsaren samma rättigheter eftersom den är en del av samma experiment. Den grafiska webbläsaren behöver dem inte, och att köra den som root skapar en egen klass av profil- och behörighetsproblem. Håll behörighet och nätverksväg som två oberoende beslut.

Kontrollera vilken process som bär trafiken

På Linux är en process nätverksnamespace synligt via dess namespacelänk. Läs den för processen du tror gör begäran, och sedan för processen som faktiskt gör det.

readlink /proc/ACTUAL_PID/ns/net

Webbläsare kör flera processer, så identitet spelar roll: innehållsprocessen som skapar anslutningen är kanske inte den du granskade först. Jämför länken med det namespace du avsåg och bekräfta med en färsk, ofarlig begäran som du kan tillskriva en enda instans. Tillskrivningen är hela testet. Om du inte kan säga vilken process som skapade anslutningen har du inte testat namespacet.

När namespacet verkligen är fel

Ibland misslyckas startaren faktiskt och den nya instansen startar i fel namespace. Kontrollera tjänsten eller omslaget som skapade den, eftersom en unit eller en skrivbordspost kan förlora namespacet när den körs igen via en sessionsbuss. Testa sedan igen från ett skal inne i rätt namespace innan du skyller på webbläsaren. En variabel i taget är det enda sättet att hålla detta diagnostiserbart.

Att dela en skärm delar inte heller en resolver.

Om processen är i rätt namespace och namnmatchningen fortfarande misslyckas,undersök dess resolver-miljö som ett separat problem. Ingen annan routingändring kan flytta en begäran som lämnades över till fel instans innan den ens började.