Slik leser du VPN-DNS-ruting per kobling fra resolvectl
resolvectl status viser servere, domener og standardruten per kobling. Les dem sammen, spør deretter på navnet og noter hvilken kobling som svarte.
Kjør resolvectl status, og du får en vegg av blokker per kobling, hver med egne servere og egen domenelinje. Linjen som avgjør rutingen, er domenelisten, ikke navneserverens adresse, fordi den lokale stubben videresender hver forespørsel til koblingen som gjør krav på navnet. Les disse kravene før du leser svaret, spør deretter på navnet og sjekk hvilken kobling som produserte det. Et galt svar fra riktig kobling er et annet problem enn et riktig svar fra feil kobling.
Hva hver blokk per kobling forteller deg
Hver blokk lister opp serverne som resolvatoren vil bruke for det grensesnittet, domenelisten og om koblingen er standardruten. Domenelisten er et sett med krav, og resolvatoren bruker samsvar for lengste suffiks: en forespørsel om host.corp.example gjøres krav på av en kobling som har corp.example, før en som bare har standardruten. To koblinger som gjør krav på samme suffiks, overlater resultatet til prioritet og rekkefølge, derfor fortjener duplikater oppmerksomhet først. Linjen for gjeldende server viser hvilken av de oppførte serverne som brukes i det øyeblikket.
En stubadresse som 127.0.0.53 i /etc/resolv.conf sier bare at stubben står foran. Den navngir ikke oppstrømmen som svarte, derfor stopper en diagnose som bare bygger på resolv.conf.
Les de tre typene domeneoppføringer riktig
| Oppføring | Hva den gjør krav på | Vanlig feil |
|---|---|---|
| corp.example | rutingsdomene og søkesuffiks: navn under det går til denne koblingen, og strengen legges til nakne navn | fjernet fordi rutingen ser ut til å virke likevel |
| ~corp.example | bare rute: navn under det går til denne koblingen, men suffikset legges ikke til | antatt at den er nødvendig for ruting |
| ~. | standardrute: gjør krav på forespørsler som ingen annen kobling dekker | latt stå aktiv på en delt profil, slik at offentlige navn følger tunnelen |
Tilden endrer søkeatferd, ikke ruting. En oppføring uten tilde er både et rutingsdomene og et søkedomene, så navn under det sendes til den koblingen, og navn med én etikett får suffikset lagt til. En tilde-oppføring ruter samme suffiks, men holder det utenfor søkelisten. Derfor endrer det å fjerne en tilde hvilke nakne navn som løses, og derfor er en manglende tilde et søkeproblem og ikke en feil i delt DNS.
Oppføringen for standardruten gjør krav på alt ingen annen kobling dekker. En fulltunnelprofil vil vanligvis ha den, og en delt profil vil vanligvis ikke, fordi offentlige navn da reiser til den private resolvatoren og kan feile der. Les tabellen mot profilens hensikt i stedet for å kopiere flagg mellom profiler. Når to koblinger gjør krav på samme suffiks, avgjør prioritetsspørsmålet før du redigerer noe annet.
Spør på et navn og se hvilken kobling som svarte
Underkommandoen query skriver ut adressen, protokollen og koblingen eller omfanget som produserte svaret. Test ett navn som det private suffikset skal gjøre krav på, og ett vanlig offentlig navn, og sammenlign deretter de rapporterte kildene. Hvis det private navnet svarer fra den trådløse koblingen, mangler kravet eller tunnelen er nede; hvis et offentlig navn på en delt profil svarer fra tunnelen, er standardruten for bred. Disse to feilene ser like ut i en nettleser og motsatte ut i denne utdataen.
resolvectl status
resolvectl query host.corp.exampleFølg også med på den rapporterte protokollen, fordi et bufret svar eller et svar fra vertsfilen kan komme uten at noen oppstrøm er spurt. Et svar fra hurtigbufferen beviser at navnet ble løst en gang, ikke at gjeldende policy ruter det riktig.
Hold navneruting atskilt fra pakkeruting
En resolvatorbeslutning skaper ikke en vei. Den valgte serveren trenger fortsatt en rute til adressen sin, og adressen som returneres, trenger fortsatt en rute inn i det private nettverket, så en riktig DNS-policy kan eksistere sammen med en forbindelse som aldri åpnes. Når et navn løses og applikasjonen feiler, undersøk adressen og ruten i stedet for å endre DNS igjen. Navneoppslag og tilgjengelighet er to spørsmål med to forskjellige eiere.
Applikasjoner kan omgå systemresolvatoren helt gjennom sin egen sikre DNS-innstilling eller en innebygd resolvator. resolvectl-resultatet beskriver systemveien, og en nettleser som ignorerer det, vil være uenig i hver test du gjør. Sjekk den innstillingen før du konkluderer med at policyen er ødelagt.
Noter adressen navnet ble løst til, ved siden av koblingen. Et riktig navn som peker på feil adresse, er et oppføringsproblem og ikke et rutingsproblem.
Sjekk på nytt etter at koblingen har endret seg
En gjentilkobling eller et trådløst bytte bygger opp koblingstilstanden på nytt, og en nettverksbehandler kan installere domenene og serverne sine på nytt over alt som er satt manuelt. Spør deretter på de samme to navnene og sammenlign med den registrerte grunnlinjen. Hvis en manuell endring er borte, hører rettelsen hjemme i tilkoblingsprofilen og ikke i en skallkommando. Det er registreringen før og etter som gjør det synlig.
Del bare navnene og serverkonteksten rapporten trenger, fordi interne suffikser avslører topologi. systemd-resolved-dokumentasjonen om domenenruting dekker regelen om lengste samsvar og tilde-atferden, og én gjennomlesing hindrer de fleste tabellfeilene ovenfor: forespørselsruting i systemd-resolved.