Firefox startet i et namespace overlod URL’en til en eksisterende instans

En kommando kører inde i VPN-namespacet, et Firefox-vindue dukker op, og siden forlader stadig den almindelige forbindelse. Routingopsætningen er sandsynligvis ikke det første, der skal genopbygges. Kontroller, om kommandoen oprettede den browserinstans, du forventede, eller overdrog URL’en til en, der allerede kørte et andet sted. Den forskel forklarer resultatet i ét trin og sparer en time med nftables.

Tegnet er, at vinduet dukker op med det samme, uden kold start.

Et nyt vindue er ikke en ny instans

Skrivebordsprogrammer genbruger rutinemæssigt en eksisterende proces. En starter inde i ét netværksnamespace flytter ikke en allerede kørende modtager ind i det namespace, fordi modtageren aldrig var en del af opstarten. Firefox’ fjernstyringsadfærd er knyttet til profiler: start mod en profil, der allerede er i brug, overdrager argumenterne til ejeren. Det nye vindue er ægte; den nye netværksvej er ikke.

Privat browsing og muligheden for nyt vindue er ikke kontrolmidler til netværksisolering.

Det er en kommandolinjeflag, der kun påvirker vinduestilstanden, heller ikke. Hvis profilen er optaget, går anmodningen til den proces, der ejer den, og den proces beholder det namespace, den startede i.

Tving en separat instans på en separat profil

Brug en dedikeret profil oprettet via browserens understøttede profilworkflow, og start den udtrykkeligt med den profil. På Firefox-builds, der understøtter det, beder --new-instance om en ny instans i stedet for et vindue inde i en eksisterende. Se den installerede builds egen hjælpeoutput, fordi de tilgængelige flag varierer efter version.

Forsøg ikke at åbne den samme aktive profil samtidigt, og behandl ikke en advarsel om, at profilen er i brug, som en instruks om at slette låsefiler.

Kør også browseren under dens almindelige ikke-root-bruger. Netværksopsætning kræver ofte administrative rettigheder, og det er fristende at give browseren de samme, fordi den er en del af det samme eksperiment. Den grafiske browser har ikke brug for dem, og at køre den som root skaber en særlig klasse af profil- og tilladelsesproblemer. Hold privilegium og netværksvej som to uafhængige beslutninger.

Kontroller, hvilken proces der bærer trafikken

På Linux er en proces’ netværksnamespace synligt gennem dens namespacelink. Læs det for den proces, du mener sender anmodningen, og derefter for den proces, der faktisk gør det.

readlink /proc/ACTUAL_PID/ns/net

Broweere kører flere processer, så identitet betyder noget: den indholdsproces, der opretter forbindelsen, er måske ikke den, du undersøgte først. Sammenlign linket med det namespace, du havde til hensigt, og bekræft med en frisk, uskadelig anmodning, som du kan tilskrive én instans. Tildelingen er hele testen. Hvis du ikke kan sige, hvilken proces der oprettede forbindelsen, har du ikke testet namespacet.

Når namespacet virkelig er forkert

Nogle gange fejler starteren faktisk, og den nye instans starter i det forkerte namespace. Kontroller den tjeneste eller wrapper, der startede den, fordi en unit eller et skrivebordselement kan miste namespacet, når det genudføres gennem en sessionsbus. Test derefter igen fra en shell inde i det korrekte namespace, før du bebrejder browseren. Én variabel ad gangen er den eneste måde, dette forbliver diagnosticerbart på.

At dele en skærm deler heller ikke en resolver.

Hvis processen er i det rigtige namespace, og navneopløsningen stadig fejler,undersøg dens resolver-miljø som et separat problem. En anden routingændring kan ikke flytte en anmodning, der blev overdraget til den forkerte instans, før den overhovedet begyndte.