ip netns exec e DNS: por que os nomes falham dentro do espaço de nomes

Um comando alcança 10.8.0.5 dentro do espaço de nomes da VPN sem qualquer reclamação, e o mesmo comando falha no momento em que usa um nome de host. O espaço de nomes tem suas próprias interfaces, rotas e sockets; ele não tem seu próprio arquivo de resolução. A menos que algo coloque um arquivo ali, o processo interno lê o /etc/resolv.conf do host e pergunta a um servidor que pode não ser alcançável a partir dessa pilha de rede.

Esse é um problema de seleção de arquivo e não de roteamento, e é exatamente por isso que o destino numérico continua funcionando.

Verifique a visão do resolvedor que o processo realmente recebe

Não presuma que o shell que você usou equivale ao processo que está depurando. Um aplicativo gráfico, uma unidade do systemd e um contêiner podem cada um entrar em um contexto de montagem ou de rede diferente. Execute a consulta pelo mesmo caminho de inicialização e imprima o arquivo do resolvedor por dentro.

Para um espaço de nomes criado com ip netns add, a verificação somente de leitura é curta:

ip netns exec vpn cat /etc/resolv.conf

Observe se o resultado nomeia um endereço alcançável, um stub de loopback ou um link simbólico que aponta para um local com outra alcançabilidade.

O que o auxiliar exec realmente monta

A ferramenta ip-netns documenta a configuração por espaço de nomes em /etc/netns/NAME/. Quando ela inicia um processo, o auxiliar cria um espaço de nomes de montagem e monta esses arquivos sobre seus caminhos habituais, de modo que o processo vê a cópia específica do espaço de nomes. Isso é uma comodidade deste lançador específico. Entrar em um espaço de nomes de rede por outro caminho, como unshare ou um runtime de contêineres, não reproduz isso automaticamente.

O resolvedor de loopback é a armadilha aqui: 127.0.0.53 significa o loopback do próprio espaço de nomes, não o stub do host. Um stub que escuta apenas no espaço de nomes do host não se torna um serviço no novo.

Escolha um resolvedor que o espaço de nomes consiga alcançar

Seja qual for o servidor que o arquivo nomeie, ele ainda precisa de uma rota a partir desse espaço de nomes. Um resolvedor público pode responder a nomes públicos e ainda assim falhar para uma zona interna, porque o serviço privado só é alcançável pelo túnel. Verifique a rota ao mesmo tempo que o endereço, não depois que a consulta já falhou.

Aplicações com resolvedor próprio, como uma que use DNS sobre HTTPS, podem ignorar o arquivo por completo. Se a ferramenta tem sua própria configuração de DNS, mudar resolv.conf não a afetará, e o espaço de nomes nunca foi o problema.

Escreva o arquivo no lugar certo

Crie o arquivo por espaço de nomes em /etc/netns/NAME/resolv.conf e deixe o lançador apresentá-lo. Mantenha-o mínimo: um ou dois servidores alcançáveis e os domínios de busca de que a tarefa precisa. Não edite o arquivo de resolvedor gerado do host para corrigir uma visão destinada a um grupo de processos, porque isso muda todas as aplicações da máquina. Se o host usa um gerenciador de resolvedor, configure o caminho do espaço de nomes por esse gerenciador em vez de lutar contra ele.

Registre o conteúdo do arquivo no runbook. Caso contrário, a próxima pessoa testará o resolvedor do host, verá uma resposta que funciona e concluirá que o espaço de nomes está bem.

Teste novamente todo o caminho

Teste dentro do espaço de nomes com um endereço numérico, um nome interno e um nome público. Essa sequência separa a alcançabilidade da resolução e separa as zonas internas das públicas. Depois recrie o espaço de nomes e repita, porque um arquivo que só existe em uma instância em execução desaparece com ela.

Confirme que é o processo, e não o shell, que recebe o arquivo. Uma consulta que funciona a partir de um shell interativo e falha a partir de um serviço é uma constatação sobre o contexto de montagem, e vale a pena anotá-la antes do próximo incidente em vez de redescobri-la do zero.