Vaša VPN domena v dnsmasqu ni prenos cone

V dnsmasq konfiguraciji odjemalca iščete korporativno cono, je ne najdete in sklepate, da VPN ni potisnil svoje domene. Kar je bilo potisnjeno, je namig za usmerjanje, ne cona. Odjemalec zabeleži domeno in resolver, ki naj bi zanjo odgovarjal, upravljani zaledni sistem pa to spremeni v pogojno posredovanje. Iskanje na napačnem mestu da samozavestno in popolnoma napačno diagnozo.

Kar je odjemalec sprejel, ni tisto, kar je ponudil prehod

Prehod lahko ponudi resolver, domeno in pot, potrebno do tega resolverja, odjemalec pa lahko sprejme vse tri ali nobenega od njih. Uvožen profil, pomožna skripta ali pravilnik, ki ignorira potisnjene možnosti, lahko pusti sprejeti nabor prazen, medtem ko je strežniška stran videti pravilna. Začnite pri zabeleženem stanju odjemalca in ne pri konfiguraciji strežnika, ker je to stanje tisto, kar resolver dejansko prejme. Če sprejeta domena manjka, nič nadaljnjega ne bo pomembno. Preden pregledate predpomnilnik, preverite lastnosti DNS povezave.

Ta razlika pojasnjuje večino poročil o domeni, ki ni nikoli prispela. Bila je ponujena in ni bila uporabljena.

Dve vrsti vnosov domene

Povezava lahko nosi običajne iskalne domene in domene samo za usmerjanje, druga vrsta pa se začne s tildo. Iskalna domena usmerja poizvedbe in dovoli širjenje kratkih imen, kar je priročno na delovni postaji in presenetljivo na strežniku. Domena samo za usmerjanje pravi, da morajo poizvedbe za to pripono iti na določene strežnike, ne da bi spremenila, kako se razrešujejo kratka imena. Pisanje iste domene na oba načina ni odveč, ker dva vnosa opravljata različni nalogi.

Za zasebni imenski prostor je oblika samo za usmerjanje običajno tista, ki jo želite. Ohranja korporativno pripono usmerjeno na korporativni resolver in vse ostalo pusti pri miru.

localhost v resolv.conf ni napaka

Ko se uporablja lokalni predpomnilniški resolver, sistemska datoteka kaže na povratni naslov in nič drugega. Ta vnos označuje lokalnega poslušalca, ne pa nadrejenih strežnikov, ki mu jih je predal upravitelj. Korporativni naslov bo v datoteki upravičeno manjkal.

Zamenjava tega vnosa z javnim resolverjem je klasičen napačen popravek. Obnovi javno razreševanje imen in v istem urejanju zavrže pogojni pravilnik.

Ne mešajte zalednih sistemov

Upravljani primerek dnsmasq in sistemski resolver sta različna programa z različno konfiguracijo in različnimi pogledi stanja. Statusni ukaz za enega ne pove nič koristnega o drugem.

Ugotovite, kateri zaledni sistem naj upravitelj uporablja, nato preberite ustvarjeno konfiguracijo tega zalednega sistema, ne pa distribucijske datoteke, ki slučajno obstaja. Upravitelj piše lastno konfiguracijo primerka in podpira možnosti po meri za ta primerek, zato urejanje nepovezane globalne datoteke ne spremeni ničesar in je videti kot sprememba brez učinka. Zagon drugega daemona na vratih 53 je slabši od neuporabnega, ker se zdaj dva programa ne strinjata, komu pripadajo vrata. Najprej ugotovite lastnika, nato urejajte tam, kjer lastnik bere.

Preizkusite imenski prostor, ne le odgovora

Poizvedite po enem dovoljenem zasebnem imenu in enem javnem kontrolnem imenu po običajni poti aplikacije. Neposredna poizvedba na korporativni strežnik dokaže, da zapis obstaja; ne dokaže, da je odjemalec izbral ta strežnik. Druga poizvedba je tista, ki preizkusi pravilnik.

Nato ponovite po ponovni povezavi in po prekinitvi. Povezava naj sledi življenjskemu ciklu povezave, zasebna imena pa naj se prenehajo razreševati, ko tunela ni več, namesto da bi se zatekla k javnemu resolverju, ki odgovarja za isto pripono. Če se vendarle zatečejo, ste našli uhajanje, kar je druga napaka kot pokvarjeno iskanje. Zapišite, kateri zaledni sistem je tekel, katere domene so bile uporabljene in kaj je vrnila vsaka poizvedba.