Jūsu VPN domēns dnsmasq nav zonas pārsūtīšana

Jūs meklējat uzņēmuma zonu klienta dnsmasq konfigurācijā, neatrodat to un secināt, ka VPN nav nosūtījis savu domēnu. Tas, kas tika nosūtīts, ir maršrutēšanas norāde, nevis zona. Klients ieraksta domēnu un resolver, kam par to jāatbild, un pārvaldītais backend to pārvērš nosacītā pārsūtīšanā. Meklēšana nepareizā vietā dod pārliecinātu un pilnīgi nepareizu diagnozi.

Tas, ko klients pieņēma, nav tas, ko piedāvāja vārteja

Vārteja var piedāvāt resolver, domēnu un maršrutu, kas nepieciešams, lai sasniegtu šo resolver, un klients var pieņemt visus trīs vai nevienu no tiem. Importēts profils, palīgskripts vai politika, kas ignorē nosūtītās opcijas, var atstāt pieņemto kopu tukšu, kamēr servera puse izskatās pareizi. Sāciet ar klienta ierakstīto stāvokli, nevis ar servera konfigurāciju, jo tieši šo stāvokli resolver faktiski saņem. Ja pieņemtā domēna trūkst, nekas tālāk vairs nebūs svarīgs. Pirms pārbaudāt jebkuru kešatmiņu, pārbaudiet savienojuma DNS īpašības.

Šī atšķirība izskaidro lielāko daļu ziņojumu par domēnu, kas tā arī neieradās. Tas tika piedāvāts un netika piemērots.

Divu veidu domēna ieraksti

Savienojums var pārnēsāt parastos meklēšanas domēnus un tikai maršrutēšanas domēnus, un otrais veids sākas ar tildi. Meklēšanas domēns gan maršrutē vaicājumus, gan ļauj paplašināt īsos nosaukumus, kas ir ērti darbstacijā un pārsteidzoši serverī. Tikai maršrutēšanas domēns nosaka, ka vaicājumi šim sufiksam jāiet uz konkrētiem serveriem, nemainot to, kā tiek atrisināti īsie nosaukumi. Viena un tā paša domēna rakstīšana abos veidos nav lieka, jo abi ieraksti veic atšķirīgus darbus.

Privātai nosaukumu telpai parasti vēlaties tikai maršrutēšanas formu. Tā notur uzņēmuma sufiksu vērstu uz uzņēmuma resolver un atstāj visu pārējo mierā.

localhost resolv.conf nav kļūda

Kad tiek izmantots vietējais kešatmiņas resolver, sistēmas fails norāda uz loopback adresi un neko citu. Šis ieraksts apzīmē vietējo klausītāju, nevis augšupējos serverus, ko tam nodeva pārvaldnieks. Uzņēmuma adrese failā likumīgi nebūs.

Šī ieraksta aizstāšana ar publisku resolver ir klasiskais nepareizais labojums. Tas atjauno publisko nosaukumu atrisināšanu un tajā pašā labojumā atmet nosacīto politiku.

Nejauciet backendus

Pārvaldīta dnsmasq instance un sistēmas resolver ir dažādas programmas ar atšķirīgu konfigurāciju un atšķirīgiem statusa skatiem. Statusa komanda vienam nepasaka neko noderīgu par otru.

Nosakiet, kuru backend pārvaldnieks ir konfigurēts izmantot, pēc tam lasiet šī backenda ģenerēto konfigurāciju, nevis visas distribūcijas failu, kas nejauši pastāv. Pārvaldnieks raksta savu instances konfigurāciju un atbalsta pielāgotas opcijas šai instancei, tāpēc nesaistīta globālā faila rediģēšana neko nemaina un izskatās kā izmaiņas bez efekta. Otra dēmona palaišana 53. portā ir sliktāka par bezjēdzīgu, jo tagad divas programmas nevar vienoties, kam pieder ports. Vispirms nosakiet īpašnieku, pēc tam rediģējiet tur, kur šis īpašnieks lasa.

Pārbaudiet nosaukumu telpu, ne tikai atbildi

Vaicājiet vienu atļautu privātu nosaukumu un vienu publisku kontroles nosaukumu pa parasto programmas ceļu. Tiešs vaicājums uzņēmuma serverim pierāda, ka ieraksts pastāv; tas nepierāda, ka klients izvēlējās šo serveri. Otrais vaicājums ir tas, kas pārbauda politiku.

Pēc tam atkārtojiet pēc atkārtotas pieslēgšanās un pēc atvienošanās. Saistībai jāseko savienojuma dzīves ciklam, un privātajiem nosaukumiem jāpārstāj atrisināties, kad tuneļa vairs nav, nevis jāatgriežas pie publiska resolver, kas atbild par to pašu sufiksu. Ja tie tomēr atgriežas, jūs esat atradis noplūdi, kas ir cits defekts nekā salauzta meklēšana. Pierakstiet, kurš backend darbojās, kuri domēni tika piemēroti un ko atgrieza katrs vaicājums.