Com llegir l'encaminament DNS de la VPN per enllaç a partir de resolvectl
resolvectl status mostra servidors, dominis i la ruta per defecte per enllaç. Llegeix-los junts, després consulta el nom i anota quin enllaç ha respost.
Executeu resolvectl status i obteniu una paret de blocs per enllaç, cadascun amb els seus servidors i la seva línia de dominis. La línia que decideix l'encaminament és la llista de dominis, no l'adreça del servidor de noms, perquè l'stub local reenvia cada consulta a l'enllaç que reclama el nom. Llegiu aquestes reclamacions abans de llegir la resposta, després consulteu el nom i comproveu quin enllaç l'ha produït. Una resposta incorrecta de l'enllaç correcte és un problema diferent d'una resposta correcta de l'enllaç incorrecte.
Què us diu cada bloc per enllaç
Cada bloc llista els servidors que el resolutor farà servir per a aquesta interfície, la llista de dominis i si l'enllaç és la ruta per defecte. La llista de dominis és un conjunt de reclamacions, i el resolutor aplica la coincidència del sufix més llarg: una consulta per a host.corp.example la reclama un enllaç que porta corp.example abans que un que només porta la ruta per defecte. Dos enllaços que reclamen el mateix sufix deixen el resultat a la prioritat i l'ordre, i per això els duplicats mereixen atenció primer. La línia del servidor actual mostra quin dels servidors llistats s'utilitza en aquell moment.
Una adreça stub com 127.0.0.53 a /etc/resolv.conf només diu que l'stub és al davant. No anomena l'origen que ha respost, i per això un diagnòstic basat només en resolv.conf s'encalla.
Llegiu correctament els tres tipus d'entrada de domini
| Entrada | Què reclama | Error habitual |
|---|---|---|
| corp.example | domini d'encaminament i sufix de cerca: els noms per sota hi van per aquest enllaç, i la cadena s'afegeix als noms simples | eliminat perquè l'encaminament sembla que funciona igualment |
| ~corp.example | només ruta: els noms per sota hi van per aquest enllaç, però el sufix no s'afegeix | es va suposar que calia per a l'encaminament |
| ~. | ruta per defecte: reclama les consultes que cap altre enllaç no cobreix | deixat actiu en un perfil dividit, de manera que els noms públics segueixen el túnel |
La titlla canvia el comportament de la cerca, no l'encaminament. Una entrada sense titlla és alhora domini d'encaminament i domini de cerca, així que els noms per sota s'envien a aquest enllaç i als noms d'una sola etiqueta se'ls afegeix el sufix. Una entrada amb titlla encamina el mateix sufix però el manté fora de la llista de cerca. Per això treure una titlla canvia quins noms simples es resolen, i per això una titlla absent és un problema de cerca i no una fallada de DNS dividit.
L'entrada de ruta per defecte reclama tot allò que cap altre enllaç no cobreix. Un perfil de túnel complet normalment la vol i un perfil dividit normalment no, perquè llavors els noms públics viatgen al resolutor privat i hi poden fallar. Llegiu la taula segons la intenció del perfil en lloc de copiar indicadors entre perfils. Quan dos enllaços reclamen el mateix sufix, resoleu la qüestió de prioritat abans d'editar res més.
Consulteu un nom i vegeu quin enllaç ha respost
La subordre query imprimeix l'adreça, el protocol i l'enllaç o àmbit que ha produït la resposta. Proveu un nom que hauria de reclamar el sufix privat i un nom públic corrent, i després compareu les fonts informades. Si el nom privat respon des de l'enllaç sense fil, la reclamació falta o el túnel està caigut; si un nom públic en un perfil dividit respon des del túnel, la ruta per defecte és massa àmplia. Aquestes dues fallades semblen idèntiques al navegador i oposades en aquesta sortida.
resolvectl status
resolvectl query host.corp.exampleVigileu també el protocol informat, perquè una resposta en memòria cau o del fitxer d'hostes pot arribar sense consultar cap origen. Una resposta de la memòria cau demostra que el nom es va resoldre en algun moment, no que la política actual l'encamini correctament.
Manteniu l'encaminament de noms separat de l'encaminament de paquets
Una decisió del resolutor no crea un camí. El servidor triat encara necessita una ruta cap a la seva adreça, i l'adreça retornada encara necessita una ruta cap a la xarxa privada, així que una política DNS correcta pot conviure amb una connexió que no s'obre mai. Quan un nom es resol i l'aplicació falla, inspecteu l'adreça i la ruta en lloc de tornar a canviar el DNS. La resolució de noms i l'abastabilitat són dues preguntes amb dos propietaris diferents.
Les aplicacions poden saltar-se el resolutor del sistema del tot mitjançant la seva pròpia configuració de DNS segur o un resolutor integrat. El resultat de resolvectl descriu el camí del sistema, i un navegador que l'ignori discreparà de cada prova que feu. Comproveu aquesta configuració abans de concloure que la política està trencada.
Anoteu l'adreça a la qual s'ha resolt el nom al costat de l'enllaç. Un nom correcte que apunta a l'adreça equivocada és un problema de registre, no d'encaminament.
Torneu a comprovar després que canviï l'enllaç
Una reconnexió o un canvi de xarxa sense fil reconstrueix l'estat de l'enllaç, i un gestor de xarxa pot reinstal·lar els seus dominis i servidors per sobre de tot el que s'hagi posat a mà. Consulteu els mateixos dos noms després i compareu amb la línia base anotada. Si una edició manual ha desaparegut, la correcció pertany al perfil de connexió i no a una ordre d'intèrpret. Anotar abans i després és el que ho fa visible.
Compartiu només els noms i el context de servidors que l'informe necessita, perquè els sufixos interns revelen la topologia. La documentació de systemd-resolved sobre encaminament de dominis cobreix la regla de la coincidència més llarga i el comportament de la titlla, i llegir-la un cop evita la majoria d'errors de la taula anterior: encaminament de consultes de systemd-resolved.