Sådan læser du VPN-DNS-routing pr. link fra resolvectl
resolvectl status viser servere, domæner og standardruten pr. link. Læs dem sammen, og spørg derefter på navnet og noter, hvilket link der svarede.
Kør resolvectl status, og du får en mur af blokke pr. link, hver med sine egne servere og sin egen domænelinje. Linjen, der afgør routing, er domænelisten, ikke navneserverens adresse, fordi den lokale stub videresender hver forespørgsel til det link, der gør krav på navnet. Læs disse krav, før du læser svaret, og spørg derefter på navnet og tjek, hvilket link der producerede det. Et forkert svar fra det rigtige link er et andet problem end et rigtigt svar fra det forkerte.
Hvad hver blok pr. link fortæller dig
Hver blok lister de servere, som resolveren vil bruge til den grænseflade, domænelisten, og om linket er standardruten. Domænelisten er et sæt krav, og resolveren anvender længste-suffiks-match: en forespørgsel på host.corp.example gøres krav på af et link, der bærer corp.example, før et der kun bærer standardruten. To link, der gør krav på samme suffiks, overlader resultatet til prioritet og rækkefølge, og derfor fortjener dubletter opmærksomhed først. Den aktuelle serverlinje viser, hvilken af de listede servere der er i brug i det øjeblik.
En stubadresse som 127.0.0.53 i /etc/resolv.conf siger kun, at stubben står foran. Den navngiver ikke den upstream, der svarede, og derfor går en diagnose, der kun bygger på resolv.conf, i stå.
Læs de tre slags domæneposter korrekt
| Post | Hvad den gør krav på | Almindelig fejl |
|---|---|---|
| corp.example | routingdomæne og søgesuffiks: navne derunder går til dette link, og strengen tilføjes til bare navne | fjernet, fordi routing alligevel ser ud til at virke |
| ~corp.example | kun rute: navne derunder går til dette link, men suffikset tilføjes ikke | antaget at være nødvendig for routing |
| ~. | standardrute: gør krav på forespørgsler, som intet andet link matcher | ladt aktiv på en delt profil, så offentlige navne følger tunnelen |
Tilden ændrer søgeadfærd, ikke routing. En post uden tilde er både et routingdomæne og et søgedomæne, så navne derunder sendes til det link, og enkeltlabels-navne får suffikset tilføjet. En tilde-post router det samme suffiks, men holder det ude af søgelisten. Derfor ændrer fjernelse af en tilde, hvilke bare navne der opløses, og derfor er en manglende tilde et søgeproblem snarere end en fejl i delt DNS.
Standardruteposten gør krav på alt, som intet andet link matcher. En fuldtunnelprofil vil normalt have den, og en delt profil vil normalt ikke, fordi offentlige navne så rejser til den private resolver og kan fejle der. Læs tabellen op imod profilens hensigt i stedet for at kopiere flag mellem profiler. Når to link gør krav på samme suffiks, afgør prioritetsspørgsmålet, før du redigerer noget andet.
Spørg på et navn, og se hvilket link der svarede
Underkommandoen query udskriver adressen, protokollen og det link eller scope, der producerede svaret. Test ét navn, som det private suffiks bør gøre krav på, og ét almindeligt offentligt navn, og sammenlign derefter de rapporterede kilder. Hvis det private navn svarer fra det trådløse link, mangler kravet, eller tunnelen er nede; hvis et offentligt navn på en delt profil svarer fra tunnelen, er standardruten for bred. De to fejl ser ens ud i en browser og modsatte ud i dette output.
resolvectl status
resolvectl query host.corp.exampleHold også øje med den rapporterede protokol, fordi et cachet svar eller et svar fra host-filen kan ankomme, uden at nogen upstream blev spurgt. Et svar fra cachen beviser, at navnet blev opløst på et tidspunkt, ikke at den nuværende politik router det korrekt.
Hold navnerouting adskilt fra pakkerouting
En resolverbeslutning skaber ikke en vej. Den valgte server har stadig brug for en rute til sin adresse, og den returnerede adresse har stadig brug for en rute ind i det private netværk, så en korrekt DNS-politik kan eksistere sammen med en forbindelse, der aldrig åbnes. Når et navn opløses, og applikationen fejler, så undersøg adressen og ruten i stedet for at ændre DNS igen. Navneopløsning og tilgængelighed er to spørgsmål med to forskellige ejere.
Applikationer kan omgå systemresolveren helt gennem deres egen sikre DNS-indstilling eller en indbygget resolver. resolvectl-resultatet beskriver systemvejen, og en browser, der ignorerer det, vil være uenig i hver test, du kører. Tjek den indstilling, før du konkluderer, at politikken er brudt.
Noter den adresse, som navnet blev opløst til, ved siden af linket. Et korrekt navn, der peger på den forkerte adresse, er et postproblem snarere end et routingproblem.
Tjek igen, efter linket ændrer sig
En genopkobling eller et trådløst skift genopbygger linktilstanden, og en netværksmanager kan geninstallere sine domæner og servere oven på alt, der er sat manuelt. Spørg på de samme to navne bagefter, og sammenlign med den registrerede baseline. Hvis en manuel redigering er forsvundet, hører rettelsen hjemme i forbindelsesprofilen snarere end i en shell-kommando. Det er registreringen før og efter, der gør det synligt.
Del kun de navne og den serverkontekst, rapporten har brug for, fordi interne suffikser afslører topologi. systemd-resolved-dokumentationen om domænerouting dækker længste-match-reglen og tilde-adfærden, og én gennemlæsning forhindrer de fleste af tabelfejlene ovenfor: forespørgselsrouting i systemd-resolved.