Firefox starta i eit namespace overleverte URL-en til ein eksisterande instans

Ein kommando køyrer inne i VPN-namespacet, eit Firefox-vindauge dukkar opp, og sida forlèt likevel den vanlege tilkoplinga. Rutinoppsettet er truleg ikkje det første som må byggjast på nytt. Sjekk om kommandoen oppretta nettlesarinstansen du forventa, eller overleverte URL-en til ein som allereie køyrde ein annan stad. Den skilnaden forklarer resultatet i eitt steg og sparer ein time med nftables.

Teiknet er at vindauget dukkar opp med éin gong, utan kaldstart.

Eit nytt vindauge er ikkje ein ny instans

Skrivebordsprogram brukar rutinemessig ein eksisterande prosess om att. Ein startar inne i eitt nettverksnamespace flyttar ikkje ein allereie køyrande mottakar inn i det namespacet, fordi mottakaren aldri var ein del av oppstarten. Fjernstyringa til Firefox er knytt til profilar: start mot ein profil som allereie er i bruk overleverer argumenta til eigaren. Det nye vindauget er ekte; den nye nettverksvegen er det ikkje.

Privat nettlesing og alternativet for nytt vindauge er ikkje kontrollar for nettverksisolasjon.

Det er heller ikkje eit kommandolinjeflagg som berre påverkar vindauge-modus. Viss profilen er oppteken, går førespurnaden til prosessen som eig han, og den prosessen held på namespacet han starta i.

Tving ein separat instans på ein separat profil

Bruk ein eigen profil oppretta via den støtta profilflyten til nettlesaren, og start han eksplisitt med den profilen. I Firefox-bygg som støttar det, ber --new-instance om ein ny instans i staden for eit vindauge inne i ein eksisterande. Sjå hjelpeutdataa til det installerte bygget sjølv, fordi tilgjengelege flagg varierer etter versjon.

Ikkje prøv å opne den same aktive profilen samstundes, og ikkje handsam ei åtvaring om at profilen er i bruk som ein instruks om å slette låsefiler.

Køyr òg nettlesaren under sin vanlege ikkje-root-brukar. Nettverksoppsett treng ofte administrative rettar, og det er freistande å gje nettlesaren dei same fordi han er ein del av det same eksperimentet. Den grafiske nettlesaren treng dei ikkje, og å køyre han som root skaper ein eigen klasse av profil- og løyveproblem. Hald privilegium og nettverksveg som to uavhengige avgjerder.

Sjekk kva prosess som ber trafikken

På Linux er nettverksnamespacet til ein prosess synleg gjennom lenkja til namespacet. Les han for prosessen du trur sender førespurnaden, og deretter for prosessen som faktisk gjer det.

readlink /proc/ACTUAL_PID/ns/net

Nettlesarar køyrer fleire prosessar, så identitet betyr noko: innhaldsprosessen som opprettar tilkoplinga er kanskje ikkje den du undersøkte først. Samanlikn lenkja med namespacet du hadde til hensikt, og stadfest med ein fersk, ufarleg førespurnad som du kan tilskrive éin instans. Tilskrivinga er heile testen. Viss du ikkje kan seie kva prosess som oppretta tilkoplinga, har du ikkje testa namespacet.

Når namespacet verkeleg er feil

Nokre gonger feilar startaren faktisk, og den nye instansen startar i feil namespace. Sjekk tenesta eller wrapperen som skapte han, fordi ein unit eller ein skrivebordsoppføring kan miste namespacet når han blir køyrd på nytt gjennom ein sesjonsbuss. Test deretter på nytt frå ein shell inne i det rette namespacet før du klandrar nettlesaren. Éin variabel om gongen er den einaste måten dette blir verande diagnostiserbart på.

Å dele ein skjerm deler heller ikkje ein resolver.

Viss prosessen er i det rette namespacet og namneoppslag framleis feilar,undersøk resolver-miljøet hans som eit separat problem. Ei anna rutingendring kan ikkje flytte ein førespurnad som blei overlevert til feil instans før han i det heile byrja.