Hoe je VPN-DNS-routering per verbinding leest uit resolvectl
resolvectl status toont servers, domeinen en de standaardroute per verbinding. Lees ze samen, vraag dan de naam op en noteer welke verbinding antwoordde.
Voer resolvectl status uit en je krijgt een muur van blokken per verbinding, elk met eigen servers en een eigen domeinregel. De regel die de routering bepaalt is de domeinenlijst, niet het adres van de naamsrever, omdat de lokale stub elke vraag doorstuurt naar de verbinding die de naam claimt. Lees die claims voordat je het antwoord leest, vraag dan de naam op en controleer welke verbinding hem heeft gemaakt. Een fout antwoord van de juiste verbinding is een ander probleem dan een juist antwoord van de verkeerde.
Wat elk blok per verbinding je vertelt
Elk blok somt de servers op die de resolver voor die interface gebruikt, de domeinenlijst en of de verbinding de standaardroute is. De domeinenlijst is een verzameling claims, en de resolver past de langste-achtervoegsel-overeenkomst toe: een vraag naar host.corp.example wordt geclaimd door een verbinding met corp.example vóór een die alleen de standaardroute heeft. Twee verbindingen die hetzelfde achtervoegsel claimen, laten de uitkomst aan prioriteit en volgorde over, daarom verdienen duplicaten eerst aandacht. De regel van de huidige server toont welke van de genoemde servers op dat moment in gebruik is.
Een stubadres zoals 127.0.0.53 in /etc/resolv.conf zegt alleen dat de stub vooraan staat. Het noemt niet de upstream die antwoordde, daarom loopt een diagnose die alleen op resolv.conf bouwt vast.
Lees de drie soorten domeinvermeldingen goed
| Vermelding | Wat hij claimt | Veelgemaakte fout |
|---|---|---|
| corp.example | routeringsdomein en zoekachtervoegsel: namen eronder gaan naar deze verbinding, en de tekenreeks wordt aan kale namen toegevoegd | verwijderd omdat de routering toch lijkt te werken |
| ~corp.example | alleen route: namen eronder gaan naar deze verbinding, maar het achtervoegsel wordt niet toegevoegd | aangenomen dat het nodig is voor de routering |
| ~. | standaardroute: claimt vragen die geen enkele andere verbinding dekt | actief gelaten op een gesplitst profiel, zodat openbare namen de tunnel volgen |
De tilde verandert het zoekgedrag, niet de routering. Een vermelding zonder tilde is zowel routeringsdomein als zoekdomein, dus namen eronder worden naar die verbinding gestuurd en namen met één label krijgen het achtervoegsel. Een tilde-vermelding routeert hetzelfde achtervoegsel maar houdt het buiten de zoeklijst. Daarom verandert het verwijderen van een tilde welke kale namen worden opgelost, en daarom is een ontbrekende tilde een zoekprobleem en geen storing van gesplitst DNS.
De vermelding van de standaardroute claimt alles wat geen andere verbinding dekt. Een fulltunnelprofiel wil hem meestal en een gesplitst profiel meestal niet, omdat openbare namen dan naar de privé-resolver reizen en daar kunnen falen. Lees de tabel tegen de bedoeling van het profiel in plaats van vlaggen tussen profielen te kopiëren. Wanneer twee verbindingen hetzelfde achtervoegsel claimen, beslecht dan de prioriteitsvraag voordat je iets anders bewerkt.
Vraag een naam op en zie welke verbinding antwoordde
Het subcommando query print het adres, het protocol en de verbinding of scope die het antwoord hebben gemaakt. Test één naam die het privé-achtervoegsel zou moeten claimen en één gewone openbare naam, en vergelijk dan de gerapporteerde bronnen. Als de privé-naam antwoordt vanaf de draadloze verbinding, ontbreekt de claim of ligt de tunnel eruit; als een openbare naam op een gesplitst profiel antwoordt vanaf de tunnel, is de standaardroute te breed. Die twee fouten zien er in een browser hetzelfde uit en in deze uitvoer tegengesteld.
resolvectl status
resolvectl query host.corp.exampleLet ook op het gerapporteerde protocol, want een antwoord uit de cache of uit het hosts-bestand kan binnenkomen zonder dat een upstream is gevraagd. Een antwoord uit de cache bewijst dat de naam ooit is opgelost, niet dat het huidige beleid hem correct routeert.
Houd naamroutering gescheiden van pakketroutering
Een beslissing van de resolver maakt geen pad. De gekozen server heeft nog steeds een route naar zijn adres nodig, en het teruggegeven adres heeft nog steeds een route naar het privénetwerk nodig, dus een correct DNS-beleid kan samengaan met een verbinding die nooit opengaat. Wanneer een naam wordt opgelost en de toepassing faalt, onderzoek dan het adres en de route in plaats van opnieuw DNS te wijzigen. Naamresolutie en bereikbaarheid zijn twee vragen met twee verschillende eigenaren.
Toepassingen kunnen de systeemresolver volledig omzeilen via hun eigen veilige DNS-instelling of een ingebouwde resolver. Het resolvectl-resultaat beschrijft het systeempad, en een browser die het negeert, zal het oneens zijn met elke test die je doet. Controleer die instelling voordat je concludeert dat het beleid stuk is.
Noteer het adres waarop de naam is opgelost naast de verbinding. Een correcte naam die naar het verkeerde adres wijst, is een recordprobleem en geen routeringsprobleem.
Controleer opnieuw nadat de verbinding is veranderd
Opnieuw verbinden of een draadloze wissel bouwt de verbindingsstatus opnieuw op, en een netwerkbeheerder kan zijn domeinen en servers opnieuw installeren over alles wat met de hand is ingesteld. Vraag daarna dezelfde twee namen op en vergelijk met de vastgelegde basislijn. Als een handmatige wijziging is verdwenen, hoort de correctie in het verbindingsprofiel en niet in een shell-commando. Het vastleggen voor en na is wat dat zichtbaar maakt.
Deel alleen de namen en servercontext die het rapport nodig heeft, want interne achtervoegsels verraden de topologie. De systemd-resolved-documentatie over domeinroutering behandelt de langste-overeenkomst-regel en het tilde-gedrag, en één keer lezen voorkomt de meeste fouten in de tabel hierboven: vraagroutering in systemd-resolved.