Como ler o enrutamento DNS da VPN por enlace desde resolvectl
resolvectl status mostra servidores, dominios e a ruta predeterminada por enlace. Léaos xuntos, despois consulta o nome e anota que enlace respondeu.
Executa resolvectl status e obterás un muro de bloques por enlace, cada un cos seus propios servidores e a súa propia liña de dominios. A liña que decide o enrutamento é a lista de dominios, non o enderezo do servidor de nomes, porque o stub local reenvía cada consulta ao enlace que reclama o nome. Le esas reclamacións antes de ler a resposta, despois consulta o nome e comproba que enlace o produciu. Unha resposta incorrecta do enlace correcto é un problema distinto dunha resposta correcta do enlace incorrecto.
Que che di cada bloque por enlace
Cada bloque enumera os servidores que o resolutor usará para esa interface, a lista de dominios e se o enlace é a ruta predeterminada. A lista de dominios é un conxunto de reclamacións, e o resolutor aplica a coincidencia do sufixo máis longo: unha consulta para host.corp.example reclámaa un enlace que leva corp.example antes que un que só leva a ruta predeterminada. Dous enlaces que reclaman o mesmo sufixo deixan o resultado á prioridade e á orde, por iso os duplicados merecen atención primeiro. A liña do servidor actual mostra cal dos servidores enumerados se usa nese momento.
Un enderezo stub como 127.0.0.53 en /etc/resolv.conf só di que o stub está diante. Non nomea a orixe que respondeu, por iso un diagnóstico baseado só en resolv.conf atasca.
Le correctamente os tres tipos de entrada de dominio
| Entrada | Que reclama | Erro habitual |
|---|---|---|
| corp.example | dominio de enrutamento e sufixo de busca: os nomes por baixo van a este enlace e a cadea engádese aos nomes simples | eliminado porque o enrutamento parece funcionar de todos os xeitos |
| ~corp.example | só ruta: os nomes por baixo van a este enlace, pero o sufixo non se engade | supúxose que era necesario para o enrutamento |
| ~. | ruta predeterminada: reclama as consultas que ningún outro enlace cobre | deixado activo nun perfil dividido, de modo que os nomes públicos seguen o túnel |
A til cambia o comportamento da busca, non o enrutamento. Unha entrada sen til é á vez dominio de enrutamento e dominio de busca, así que os nomes por baixo envíanse a ese enlace e aos nomes dunha soa etiqueta engádeselles o sufixo. Unha entrada con til enruta o mesmo sufixo pero manteno fóra da lista de busca. Por iso quitar un til cambia que nomes simples se resolven, e por iso un til ausente é un problema de busca e non un fallo de DNS dividido.
A entrada de ruta predeterminada reclama todo o que ningún outro enlace cobre. Un perfil de túnel completo normalmente quérea e un perfil dividido normalmente non, porque entón os nomes públicos viaxan ao resolutor privado e poden fallar alí. Le a táboa segundo a intención do perfil en lugar de copiar indicadores entre perfís. Cando dous enlaces reclaman o mesmo sufixo, resolve a cuestión de prioridade antes de editar calquera outra cousa.
Consulta un nome e mira que enlace respondeu
A suborde query imprime o enderezo, o protocolo e o enlace ou ámbito que produciron a resposta. Proba un nome que debería reclamar o sufixo privado e un nome público corrente, despois compara as fontes informadas. Se o nome privado responde desde o enlace sen fíos, falta a reclamación ou o túnel está caído; se un nome público nun perfil dividido responde desde o túnel, a ruta predeterminada é demasiado ampla. Eses dous fallos parecen idénticos nun navegador e opostos nesta saída.
resolvectl status
resolvectl query host.corp.exampleVixía tamén o protocolo informado, porque unha resposta na caché ou do ficheiro de hosts pode chegar sen consultar ningunha orixe. Unha resposta da caché demostra que o nome se resolveu nalgún momento, non que a política actual o enrute correctamente.
Mantén o enrutamento de nomes apartado do enrutamento de paquetes
Unha decisión do resolutor non crea un camiño. O servidor elixido aínda necesita unha ruta cara ao seu enderezo, e o enderezo devolto aínda necesita unha ruta cara á rede privada, así que unha política DNS correcta pode convivir cunha conexión que nunca se abre. Cando un nome se resolve e a aplicación falla, inspecciona o enderezo e a ruta en lugar de cambiar DNS de novo. A resolución de nomes e a accesibilidade son dúas preguntas con dous propietarios distintos.
As aplicacións poden saltarse por completo o resolutor do sistema mediante a súa propia configuración de DNS seguro ou un resolutor integrado. O resultado de resolvectl describe a ruta do sistema, e un navegador que o ignore discrepará de cada proba que fagas. Comproba esa configuración antes de concluír que a política está rota.
Anota o enderezo ao que se resolveu o nome xunto ao enlace. Un nome correcto que apunta ao enderezo equivocado é un problema de rexistro, non de enrutamento.
Volve comprobar despois de que cambie o enlace
Unha reconexión ou un cambio de rede sen fíos reconstrúe o estado do enlace, e un xestor de rede pode reinstalar os seus dominios e servidores por riba de todo o posto a man. Consulta despois os mesmos dous nomes e compara coa liña base rexistrada. Se unha edición manual desapareceu, a corrección pertence ao perfil de conexión e non a unha orde de shell. Anotar antes e despois é o que fai iso visible.
Comparte só os nomes e o contexto de servidores que o informe necesita, porque os sufixos internos revelan a topoloxía. A documentación de systemd-resolved sobre enrutamento de dominios cobre a regra da coincidencia máis longa e o comportamento do til, e lela unha vez evita a maioría dos erros da táboa anterior: enrutamento de consultas de systemd-resolved.