Um comando corre dentro do namespace da VPN, aparece uma janela do Firefox e a página continua a sair pela ligação normal. A configuração do encaminhamento provavelmente não é a primeira coisa a reconstruir. Verifique se o comando criou a instância do navegador que esperava ou se entregou o URL a uma que já estava a correr noutro sítio. Essa distinção explica o resultado num único passo e poupa uma hora de nftables.

O sinal é que a janela aparece de imediato, sem arranque a frio.

Uma janela nova não é uma instância nova

As aplicações de ambiente de trabalho reutilizam rotineiramente um processo existente. Um lançador dentro de um namespace de rede não move um destinatário já em execução para esse namespace, porque o destinatário nunca fez parte do arranque. O comportamento de controlo remoto do Firefox está associado a perfis: lançar contra um perfil já em uso entrega os argumentos ao seu proprietário. A janela nova é real; o caminho de rede novo não é.

A navegação privada e a opção de janela nova não são controlos de isolamento de rede.

Também não é uma opção de linha de comandos que só afete o modo de janela. Se o perfil estiver ocupado, o pedido vai para o processo que o possui, e esse processo mantém o namespace com que começou.

Force uma instância separada num perfil separado

Use um perfil dedicado criado através do fluxo de trabalho de perfis suportado pelo navegador e lance-o explicitamente com esse perfil. Nas compilações do Firefox que o suportam, --new-instance pede uma instância nova em vez de uma janela dentro de uma existente. Consulte a própria saída de ajuda da compilação instalada, porque as opções disponíveis variam consoante a versão.

Não tente abrir o mesmo perfil ativo em simultâneo e não trate um aviso de perfil em uso como uma instrução para apagar os ficheiros de bloqueio.

Execute também o navegador com o seu utilizador habitual sem root. A configuração de rede precisa frequentemente de direitos administrativos, e é tentador dar os mesmos ao navegador porque faz parte da mesma experiência. O navegador gráfico não precisa deles, e executá-lo como root cria uma classe separada de problemas de perfil e permissões. Mantenha o privilégio e o caminho de rede como duas decisões independentes.

Verifique que processo transporta o tráfego

No Linux, o namespace de rede de um processo é visível através da sua ligação ao namespace. Leia-a para o processo que acredita estar a fazer o pedido e depois para o processo que realmente o faz.

readlink /proc/ACTUAL_PID/ns/net

Os navegadores executam vários processos, por isso a identidade importa: o processo de conteúdo que estabelece a ligação pode não ser o que inspecionou primeiro. Compare a ligação com o namespace que pretendia e confirme com um pedido novo e inofensivo que possa atribuir a uma só instância. A atribuição é todo o teste. Se não conseguir dizer que processo estabeleceu a ligação, não testou o namespace.

Quando o namespace está mesmo errado

Por vezes o lançador falha mesmo e a instância nova começa no namespace errado. Verifique o serviço ou o wrapper que a gerou, porque uma unidade ou uma entrada de ambiente de trabalho pode perder o namespace quando é reexecutada através de um bus de sessão. Depois teste de novo a partir de uma shell dentro do namespace correto antes de culpar o navegador. Uma variável de cada vez é a única forma de isto continuar diagnosticável.

Partilhar um ecrã também não partilha um resolvedor.

Se o processo estiver no namespace correto e a resolução de nomes continuar a falhar,investigue o seu ambiente de resolvedor como um problema separado. Nenhuma outra alteração de encaminhamento pode deslocar um pedido que foi entregue à instância errada antes mesmo de ter começado.

Artigos relacionados