Ang VPN domain mo sa dnsmasq ay hindi zone transfer
Ang itinulak na domain ay patakaran, hindi zone file, at ang localhost sa resolv.conf ay maaaring tama. Sundin ang tinanggap na setting hanggang sa backend na talagang tumatakbo.
Hinahanap mo ang corporate zone sa dnsmasq configuration ng kliyente, hindi mo ito mahanap, at napagpasyahan mong nabigo ang VPN na itulak ang domain nito. Ang itinulak ay routing hint, hindi zone. Itinatala ng kliyente ang domain at ang resolver na dapat sumagot para dito, at ginagawa ito ng managed backend na conditional forwarding. Ang pagtingin sa maling lugar ay nagbubunga ng matatag at ganap na maling diagnosis.
Ang tinanggap ng kliyente ay hindi ang inialok ng gateway
Maaaring mag-alok ang gateway ng resolver, domain at ang rutang kailangan upang maabot ang resolver na iyon, at maaaring tanggapin ng kliyente ang tatlo o wala sa mga ito. Ang na-import na profile, helper script o patakarang hindi pinapansin ang itinulak na opsyon ay maaaring mag-iwan ng tinanggap na set na walang laman habang mukhang tama ang panig ng server. Magsimula sa naitalang estado ng kliyente sa halip na sa configuration ng server, dahil ang estadong iyon ang talagang natatanggap ng resolver. Kung wala ang tinanggap na domain, wala nang iba pang mahalaga. Suriin ang DNS properties ng koneksyon bago tingnan ang anumang cache.
Ipinapaliwanag ng pagkakaibang iyon ang karamihan sa mga ulat ng domain na hindi dumating. Inialok ito, at hindi ito inilapat.
Dalawang uri ng domain entry
Maaaring magdala ang koneksyon ng ordinaryong search domain at route-only domain, at ang pangalawang uri ay nagsisimula sa tilde. Ang search domain ay nagruruta ng mga query at pinapayagan ang maiikling pangalan na lumawak, na maginhawa sa workstation at nakakagulat sa server. Ang route-only domain ay nagsasabi na ang mga query para sa suffix na iyon ay dapat pumunta sa partikular na server nang hindi binabago kung paano nireresolba ang maiikling pangalan. Ang pagsulat ng parehong domain sa dalawang paraan ay hindi redundancy, dahil magkaiba ang trabaho ng dalawang entry.
Para sa isang pribadong namespace, ang route-only form ang karaniwang gusto mo. Pinapanatili nitong nakaturo ang corporate suffix sa corporate resolver at hinahayaan ang lahat ng iba.
Ang localhost sa resolv.conf ay hindi bug
Kapag gumagamit ng lokal na caching resolver, itinuturo ng system file ang loopback address at wala nang iba. Tinutukoy ng entry na iyon ang lokal na listener, hindi ang upstream servers na ibinigay ng manager dito. Ang corporate address ay lehitimong wala sa file.
Ang palitan ang entry na iyon ng public resolver ay ang klasikong maling pagtatama. Ibinabalik nito ang public name resolution at itinatapon ang conditional policy sa parehong edit.
Huwag ipagkamali ang mga backend
Ang managed dnsmasq instance at system resolver ay magkaibang programa na may magkaibang configuration at magkaibang status view. Ang status command para sa isa ay walang sinasabing kapaki-pakinabang tungkol sa isa.
Tukuyin kung aling backend ang naka-configure na gamitin ng manager, pagkatapos ay basahin ang generated configuration ng backend na iyon sa halip na isang distribution-wide file na nagkataong umiiral. Isinusulat ng manager ang sarili nitong instance configuration at sinusuportahan ang custom na opsyon para sa instance na iyon, kaya ang pag-edit ng walang kaugnayang global file ay walang binabago at mukhang pagbabagong walang epekto. Ang paglunsad ng pangalawang daemon sa port 53 ay mas masahol pa sa walang silbi, dahil ngayon ay hindi magkasundo ang dalawang programa kung sino ang may-ari ng port. Itatag muna ang may-ari, pagkatapos ay i-edit kung saan nagbabasa ang may-ari na iyon.
Subukan ang namespace, hindi lang ang sagot
Magtanong ng isang pinapayagang private name at isang public control name sa normal na landas ng application. Ang direktang query sa corporate server ay nagpapatunay na umiiral ang record; hindi nito pinapatunayan na pinili ng kliyente ang server na iyon. Ang pangalawang query ang sumusubok sa patakaran.
Pagkatapos ay ulitin pagkatapos ng reconnect at pagkatapos ng disconnect. Dapat sundin ng association ang lifecycle ng koneksyon, at dapat tumigil sa pagresolba ang mga private name kapag wala na ang tunnel, sa halip na bumalik sa public resolver na sumasagot sa parehong suffix. Kung bumabalik sila, nakakita ka ng leak, na ibang depekto kaysa sa sirang lookup. Isulat kung aling backend ang tumakbo, aling domain ang inilapat, at ano ang ibinalik ng bawat query.