Firefox startet i et namespace overleverte URL-en til en eksisterende instans

En kommando kjører inne i VPN-namespacet, et Firefox-vindu dukker opp, og siden forlater likevel den vanlige tilkoblingen. Rutingoppsettet er sannsynligvis ikke det første som må bygges på nytt. Sjekk om kommandoen opprettet nettleserinstansen du forventet, eller overleverte URL-en til en som allerede kjørte et annet sted. Den forskjellen forklarer resultatet i ett trinn og sparer en time med nftables.

Tegnet er at vinduet dukker opp umiddelbart, uten kaldstart.

Et nytt vindu er ikke en ny instans

Skrivebordsprogrammer gjenbruker rutinemessig en eksisterende prosess. En starter inne i ett nettverksnamespace flytter ikke en allerede kjørende mottaker inn i det namespacet, fordi mottakeren aldri var en del av oppstarten. Firefox’ fjernstyringsatferd er knyttet til profiler: start mot en profil som allerede er i bruk overleverer argumentene til eieren. Det nye vinduet er ekte; den nye nettverksveien er det ikke.

Privat nettlesing og alternativet for nytt vindu er ikke kontroller for nettverksisolasjon.

Det er heller ikke et kommandolinjeflagg som bare påvirker vindusmodus. Hvis profilen er opptatt, går forespørselen til prosessen som eier den, og den prosessen beholder namespacet den startet i.

Tving en separat instans på en separat profil

Bruk en dedikert profil opprettet via nettleserens støttede profilflyt, og start den eksplisitt med den profilen. I Firefox-bygg som støtter det, ber --new-instance om en ny instans i stedet for et vindu inne i en eksisterende. Se hjelpeutdataene til det installerte bygget selv, fordi tilgjengelige flagg varierer etter versjon.

Ikke prøv å åpne den samme aktive profilen samtidig, og ikke behandle en advarsel om at profilen er i bruk som en instruks om å slette låsefiler.

Kjør også nettleseren under sin vanlige ikke-root-bruker. Nettverksoppsett trenger ofte administrative rettigheter, og det er fristende å gi nettleseren de samme fordi den er en del av det samme eksperimentet. Den grafiske nettleseren trenger dem ikke, og å kjøre den som root skaper en egen klasse av profil- og tillatelsesproblemer. Hold privilegium og nettverksvei som to uavhengige beslutninger.

Sjekk hvilken prosess som bærer trafikken

På Linux er et prosess’ nettverksnamespace synlig gjennom lenken til namespacet. Les den for prosessen du tror sender forespørselen, og deretter for prosessen som faktisk gjør det.

readlink /proc/ACTUAL_PID/ns/net

Nettlesere kjører flere prosesser, så identitet betyr noe: innholdsprosessen som oppretter tilkoblingen er kanskje ikke den du undersøkte først. Sammenlign lenken med namespacet du hadde til hensikt, og bekreft med en fersk, ufarlig forespørsel som du kan tilskrive én instans. Tilskrivningen er hele testen. Hvis du ikke kan si hvilken prosess som opprettet tilkoblingen, har du ikke testet namespacet.

Når namespacet virkelig er feil

Noen ganger feiler starteren faktisk, og den nye instansen starter i feil namespace. Sjekk tjenesten eller wrapperen som skapte den, fordi en unit eller en skrivebordsoppføring kan miste namespacet når den kjøres på nytt gjennom en sesjonsbuss. Test deretter på nytt fra en shell inne i det riktige namespacet før du klandrer nettleseren. Én variabel om gangen er den eneste måten dette forblir diagnostiserbart på.

Å dele en skjerm deler heller ikke en resolver.

Hvis prosessen er i det riktige namespacet og navneoppslag fortsatt feiler,undersøk resolver-miljøet dens som et separat problem. En annen rutingendring kan ikke flytte en forespørsel som ble overlevert til feil instans før den i det hele tatt begynte.