Firefox lansat într-un namespace a predat URL-ul unei instanțe existente

O comandă rulează în interiorul namespace-ului VPN, apare o fereastră Firefox, iar pagina tot pleacă pe conexiunea obișnuită. Configurarea rutării nu este probabil primul lucru care trebuie reconstruit. Verificați dacă comanda a creat instanța de browser pe care o așteptați sau a predat URL-ul uneia care rula deja în altă parte. Această distincție explică rezultatul într-un singur pas și economisește o oră de nftables.

Semnalul este că fereastra apare instantaneu, fără pornire la rece.

O fereastră nouă nu este o instanță nouă

Aplicațiile desktop refolosesc în mod obișnuit un proces existent. Un lansator dintr-un namespace de rețea nu mută un destinatar deja în execuție în acel namespace, pentru că destinatarul nu a făcut niciodată parte din lansare. Comportamentul de control de la distanță al Firefox este legat de profiluri: lansarea către un profil deja folosit predă argumentele proprietarului său. Fereastra nouă este reală; calea de rețea nouă nu este.

Navigarea privată și opțiunea de fereastră nouă nu sunt controale de izolare a rețelei.

Nu este nici un comutator de linie de comandă care afectează doar modul ferestrei. Dacă profilul este ocupat, cererea merge la procesul care îl deține, și acel proces păstrează namespace-ul cu care a început.

Forțați o instanță separată pe un profil separat

Folosiți un profil dedicat creat prin fluxul de lucru de profiluri acceptat al browserului și lansați-l explicit cu acel profil. În versiunile Firefox care acceptă acest lucru, --new-instance cere o instanță nouă în locul unei ferestre într-o instanță existentă. Verificați propria ieșire de ajutor a versiunii instalate, deoarece comutatoarele disponibile diferă în funcție de versiune.

Nu încercați să deschideți același profil activ simultan și nu tratați un avertisment că profilul este în uz ca pe o instrucțiune de a șterge fișierele de blocare.

Rulați browserul și sub utilizatorul său obișnuit care nu este root. Configurarea rețelei necesită adesea drepturi administrative, și este tentant să îi dați browserului aceleași drepturi pentru că face parte din același experiment. Browserul grafic nu are nevoie de ele, iar rularea lui ca root creează o clasă separată de probleme de profil și permisiuni. Țineți privilegiul și calea de rețea ca două decizii independente.

Verificați care proces transportă traficul

În Linux, namespace-ul de rețea al unui proces este vizibil prin legătura sa de namespace. Citiți-o pentru procesul care credeți că face cererea, apoi pentru procesul care o face cu adevărat.

readlink /proc/ACTUAL_PID/ns/net

Browserele rulează mai multe procese, așa că identitatea contează: procesul de conținut care realizează conexiunea poate să nu fie cel pe care l-ați inspectat primul. Comparați legătura cu namespace-ul intenționat și confirmați cu o cerere nouă și inofensivă pe care o puteți atribui unei singure instanțe. Atribuirea este întregul test. Dacă nu puteți spune care proces a realizat conexiunea, nu ați testat namespace-ul.

Când namespace-ul este într-adevăr greșit

Uneori lansatorul eșuează cu adevărat și instanța nouă pornește în namespace-ul greșit. Verificați serviciul sau wrapperul care a creat-o, pentru că o unitate sau o intrare de desktop poate pierde namespace-ul când este reexecutată printr-un bus de sesiune. Apoi testați din nou dintr-un shell în interiorul namespace-ului corect înainte de a da vina pe browser. O singură variabilă pe rând este singura cale ca acest lucru să rămână diagnosticabil.

Partajarea unui afișaj nu partajează nici un resolver.

Dacă procesul este în namespace-ul corect și rezolvarea numelor încă eșuează,investigați mediul său de resolver ca o problemă separată. Nicio altă schimbare de rutare nu poate muta o cerere care a fost predată instanței greșite înainte ca ea să fi început.