Ukaz se izvaja znotraj namespacea VPN, pojavi se okno Firefoxa in stran vseeno odide po običajni povezavi. Nastavitev usmerjanja verjetno ni prva stvar, ki jo je treba znova zgraditi. Preverite, ali je ukaz ustvaril pričakovano instanco brskalnika ali predal URL tisti, ki je že tekla kje drugje. Ta razlika pojasni rezultat v enem koraku in prihrani uro z nftables.

Znak je, da se okno pojavi takoj, brez hladnega zagona.

Novo okno ni nova instanca

Namizne aplikacije rutinsko znova uporabijo obstoječi proces. Zaganjalnik v enem omrežnem namespaceu ne premakne že delujočega prejemnika v ta namespace, ker prejemnik nikoli ni bil del zagona. Vedenje Firefoxa pri oddaljenem upravljanju je povezano s profili: zagon proti profilu, ki je že v uporabi, preda argumente njegovemu lastniku. Novo okno je resnično; nova omrežna pot ni.

Zasebno brskanje in možnost novega okna nista sredstvi za omrežno izolacijo.

To ni niti stikalo ukazne vrstice, ki vpliva samo na način okna. Če je profil zaseden, zahteva gre procesu, ki ga ima v lasti, in ta proces obdrži namespace, v katerem se je začel.

Prisilite ločeno instanco na ločenem profilu

Uporabite namenski profil, ustvarjen s podprtim delovnim tokom profilov brskalnika, in ga zaženite izrecno s tem profilom. V gradnjah Firefoxa, ki to podpirajo, --new-instance zahteva novo instanco namesto okna v obstoječi. Poglejte lasten izpis pomoči nameščene gradnje, ker se razpoložljiva stikala razlikujejo glede na različico.

Ne poskušajte hkrati odpreti istega živega profila in opozorila, da je profil v uporabi, ne jemljite kot navodila za brisanje zaklepnih datotek.

Brskalnik zaženite tudi pod njegovim običajnim uporabnikom brez root. Omrežna nastavitev pogosto potrebuje skrbniške pravice, in mamljivo je dati brskalniku iste, ker je del istega poskusa. Grafični brskalnik jih ne potrebuje, zagon kot root pa ustvari ločen razred težav s profilom in dovoljenji. Držite privilegij in omrežno pot kot dve neodvisni odločitvi.

Preverite, kateri proces nosi promet

V Linuxu je omrežni namespace procesa viden prek njegove povezave do namespacea. Preberite jo za proces, za katerega menite, da pošilja zahtevo, nato pa za proces, ki jo res pošilja.

readlink /proc/ACTUAL_PID/ns/net

Brskalniki izvajajo več procesov, zato je identiteta pomembna: vsebinski proces, ki vzpostavi povezavo, morda ni tisti, ki ste ga preverili prvega. Primerjajte povezavo z načrtovanim namespaceom in potrdite s svežo, nedolžno zahtevo, ki jo lahko pripišete eni instanci. Pripis je celoten preizkus. Če ne morete povedati, kateri proces je vzpostavil povezavo, namespacea niste preizkusili.

Ko je namespace res napačen

Včasih se zaganjalnik res ne uspe in nova instanca se začne v napačnem namespaceu. Preverite storitev ali ovoj, ki jo je ustvaril, ker enota ali vnos na namizju lahko izgubi namespace, ko se znova izvede prek sejnega vodila. Nato znova preizkusite iz lupine znotraj pravega namespacea, preden obtožite brskalnik. Ena spremenljivka naenkrat je edini način, da to ostane diagnosticirljivo.

Deljenje zaslona ne deli tudi resolverja.

Če je proces v pravem namespaceu in razreševanje imen še vedno ne uspe,raziščite njegovo okolje resolverja kot ločen problem. Nobena druga sprememba usmerjanja ne more premakniti zahteve, ki je bila predana napačni instanci, še preden se je sploh začela.

Sorodni članki