Como ler o encaminhamento DNS da VPN por ligação a partir do resolvectl

Execute resolvectl status e obtém uma parede de blocos por ligação, cada um com os seus próprios servidores e a sua própria linha de domínios. A linha que decide o encaminhamento é a lista de domínios, não o endereço do servidor de nomes, porque o stub local reenvia cada consulta para a ligação que reclama o nome. Leia essas reivindicações antes de ler a resposta, depois consulte o nome e verifique qual ligação o produziu. Uma resposta errada da ligação certa é um problema diferente de uma resposta certa da ligação errada.

O que cada bloco por ligação lhe diz

Cada bloco lista os servidores que o resolvedor usará para essa interface, a lista de domínios e se a ligação é a rota predefinida. A lista de domínios é um conjunto de reivindicações, e o resolvedor aplica a correspondência do sufixo mais longo: uma consulta para host.corp.example é reclamada por uma ligação que transporta corp.example antes de uma que só transporta a rota predefinida. Duas ligações que reivindicam o mesmo sufixo deixam o resultado à prioridade e à ordem, por isso os duplicados merecem atenção primeiro. A linha do servidor atual mostra qual dos servidores listados está em uso naquele momento.

Um endereço stub como 127.0.0.53 em /etc/resolv.conf diz apenas que o stub está à frente. Não nomeia a origem que respondeu, por isso um diagnóstico baseado apenas em resolv.conf encrava.

Leia corretamente os três tipos de entrada de domínio

O til altera o comportamento de pesquisa, não o encaminhamento. Uma entrada sem til é simultaneamente domínio de encaminhamento e domínio de pesquisa, por isso os nomes abaixo são enviados para essa ligação e os nomes de uma só etiqueta recebem o sufixo. Uma entrada com til encaminha o mesmo sufixo mas mantém-no fora da lista de pesquisa. Por isso remover um til altera que nomes simples se resolvem, e por isso um til em falta é um problema de pesquisa e não uma falha de DNS dividido.

A entrada da rota predefinida reclama tudo o que nenhuma outra ligação cobre. Um perfil de túnel completo normalmente quer essa rota e um perfil dividido normalmente não, porque os nomes públicos viajam então para o resolvedor privado e podem falhar ali. Leia a tabela contra a intenção do perfil em vez de copiar indicadores entre perfis. Quando duas ligações reivindicam o mesmo sufixo, resolva a questão da prioridade antes de editar qualquer outra coisa.

Consulte um nome e veja qual ligação respondeu

O subcomando query imprime o endereço, o protocolo e a ligação ou âmbito que produziram a resposta. Teste um nome que deveria ser reclamado pelo sufixo privado e um nome público comum, depois compare as origens comunicadas. Se o nome privado responde a partir da ligação sem fios, a reivindicação falta ou o túnel está em baixo; se um nome público num perfil dividido responde a partir do túnel, a rota predefinida é demasiado ampla. Essas duas falhas parecem idênticas num navegador e opostas nesta saída.

resolvectl status
resolvectl query host.corp.example

Repare também no protocolo comunicado, porque uma resposta da cache ou do ficheiro hosts pode chegar sem que nenhuma origem seja consultada. Uma resposta da cache prova que o nome se resolveu em algum momento, não que a política atual o encaminhe corretamente.

Mantenha o encaminhamento de nomes separado do encaminhamento de pacotes

Uma decisão do resolvedor não cria um caminho. O servidor escolhido continua a precisar de uma rota para o seu endereço, e o endereço devolvido continua a precisar de uma rota para a rede privada, por isso uma política DNS correta pode coexistir com uma ligação que nunca se abre. Quando um nome se resolve e a aplicação falha, inspecione o endereço e a rota em vez de mudar o DNS outra vez. Resolução de nomes e alcançabilidade são duas perguntas com dois donos diferentes.

As aplicações podem contornar totalmente o resolvedor do sistema através da sua própria definição de DNS seguro ou de um resolvedor integrado. O resultado do resolvectl descreve o caminho do sistema, e um navegador que o ignore vai discordar de todos os testes que fizer. Verifique essa definição antes de concluir que a política está quebrada.

Registe o endereço para o qual o nome se resolveu ao lado da ligação. Um nome correto que aponta para o endereço errado é um problema de registo, não de encaminhamento.

Verifique de novo depois de a ligação mudar

Uma reconexão ou uma mudança de rede sem fios reconstrói o estado da ligação, e um gestor de rede pode reinstalar os seus domínios e servidores por cima de tudo o que foi definido à mão. Consulte depois os mesmos dois nomes e compare com a linha de base registada. Se uma edição manual desapareceu, a correção pertence ao perfil de ligação e não a um comando shell. É o registo antes e depois que torna isso visível.

Partilhe apenas os nomes e o contexto de servidores de que o relatório precisa, porque os sufixos internos revelam a topologia. A documentação do systemd-resolved sobre encaminhamento de domínios cobre a regra da correspondência mais longa e o comportamento do til, e uma leitura evita a maioria dos erros da tabela acima: encaminhamento de consultas no systemd-resolved.