Firefox avviato in un namespace ha consegnato l’URL a un’istanza esistente

Un comando viene eseguito all’interno del namespace della VPN, appare una finestra di Firefox e la pagina esce comunque dalla connessione ordinaria. La configurazione del routing probabilmente non è la prima cosa da ricostruire. Verificate se il comando ha creato l’istanza del browser che vi aspettavate o se ha consegnato l’URL a una che era già in esecuzione altrove. Questa distinzione spiega il risultato in un solo passaggio e risparmia un’ora di nftables.

L’indizio è che la finestra appare all’istante, senza avvio a freddo.

Una nuova finestra non è una nuova istanza

Le applicazioni desktop riutilizzano abitualmente un processo esistente. Un launcher dentro un namespace di rete non sposta un destinatario già in esecuzione in quel namespace, perché il destinatario non è mai stato parte dell’avvio. Il comportamento di controllo remoto di Firefox è legato ai profili: avviare contro un profilo già in uso consegna gli argomenti al suo proprietario. La nuova finestra è reale; il nuovo percorso di rete no.

La navigazione privata e l’opzione nuova finestra non sono controlli di isolamento di rete.

Non lo è neppure un flag da riga di comando che influisce solo sulla modalità finestra. Se il profilo è occupato, la richiesta va al processo che lo possiede, e quel processo mantiene il namespace con cui è partito.

Forzate un’istanza separata su un profilo separato

Usate un profilo dedicato creato tramite il flusso di lavoro dei profili supportato dal browser e avviatelo esplicitamente con quel profilo. Nelle build di Firefox che lo supportano, --new-instance chiede una nuova istanza invece di una finestra dentro una esistente. Consultate l’output di aiuto della build installata, perché i flag disponibili variano in base alla versione.

Non provate ad aprire lo stesso profilo attivo contemporaneamente e non trattate un avviso di profilo in uso come un’istruzione a eliminare i file di blocco.

Eseguite anche il browser con il suo utente abituale non root. La configurazione di rete spesso richiede privilegi amministrativi, ed è tentante darli al browser perché fa parte dello stesso esperimento. Il browser grafico non ne ha bisogno, ed eseguirlo come root crea una classe separata di problemi di profilo e permessi. Tenete privilegio e percorso di rete come due decisioni indipendenti.

Verificate quale processo trasporta il traffico

Su Linux, il namespace di rete di un processo è visibile tramite il suo collegamento al namespace. Leggetelo per il processo che credete stia effettuando la richiesta, poi per il processo che la effettua davvero.

readlink /proc/ACTUAL_PID/ns/net

I browser eseguono diversi processi, quindi l’identità conta: il processo di contenuto che stabilisce la connessione potrebbe non essere quello che avete ispezionato per primo. Confrontate il collegamento con il namespace che intendevate e confermate con una richiesta nuova e innocua che potete attribuire a una sola istanza. L’attribuzione è tutta la prova. Se non sapete dire quale processo ha stabilito la connessione, non avete verificato il namespace.

Quando il namespace è davvero sbagliato

A volte il launcher fallisce davvero e la nuova istanza parte nel namespace sbagliato. Controllate il servizio o il wrapper che l’ha generata, perché un’unità o una voce del desktop può perdere il namespace quando viene rieseguita attraverso un bus di sessione. Poi provate di nuovo da una shell dentro il namespace corretto prima di dare la colpa al browser. Una variabile alla volta è l’unico modo perché resti diagnosticabile.

Condividere uno schermo non condivide nemmeno un resolver.

Se il processo è nel namespace corretto e la risoluzione dei nomi fallisce ancora,esaminate il suo ambiente resolver come un problema separato. Nessun altro cambio di routing può spostare una richiesta che è stata consegnata all’istanza sbagliata prima ancora che iniziasse.