OpenVPN enviou um servidor DNS, mas o Linux ignora-o

O servidor DNS enviado está no log, o túnel está ativo e os nomes internos continuam a falhar. Nada está quebrado no envio em si; a configuração chegou e parou ali. Uma opção DNS enviada é uma mensagem ao cliente, não uma instrução ao resolvedor do sistema operativo, e a entrega entre ambos é onde termina a maioria destes casos. Cinco verificações, por ordem, encontram a entrega que não aconteceu.

Verificação um: como começa a ligação

O dono da ligação determina quem pode aplicar as configurações do resolvedor. Um comando openvpn direto a partir de uma shell não possui nada além do seu próprio processo, enquanto uma unidade systemd, o NetworkManager ou um cliente de fabricante têm cada um a sua forma de publicar DNS. Leia a lista de processos e o nome da unidade antes de assumir qualquer um deles.

Um processo de linha de comandos não é automaticamente uma ligação do NetworkManager, e uma ligação do NetworkManager não é automaticamente o que escreveu resolv.conf. Essas duas suposições explicam a maior parte das horas perdidas nesta investigação. Pergunte que componente publicaria DNS para a interface que realmente vê.

Anote o dono antes de continuar. Cada verificação posterior depende dele.

Verificação dois: o que a ligação do resolvedor realmente contém

Num host com systemd-resolved, resolvectl status lista cada ligação com os seus servidores DNS e domínios. Encontre a ligação do túnel e leia as suas entradas, e não suponha que a interface se chama tun0, porque a numeração segue a ordem de criação. Se o endereço enviado não estiver na ligação, o que falhou foi a entrega, não a consulta.

Se o endereço estiver presente, a pergunta seguinte é que domínios essa ligação reclama. Uma ligação sem lista de domínios responde apenas aos nomes pelos quais é questionada diretamente, e isso raramente é o que uma implementação split-DNS quer. O endereço sozinho é necessário mas não suficiente.

Compare o nome da ligação na saída do resolvedor com o nome da interface no log do VPN antes de tirar qualquer conclusão. Uma discrepância ali costuma significar que a linha do log veio de outro processo.

Verificação três: se o espaço de nomes escolhe essa ligação

Um resolvedor pode ter o servidor certo e mesmo assim não ser consultado. O domínio por ligação decide que consultas vão para que ligação, e sem um domínio de encaminhamento o espaço de nomes privado recai no que diz a ligação predefinida. É por isso que resolvectl query pode ter sucesso para o nome interno enquanto uma aplicação continua a falhar. A aplicação pode estar a usar um caminho de resolvedor completamente diferente.

Verifique a atribuição de domínio, não apenas o endereço do servidor. Um domínio escrito como ~corp.example é um domínio de encaminhamento, e o til muda a forma como o nome é correspondido.

Se a aplicação tem o seu próprio resolvedor, teste com o mesmo mecanismo que ela usa em vez de com a ferramenta do sistema. Uma ferramenta de consulta que contorna o resolvedor do sistema terá sucesso independentemente do estado da ligação.

Verificação quatro: um dono, não dois

Se o NetworkManager já gere o VPN e o estado do resolvedor, acrescentar um script de gancho não relacionado cria escritores concorrentes. O gancho que o pacote fornece para o systemd-resolved é uma integração suportada e espera um ciclo de vida concreto: script-security 2, um caminho up, up-restart, um caminho down e down-pre. Essas opções fazem com que o registo e a remoção aconteçam nos momentos certos e não apenas na primeira ligação.

Use o caminho instalado pelo pacote em vez de um ilustrativo copiado de um guia. As permissões também importam, porque o gancho corre depois de os privilégios baixarem.

Editar um script de resolvedor da distribuição para mudar o seu alvo de saída registra uma solução temporária de um único host. Não é uma reparação geral.

Verificação cinco: o mesmo resultado após reconectar

Reconecte e leia a ligação outra vez. Um registo que aparece uma vez e desaparece na transição seguinte é a falha para a qual existe toda esta lista. Teste após uma suspensão, após uma reconexão forçada e após reiniciar o serviço do resolvedor. Cada transição testa uma suposição de ordem diferente.

Só quando as cinco verificações passam numa reconexão pode dizer que as configurações enviadas estão em uso. Qualquer coisa anterior é uma captura de um momento de sorte.