Una ordre s’executa dins de l’espai de noms de la VPN, apareix una finestra del Firefox i la pàgina continua sortint per la connexió ordinària. La configuració d’encaminament probablement no és el primer que cal reconstruir. Comproveu si l’ordre ha creat la instància del navegador que esperàveu o si ha passat l’URL a una que ja s’executava en un altre lloc. Aquesta distinció explica el resultat en un sol pas i estalvia una hora de nftables.

La pista és que la finestra apareix a l’instant, sense cap arrencada en fred.

Una finestra nova no és una instància nova

Les aplicacions d’escriptori reutilitzen habitualment un procés existent. Un llançador dins d’un espai de noms de xarxa no trasllada un destinatari que ja s’executa a aquest espai de noms, perquè el destinatari mai no formava part del llançament. El comportament del Firefox en remot es basa en perfils: engegar contra un perfil ja en ús lliura els arguments al seu propietari. La finestra nova és real; el camí de xarxa nou no ho és.

La navegació privada i l’opció de finestra nova no són controls d’aïllament de xarxa.

Tampoc no ho és cap opció de línia d’ordres que només afecti el mode de finestra. Si el perfil està ocupat, la petició va al procés que el posseeix, i aquell procés conserva l’espai de noms amb què va començar.

Forceu una instància separada en un perfil a part

Feu servir un perfil dedicat creat amb el flux de treball de perfils compatible del navegador i engegueu-lo explícitament amb aquell perfil. A les compilacions del Firefox que ho admeten, --new-instance demana una instància nova en lloc d’una finestra dins d’una d’existent. Consulteu la sortida d’ajuda de la compilació instal·lada, perquè les opcions disponibles varien segons la versió.

No intenteu obrir el mateix perfil viu alhora ni tracteu un avís de perfil en ús com una instrucció per esborrar fitxers de bloqueig.

Executeu el navegador també amb el seu usuari habitual sense root. La configuració de xarxa sovint necessita drets administratius, i és temptador donar-los al navegador perquè forma part del mateix experiment. El navegador gràfic no els necessita, i executar-lo com a root crea una classe a part de problemes de perfil i permisos. Manteniu el privilegi i el camí de xarxa com dues decisions independents.

Comproveu quin procés transporta el trànsit

A Linux, l’espai de noms de xarxa d’un procés és visible a través del seu enllaç d’espai de noms. Llegiu-lo per al procés que creieu que fa la petició i després per al procés que realment la fa.

readlink /proc/ACTUAL_PID/ns/net

Els navegadors executen diversos processos, així que la identitat importa: el procés de contingut que fa la connexió pot no ser el que heu inspeccionat primer. Compareu l’enllaç amb l’espai de noms que volíeu i confirmeu-ho amb una petició nova i innòcua que pugueu atribuir a una sola instància. L’atribució és tota la prova. Si no podeu dir quin procés ha fet la connexió, no heu provat l’espai de noms.

Quan l’espai de noms realment és incorrecte

De vegades el llançador falla de debò i la instància nova comença en l’espai de noms equivocat. Comproveu el servei o l’embolcall que l’ha generat, perquè una unitat o una entrada d’escriptori pot perdre l’espai de noms quan es torna a executar a través del bus de sessió. Després torneu a provar des d’una shell dins de l’espai de noms correcte abans de culpar el navegador. Una variable alhora és l’única manera que això segueixi sent diagnosticable.

Compartir una pantalla tampoc no comparteix un resolutor.

Si el procés és a l’espai de noms correcte i la resolució de noms encara falla,investigueu el seu entorn de resolutor com un problema a part. Cap altre canvi d’encaminament no pot traslladar una petició que es va lliurar a la instància equivocada abans que comencés.

Articles relacionats