Hogyan olvassuk a VPN DNS-útválasztást kapcsolatonként a resolvectl kimenetéből

Futtassa a resolvectl status parancsot, és kapcsolatonkénti blokkok falát kapja, mindegyik a saját kiszolgálóival és a saját tartománysorával. Az útválasztást eldöntő sor a tartománylista, nem a névkiszolgáló címe, mert a helyi stub minden lekérdezést ahhoz a kapcsolathoz továbbít, amelyik igényt tart a névre. Olvassa el ezeket az igényeket, mielőtt a választ olvassa, majd kérdezze le a nevet, és ellenőrizze, melyik kapcsolat állította elő. A helyes kapcsolattól kapott hibás válasz más probléma, mint a hibás kapcsolattól kapott helyes válasz.

Mit mond el az egyes kapcsolatonkénti blokk

Minden blokk felsorolja a kiszolgálókat, amelyeket a feloldó az adott interfészhez használ, a tartománylistát és azt, hogy a kapcsolat az alapértelmezett útvonal-e. A tartománylista igények halmaza, és a feloldó a leghosszabb utótag egyezését alkalmazza: a host.corp.example lekérdezésére a corp.example-t hordozó kapcsolat tart igényt, mielőtt az, amelyik csak az alapértelmezett útvonalat hordozza. Két kapcsolat, amely ugyanarra az utótagra tart igényt, a prioritásra és a sorrendre hagyja az eredményt, ezért a duplikátumok érdemelnek első figyelmet. Az aktuális kiszolgáló sor megmutatja, melyik felsorolt kiszolgáló van éppen használatban.

Egy stub-cím, például 127.0.0.53 az /etc/resolv.conf fájlban csak azt mondja, hogy a stub elöl van. Nem nevezi meg a válaszoló felsőbb forrást, ezért a csak resolv.conf-ra támaszkodó diagnózis elakad.

Olvassa helyesen a háromféle tartománybejegyzést

A tilde a keresési viselkedést változtatja meg, nem az útválasztást. A tilde nélküli bejegyzés egyszerre útválasztási tartomány és keresési tartomány, ezért az alatta lévő nevek ahhoz a kapcsolathoz mennek, és az egyszerű címkés nevekhez hozzáfűződik az utótag. A tildés bejegyzés ugyanazt az utótagot útválasztja, de kívül tartja a keresési listán. Ezért változtatja meg a tilde eltávolítása, mely csupasz nevek oldódnak fel, és ezért hiányzó tilde esetén keresési problémáról van szó, nem osztott DNS-meghibásodásról.

Az alapértelmezett útvonal bejegyzése mindenre igényt tart, amit semelyik másik kapcsolat nem fed le. A teljes alagút profil általában akarja, az osztott profil általában nem, mert a nyilvános nevek akkor a privát feloldóhoz utaznak, és ott meghiúsulhatnak. A táblázatot a profil szándékához mérve olvassa, ne másolja a jelzőket profilok között. Ha két kapcsolat ugyanarra az utótagra tart igényt, a prioritás kérdését rendezze, mielőtt bármi mást szerkeszt.

Kérdezzen le egy nevet, és nézze meg, melyik kapcsolat válaszolt

A query alparancs kiírja a címet, a protokollt és azt a kapcsolatot vagy hatókört, amely a választ előállította. Teszteljen egy nevet, amelyre a privát utótagnak igényt kellene tartania, és egy közönséges nyilvános nevet, majd hasonlítsa össze a jelentett forrásokat. Ha a privát név a vezeték nélküli kapcsolatból válaszol, az igény hiányzik, vagy az alagút leállt; ha egy nyilvános név osztott profilban az alagútból válaszol, az alapértelmezett útvonal túl széles. Ez a két hiba a böngészőben azonosnak, ebben a kimenetben pedig ellentétesnek látszik.

resolvectl status
resolvectl query host.corp.example

Figyelje a jelentett protokollt is, mert egy gyorsítótárazott vagy hosts-fájlból származó válasz úgy is megérkezhet, hogy egyetlen felsőbb forrást sem kérdeztek meg. A gyorsítótárból jött válasz azt bizonyítja, hogy a név valamikor feloldódott, nem azt, hogy a jelenlegi szabályzat helyesen útválasztja.

Tartsa külön a névútválasztást a csomagútválasztástól

A feloldó döntése nem hoz létre útvonalat. A kiválasztott kiszolgálónak még mindig kell útvonal a saját címéhez, és a visszakapott címnek még mindig kell útvonal a privát hálózatba, így egy helyes DNS-szabályzat együtt létezhet egy soha nem nyíló kapcsolattal. Ha egy név feloldódik, de az alkalmazás meghiúsul, vizsgálja meg a címet és az útvonalat, ahelyett hogy újra a DNS-t változtatná. A névfeloldás és az elérhetőség két kérdés, két különböző gazdával.

Az alkalmazások teljesen megkerülhetik a rendszer feloldóját saját biztonságos DNS-beállításukkal vagy egy beépített feloldóval. A resolvectl eredménye a rendszer útvonalát írja le, és egy böngésző, amely figyelmen kívül hagyja, minden tesztjével ellentmond. Ellenőrizze ezt a beállítást, mielőtt arra jut, hogy a szabályzat elromlott.

Jegyezze fel a címet, amelyre a név feloldódott, a kapcsolat mellé. Egy helyes név, amely rossz címre mutat, rekordprobléma, nem útválasztási probléma.

Ellenőrizze újra, miután a kapcsolat megváltozott

Az újracsatlakozás vagy a vezeték nélküli váltás újraépíti a kapcsolat állapotát, és a hálózatkezelő újratelepítheti a tartományait és kiszolgálóit minden kézzel beállított dolog fölé. Ezután kérdezze le ugyanazt a két nevet, és hasonlítsa össze a rögzített alapvonallal. Ha egy kézi szerkesztés eltűnt, a javítás a kapcsolatprofilba tartozik és nem egy shell-parancsba. Az előtte és utána való rögzítés az, ami ezt láthatóvá teszi.

Csak azokat a neveket és kiszolgáló-környezetet ossza meg, amelyekre a jelentésnek szüksége van, mert a belső utótagok felfedik a topológiát. A systemd-resolved tartomány-útválasztási dokumentációja kiterjed a leghosszabb egyezés szabályára és a tilde viselkedésére, és egyetlen olvasás megelőzi a fenti táblázat hibáinak többségét: lekérdezés-útválasztás a systemd-resolvedben.