Jūsų VPN domenas dnsmasq programoje nėra zonos perdavimas

Jūs ieškote įmonės zonos kliento dnsmasq konfigūracijoje, nerandate jos ir darote išvadą, kad VPN neišsiuntė savo domeno. Tai, kas buvo išsiųsta, yra maršrutizavimo užuomina, o ne zona. Klientas įrašo domeną ir resolver, kuris turėtų už jį atsakyti, o valdomas backend tai paverčia sąlyginiu persiuntimu. Paieška ne toje vietoje duoda užtikrintą ir visiškai klaidingą diagnozę.

Tai, ką klientas priėmė, nėra tai, ką pasiūlė šliuzas

Šliuzas gali pasiūlyti resolver, domeną ir maršrutą, reikalingą pasiekti tą resolver, o klientas gali priimti visus tris arba nė vieno jų. Importuotas profilis, pagalbinis scenarijus ar politika, kuri ignoruoja išsiųstas parinktis, gali palikti priimtą rinkinį tuščią, nors serverio pusė atrodo teisingai. Pradėkite nuo užfiksuotos kliento būsenos, o ne nuo serverio konfigūracijos, nes būtent tą būseną resolver iš tikrųjų gauna. Jei priimto domeno trūksta, niekas toliau nebeturės reikšmės. Prieš tikrindami bet kokią podėlio atmintį patikrinkite ryšio DNS savybes.

Šis skirtumas paaiškina daugumą pranešimų apie domeną, kuris taip ir neatvyko. Jis buvo pasiūlytas ir nebuvo pritaikytas.

Dviejų rūšių domeno įrašai

Ryšys gali nešti įprastus paieškos domenus ir tik maršrutizavimo domenus, o antroji rūšis prasideda tildės ženklu. Paieškos domenas ir nukreipia užklausas, ir leidžia išplėsti trumpus vardus, kas patogu darbo stotyje ir netikėta serveryje. Tik maršrutizavimo domenas nurodo, kad tos priesagos užklausos turi būti siunčiamos konkretiems serveriams nekeičiant to, kaip sprendžiami trumpi vardai. Rašyti tą patį domeną abiem būdais nėra perteklius, nes du įrašai atlieka skirtingus darbus.

Privačiai vardų erdvei paprastai norite tik maršrutizavimo formos. Ji išlaiko įmonės priesagą nukreiptą į įmonės resolver ir palieka visa kita ramybėje.

localhost resolv.conf faile nėra klaida

Kai naudojamas vietinis talpinantis resolver, sistemos failas nurodo loopback adresą ir nieko daugiau. Tas įrašas žymi vietinį klausytoją, o ne viršutinio lygio serverius, kuriuos jam perdavė tvarkyklė. Įmonės adreso faile teisėtai nebus.

Pakeisti tą įrašą viešu resolver yra klasikinis klaidingas taisymas. Jis atkuria viešą vardų sprendimą ir tame pačiame pakeitime atmeta sąlyginę politiką.

Nesupainokite backendų

Valdoma dnsmasq instancija ir sistemos resolver yra skirtingos programos su skirtinga konfigūracija ir skirtingais būsenos vaizdais. Vienos būsenos komanda nieko naudingo nepasako apie kitą.

Nustatykite, kurį backend tvarkyklė sukonfigūruota naudoti, tada skaitykite to backend sugeneruotą konfigūraciją, o ne visos distribucijos failą, kuris atsitiktinai egzistuoja. Tvarkyklė rašo savo instancijos konfigūraciją ir palaiko pasirinktines parinktis tai instancijai, todėl nesusijusio globalaus failo redagavimas nieko nekeičia ir atrodo kaip pakeitimas be poveikio. Antro daemono paleidimas 53 prievade yra blogiau nei nenaudinga, nes dabar dvi programos nesutaria, kam priklauso prievadas. Pirmiausia nustatykite savininką, tada redaguokite ten, kur tas savininkas skaito.

Tikrinkite vardų erdvę, o ne tik atsakymą

Užklauskite vieną leistiną privatų vardą ir vieną viešą kontrolinį vardą įprastu programos keliu. Tiesioginė užklausa įmonės serveriui įrodo, kad įrašas egzistuoja; ji neįrodo, kad klientas pasirinko tą serverį. Antroji užklausa yra ta, kuri tikrina politiką.

Tada pakartokite po prisijungimo iš naujo ir po atsijungimo. Susiejimas turėtų sekti ryšio gyvavimo ciklą, o privatūs vardai turėtų nustoti spręstis, kai tunelio nebėra, o ne grįžti prie viešo resolver, kuris atsako už tą pačią priesagą. Jei jie vis dėlto grįžta, radote nuotėkį, kuris yra kitas defektas nei sugedusi paieška. Užrašykite, kuris backend veikė, kurie domenai buvo pritaikyti ir ką grąžino kiekviena užklausa.