Kaip skaityti VPN DNS maršrutizavimą pagal jungtį iš resolvectl
resolvectl status rodo serverius, domenus ir numatytąjį maršrutą pagal jungtį. Skaitykite juos kartu, tada užklauskite vardą ir pažymėkite, kuri jungtis atsakė.
Paleiskite resolvectl status ir gausite sieną blokų pagal jungtį, kiekvienas su savo serveriais ir savo domenų eilute. Maršrutizavimą lemia domenų sąrašas, o ne vardų serverio adresas, nes vietinis stub perduoda kiekvieną užklausą tai jungčiai, kuri pretenduoja į vardą. Perskaitykite tuos teiginius prieš skaitydami atsakymą, tada užklauskite vardą ir patikrinkite, kuri jungtis jį sukūrė. Neteisingas atsakymas iš teisingos jungties yra kita problema nei teisingas atsakymas iš neteisingos.
Ką jums sako kiekvienas jungties blokas
Kiekvienas blokas išvardija serverius, kuriuos sprendiklis naudos tam sąsajai, domenų sąrašą ir ar jungtis yra numatytasis maršrutas. Domenų sąrašas yra teiginių rinkinys, o sprendiklis taiko ilgiausio priesago atitikimą: užklausą dėl host.corp.example pretenduoja jungtis, turinti corp.example, prieš tą, kuri turi tik numatytąjį maršrutą. Dvi jungtys, pretenduojančios į tą pačią priesagą, palieka rezultatą prioritetui ir tvarkai, todėl dublikatai pirmiausia verti dėmesio. Dabartinio serverio eilutė rodo, kuris iš išvardytų serverių tuo metu naudojamas.
Stub adresas, pavyzdžiui, 127.0.0.53 faile /etc/resolv.conf, sako tik tai, kad stub yra priekyje. Jis neįvardija aukštesniojo srauto, kuris atsakė, todėl diagnostika, pagrįsta vien resolv.conf, įstringa.
Teisingai skaitykite tris domenų įrašų tipus
| Įrašas | Į ką jis pretenduoja | Įprasta klaida |
|---|---|---|
| corp.example | maršrutizavimo domenas ir paieškos priesaga: vardai po juo eina į šią jungtį, o eilutė pridedama prie plikų vardų | pašalintas, nes maršrutizavimas vis tiek atrodo veikiantis |
| ~corp.example | tik maršrutas: vardai po juo eina į šią jungtį, bet priesaga nepridedama | manyta, kad jis būtinas maršrutizavimui |
| ~. | numatytasis maršrutas: pretenduoja į užklausas, kurių nedengia jokia kita jungtis | paliktas aktyvus padalintame profilyje, todėl vieši vardai eina tuneliu |
Tildė keičia paieškos elgseną, o ne maršrutizavimą. Įrašas be tildės yra ir maršrutizavimo domenas, ir paieškos domenas, todėl vardai po juo siunčiami į tą jungtį, o vienos etiketės vardams pridedama priesaga. Įrašas su tilde maršrutizuoja tą pačią priesagą, bet laiko ją už paieškos sąrašo ribų. Todėl tildės pašalinimas keičia, kurie pliki vardai išsprendžiami, ir todėl trūkstama tildė yra paieškos problema, o ne padalinto DNS gedimas.
Numatytojo maršruto įrašas pretenduoja į viską, ko nedengia jokia kita jungtis. Viso tunelio profilis paprastai jo nori, o padalintas profilis paprastai ne, nes vieši vardai tada keliauja į privatų sprendiklį ir gali ten nepavykti. Skaitykite lentelę pagal profilio ketinimą, o ne kopijuokite vėliavėles tarp profilių. Kai dvi jungtys pretenduoja į tą pačią priesagą, išspręskite prioriteto klausimą prieš redaguodami ką nors kita.
Užklauskite vardo ir pamatykite, kuri jungtis atsakė
Potipis query išspausdina adresą, protokolą ir jungtį ar sritį, kurios sukūrė atsakymą. Išbandykite vieną vardą, kurį turėtų pretenduoti privati priesaga, ir vieną įprastą viešą vardą, tada palyginkite praneštus šaltinius. Jei privatus vardas atsako iš belaidės jungties, teiginio trūksta arba tunelis yra išjungtas; jei viešas vardas padalintame profilyje atsako iš tunelio, numatytasis maršrutas yra per platus. Šie du gedimai naršyklėje atrodo vienodai, o šioje išvestyje priešingai.
resolvectl status
resolvectl query host.corp.exampleStebėkite ir praneštą protokolą, nes atsakymas iš podėlio arba hosts failo gali atkeliauti neklausus jokio aukštesniojo srauto. Atsakymas iš podėlio įrodo, kad vardas kadaise buvo išspręstas, o ne tai, kad dabartinė politika jį teisingai maršrutizuoja.
Laikykite vardų maršrutizavimą atskirai nuo paketų maršrutizavimo
Sprendiklio sprendimas nesukuria kelio. Pasirinktas serveris vis dar turi maršrutą į savo adresą, o grąžintas adresas vis dar turi maršrutą į privatų tinklą, todėl teisinga DNS politika gali egzistuoti kartu su ryšiu, kuris niekada neatsidaro. Kai vardas išsprendžiamas, o programa nepavyksta, patikrinkite adresą ir maršrutą, o ne keiskite DNS dar kartą. Vardų sprendimas ir pasiekiamumas yra du klausimai su dviem skirtingais savininkais.
Programos gali visiškai apeiti sistemos sprendiklį per savo saugaus DNS nustatymą arba įterptą sprendiklį. resolvectl rezultatas aprašo sistemos kelią, o naršyklė, kuri jo nepaiso, nesutars su kiekvienu jūsų testu. Patikrinkite tą nustatymą prieš darydami išvadą, kad politika sulaužyta.
Užrašykite adresą, į kurį vardas išspręstas, šalia jungties. Teisingas vardas, rodantis į neteisingą adresą, yra įrašo problema, o ne maršrutizavimo.
Patikrinkite dar kartą, kai jungtis pasikeis
Prisijungimas iš naujo arba belaidžio tinklo pakeitimas iš naujo sukuria jungties būseną, o tinklo tvarkyklė gali iš naujo įdiegti savo domenus ir serverius ant visko, kas nustatyta ranka. Tada užklauskite tuos pačius du vardus ir palyginkite su užrašyta bazine linija. Jei rankinis pakeitimas dingo, pataisa priklauso ryšio profiliui ir ne apvalkalo komandai. Būtent užrašymas prieš ir po padaro tai matomu.
Bendrinkite tik tuos vardus ir serverio kontekstą, kurių reikia ataskaitai, nes vidinės priesagos atskleidžia topologiją. systemd-resolved dokumentacija apie domenų maršrutizavimą apima ilgiausio atitikimo taisyklę ir tildės elgseną, ir vienas perskaitymas užkerta kelią daugumai aukščiau pateiktos lentelės klaidų: užklausų maršrutizavimas systemd-resolved.