Hoe't jo VPN-DNS-rûting per keppeling lêze út resolvectl
resolvectl status toant tsjinners, domeinen en de standertrûte per keppeling. Lês se tegearre, freegje dan de namme op en notearje hokker keppeling antwurde.
Fier resolvectl status út en jo krije in muorre fan blokken per keppeling, elk mei syn eigen tsjinners en syn eigen domeinrigel. De rigel dy't de rûting beslút is de domeinlist, net it adres fan de nammentsjinner, om't de lokale stub elke fraach trochstjoert nei de keppeling dy't de namme claimt. Lês dy claims foardat jo it antwurd lêze, freegje dan de namme op en kontrolearje hokker keppeling it makke hat. In ferkeard antwurd fan 'e goede keppeling is in oar probleem as in goed antwurd fan 'e ferkearde.
Wat elk blok per keppeling jo fertelt
Elk blok listet de tsjinners op dy't de resolver foar dat ynterface brûkt, de domeinlist en oft de keppeling de standertrûte is. De domeinlist is in set claims, en de resolver past de langste-efterheaksel-oerienkomst ta: in fraach foar host.corp.example wurdt claimt troch in keppeling mei corp.example foar ien dy't allinnich de standertrûte hat. Twa keppelings dy't itselde efterheaksel claimje litte it resultaat oan prioriteit en oardering oer, dêrom fertsjinje dûblêden earst oandacht. De rigel fan 'e aktuele tsjinner toant hokker fan 'e neamde tsjinners op dat stuit brûkt wurdt.
In stub-adres lykas 127.0.0.53 yn /etc/resolv.conf seit allinnich dat de stub foaroan stiet. It neamt net de upstream dy't antwurde, dêrom rint in diagnoaze dy't allinnich op resolv.conf bout fêst.
Lês de trije soarten domeinynfieringen goed
| Ynfiering | Wat it claimt | Gebrûklike flater |
|---|---|---|
| corp.example | rûtingdomein en sykefterheaksel: nammen dêrûnder geane nei dizze keppeling, en de tekst wurdt taheakke oan keale nammen | fuortsmiten om't rûting dochs wol liket te wurkjen |
| ~corp.example | allinnich rûte: nammen dêrûnder geane nei dizze keppeling, mar it efterheaksel wurdt net taheakke | oanommen dat it nedich is foar rûting |
| ~. | standertrûte: claimt fragen dy't gjin oare keppeling dekt | aktyf litten op in splitst profyl, sadat iepenbiere nammen de tunnel folgje |
De tilde feroaret sykgedrach, net rûting. In ynfiering sûnder tilde is sawol in rûtingdomein as in sykdomein, dus nammen dêrûnder wurde nei dy keppeling stjoerd en oan ien-label-nammen wurdt it efterheaksel taheakke. In tilde-ynfiering rûtet itselde efterheaksel wylst it bûten de syklist holden wurdt. Dêrom feroaret it fuortheljen fan in tilde hokker keale nammen oplost wurde, en dêrom is in ûntbrekkende tilde in sykprobleem en gjin flater fan splitst DNS.
De standertrûte-ynfiering claimt alles wat gjin oare keppeling dekt. In folsleine-tunnelprofyl wol it meastentiids en in splitst profyl meastentiids net, om't iepenbiere nammen dan nei de privee resolver reizgje en dêr miskien mislearje. Lês de tabel tsjin 'e bedoeling fan it profyl yn ynstee fan flaggen tusken profylen te kopiearjen. As twa keppelings itselde efterheaksel claimje, besljochtsje dan de prioriteitskwestje foardat jo eat oars bewurkje.
Freegje in namme op en sjoch hokker keppeling antwurde
It subkommando query prints it adres, it protokol en de keppeling of it berik dat it antwurd makke hat. Test ien namme dy't it privee efterheaksel claimje moat en ien gewoane iepenbiere namme, en fergelykje dan de rapporteare boarnen. As de privee namme fan 'e draadleaze keppeling antwurdet, ûntbrekt de claim of is de tunnel del; as in iepenbiere namme op in splitst profyl fan 'e tunnel antwurdet, is de standertrûte te breed. Dy twa flaters lykje itselde yn in browser en tsjinoersteld yn dizze útfier.
resolvectl status
resolvectl query host.corp.exampleLet ek op it rapporteare protokol, om't in antwurd út 'e cache of út it hosts-bestân komme kin sûnder dat ien upstream frege is. In antwurd út 'e cache bewiist dat de namme ea oplost is, net dat it hjoeddeiske belied him goed rûtet.
Hâld nammerûting los fan pakketrûting
In resolverbeslút makket gjin paad. De keazen tsjinner hat noch altyd in rûte nei syn adres nedich, en it weromjûne adres hat noch altyd in rûte it privee netwurk yn nedich, dus in goed DNS-belied kin bestean njonken in ferbining dy't nea iepenet. As in namme oplost en de applikaasje mislearret, besjoch dan it adres en de rûte ynstee fan DNS wer te feroarjen. Namme-oplossing en berikberens binne twa fragen mei twa ferskillende eigners.
Applikaasjes kinne de systeemresolver folslein omsile fia har eigen ynstelling foar feilige DNS of in ynboude resolver. It resolvectl-resultaat beskriuwt it systeempad, en in browser dy't it negearret sil it mei elke test dy't jo dogge iens wêze. Kontrolearje dy ynstelling foardat jo konkludearje dat it belied stikken is.
Notearje it adres dêr't de namme nei oplost is njonken de keppeling. In goede namme dy't nei it ferkearde adres wiist is in recordprobleem en gjin rûtingprobleem.
Kontrolearje opnij nei't de keppeling feroare is
In werferbining of in draadleaze wiksel bout de keppelingstastân opnij, en in netwurkbehearder kin syn domeinen en tsjinners oer alles hinne ynstallearje wat mei de hân set is. Freegje dêrnei deselde twa nammen op en fergelykje mei de fêstleine basisline. As in hânmjittige bewurking ferdwûn is, heart de reparaasje yn it ferbiningsprofyl en net yn in shell-opdracht. Foar en nei fêstlizze is wat dat sichtber makket.
Diel allinnich de nammen en tsjinnerkontekst dy't it rapport nedich hat, om't ynterne efterheaksels topology ferriede. De systemd-resolved-dokumintaasje oer domeinrûting beslacht de langste-oerienkomst-regel en it tilde-gedrach, en ien kear lêze foarkomt de measte tabelflaters hjirboppe: fraachrûting yn systemd-resolved.