Compartilhar a rede de um contêiner VPN: o que acontece com o DNS

Compartilhar o espaço de nomes de rede de um contêiner VPN dá à sua aplicação as interfaces e as rotas do túnel. Ele não lhe dá o resolvedor do túnel, nem uma cópia unificada de qualquer outra coisa no host. Essa lacuna produz uma falha muito específica: nomes públicos resolvem, nomes internos não, e a aplicação que falha parece estar usando o servidor DNS errado, porque está. O reparo costuma ser menor do que o diagnóstico sugere.

Passo 1: Teste a partir da aplicação, não do host

Execute a consulta dentro do contêiner que tem o problema, não no host e não num navegador. docker exec app-container getent hosts db.internal responde à única pergunta que importa: o que o resolvedor deste processo devolve.

Se o host resolve o nome e o contêiner não, você encontrou a falha. Tudo depois disso é escolher uma forma suportada de corrigi-la.

Passo 2: Leia o modelo suportado pelo runtime

A documentação de rede do Docker registra restrições em opções de DNS para contêineres que compartilham o modo de rede de outro contêiner. No Compose network_mode: service:vpn liga a aplicação ao espaço de nomes do contêiner VPN, e por serviço dns as configurações não se comportam como num serviço comum. A resolução que você obtém é a que o espaço de nomes compartilhado tem.

As redes de ponte definidas pelo usuário também usam o DNS integrado do Docker de forma diferente da ponte padrão. Por isso uma dns cláusula copiada de um exemplo de ponte que funciona pode não fazer absolutamente nada numa pilha compartilhada. Verifique a disposição antes de copiar a cláusula.

Um endereço de loopback sempre se refere ao contexto de rede relevante. Dentro de um espaço de nomes compartilhado, 127.0.0.1 não é o resolvedor do host.

Passo 3: Siga a consulta até o destinatário

Leia a configuração do resolvedor da aplicação e depois qualquer DNS cifrado específico da aplicação que ela traga, porque uma aplicação que executa o seu próprio resolvedor ignora o ficheiro que você editou. Depois verifique se o resolvedor escolhido é alcançável sob as rotas e a política de firewall da VPN. Um endereço de resolvedor do outro lado do túnel é inútil se o espaço de nomes não tiver rota até ele. Confirme o destinatário antes de editar qualquer ficheiro.

Uma página de verificação de IP no navegador não pode dizer para onde foram as consultas de nomes. Diz para onde foi uma conexão HTTP.

Passo 4: Corrija as duas classes de falha de forma diferente

Se os nomes de serviço falham enquanto os nomes públicos funcionam, o problema é a descoberta de serviços dentro da rede de contêineres, não a lista de resolvedores públicos. Mudar todos os endereços DNS públicos não criará registos que o mecanismo de descoberta da rede nunca foi convidado a criar.

Se as duas classes falharem, comece pela acessibilidade ao resolvedor. Se só uma falhar, comece pelo mecanismo de descoberta. As duas têm proprietários diferentes, por isso um reparo nunca cobre as duas.

Passo 5: Teste novamente após recriar

Altere a configuração através do mecanismo suportado pelo runtime e depois recrie os contêineres em vez de editar ficheiros dentro de um em execução. Teste um novo nome privado, um novo nome público e o pedido da aplicação que se segue à consulta. Uma edição em /etc/resolv.conf dentro de um contêiner desaparece ao recriar e vai convencê-lo de que o reparo funcionou quando não funcionou.

Registe o proprietário do resolvedor e o espaço de nomes esperado ao lado da definição da rede compartilhada. A próxima pessoa vai precisar dos dois.