Firefox lanĉita en namespace transdonis la URL-on al ekzistanta instanco

Komando kuras ene de la VPN-namespace, fenestro de Firefox aperas, kaj la paĝo tamen eliras per la ordinara konekto. La enkursiga agordo verŝajne ne estas la unua afero rekonstruenda. Kontrolu, ĉu la komando kreis la retumilan instancon, kiun vi atendis, aŭ transdonis la URL-on al unu, kiu jam kuris aliloke. Tiu distingo klarigas la rezulton en unu paŝo kaj ŝparas horon da nftables.

La signo estas, ke la fenestro aperas tuj, sen malvarma starto.

Nova fenestro ne estas nova instanco

Labortablaj aplikaĵoj rutine reuzas ekzistantan procezon. Lanĉilo ene de unu reta namespace ne movas jam kurantan ricevanton en tiun namespace, ĉar la ricevanto neniam estis parto de la lanĉo. La fora regado de Firefox rilatas al profiloj: lanĉo kontraŭ jam uzata profilo transdonas la argumentojn al ĝia posedanto. La nova fenestro estas reala; la nova reta vojo ne.

Privata retumado kaj la elekto de nova fenestro ne estas regiloj de reta izolado.

Ankaŭ ne estas tia komandlinia flago, kiu influas nur la fenestran reĝimon. Se la profilo estas okupata, la peto iras al la procezo, kiu posedas ĝin, kaj tiu procezo konservas la namespace, en kiu ĝi komenciĝis.

Devigu apartan instancon en aparta profilo

Uzu dediĉitan profilon kreitan per la subtenata profilflujo de la retumilo, kaj lanĉu ĝin eksplicite kun tiu profilo. En Firefox-konstruoj, kiuj subtenas tion, --new-instance petas novan instancon anstataŭ fenestron ene de ekzistanta. Kontrolu la propan helpeliron de la instalita konstruo, ĉar la disponeblaj flagoj varias laŭ versio.

Ne provu malfermi la saman vivan profilon samtempe, kaj ne traktu averton, ke profilo estas en uzo, kiel instrukciom forigi ŝlosilajn dosierojn.

Lanĉu la retumilon ankaŭ sub ĝia ordinara ne-root uzanto. Reta agordo ofte bezonas administrajn rajtojn, kaj estas tentate doni al la retumilo la samajn, ĉar ĝi estas parto de la sama eksperimento. La grafika retumilo ne bezonas ilin, kaj lanĉi ĝin kiel root kreas apartan klason de profilaj kaj permesaj problemoj. Tenu privilegion kaj retan vojon kiel du sendependajn decidojn.

Kontrolu, kiu procezo portas la trafikon

En Linux, la reta namespace de procezo estas videbla per ĝia namespace-ligo. Legu ĝin por la procezo, kiun vi kredas fari la peton, kaj poste por la procezo, kiu efektive faras ĝin.

readlink /proc/ACTUAL_PID/ns/net

Retumiloj funkciigas plurajn procezojn, do identeco gravas: la enhavprocezo, kiu faras la konekton, eble ne estas tiu, kiun vi unue inspektis. Komparu la ligon kun la namespace, kiun vi intencis, kaj konfirmu per freŝa, senkulpa peto, kiun vi povas atribui al unu instanco. La atribuo estas la tuta testo. Se vi ne povas diri, kiu procezo faris la konekton, vi ne testis la namespace.

Kiam la namespace vere estas malĝusta

Iam la lanĉilo vere fiaskas kaj la nova instanco komenciĝas en la malĝusta namespace. Kontrolu la servon aŭ ĉirkaŭaĵon, kiu ĝin naskis, ĉar unuo aŭ labortabla ero povas perdi la namespace, kiam ĝi reekzekutiĝas tra sesia buso. Poste testu denove el ŝelo ene de la ĝusta namespace antaŭ ol kulpigi la retumilon. Unu variablo samtempe estas la sola maniero konservi ĉi tion diagnozebla.

Kunhavigi ekranon ankaŭ ne kunhavigas resolver.

Se la procezo estas en la ĝusta namespace kaj nomtraduko ankoraŭ fiaskas,esploru ĝian resolver-medion kiel apartan problemon. Neniu alia enkursiga ŝanĝo povas translokigi peton, kiu estis transdonita al la malĝusta instanco antaŭ ol ĝi eĉ komenciĝis.