Ang NXDOMAIN sa VPN ay hindi pagkasira ng tunnel

Nakakatuksong basahin ang isang nabigong paghahanap bilang patunay na gumuho ang tunnel, lalo na kapag gumana ang pangalan sampung minuto ang nakalipas. Iba ang sinasabi ng sagot. Ang NXDOMAIN ay isang kumpletong transaksyon ng DNS kung saan inihayag ng resolver na wala ang pangalang itinanong; ang sirang tunnel ay karaniwang nagdudulot ng katahimikan, timeout o pagtatangkang mag-resolve sa maling server. Ang bersyon ng argumento na walang wireshark ay isang query, isang sumasagot at isang code ng sagot, at ang triad na iyon ay dapat itala bago ang anumang pagbabago sa configuration.

Ano ang tunay na pinapatunayan ng sagot

Hinihiwalay ng DNS ang mga resulta na madalas pagsamahin ng mga client sa isang kabiguan. Ang pangalang wala ay gumagawa ng negatibong sagot na may code na NXDOMAIN, samantalang ang pangalang umiiral ngunit walang record ng hiniling na uri ay gumagawa ng matagumpay na sagot na may walang laman na seksyon ng mga sagot. Pareho silang mukhang walang silbi sa isang application, at isa lamang sa kanila ang nangangahulugang mali ang pangalan.

Ang pagkakaibang iyon ang nagtatakda kung saan nararapat ang pagkukumpuni. Ang nawawalang record na AAAA sa isang host na may record na A ay hindi nawawalang host, at ang muling pag-isyu ng sertipiko o muling pagbuo ng tunnel upang habulin iyon ay nag-aaksaya ng nag-iisang bakas na magagamit. Itinatakda rin ng pagkakaiba ang anyo ng kasunod: ang problema sa pagpapangalan ay inaayos sa zone, at ang problema sa uri ay inaayos sa pamamagitan ng paghingi ng tamang record o sa pagtanggap na wala talaga ang pamilya ng address.

Ang mito: ang nawawalang pribadong pangalan ay nangangahulugang nabigo ang tunnel

Nabubuhay ang mito dahil madalas magkasabay ang dalawang pangyayari. Kumokonekta ang client sa VPN, pinapanatili ng operating system ang isang resolver na pinagkatiwalaan na nito, at ang panloob na pangalan na kailangan nito ngayon ay itinatanong sa isang server na hindi kailanman nakarinig tungkol sa pribadong zone. Tapat at negatibong sumasagot ang server na iyon. Dinadala ng tunnel ang packet; ang sagot ay tungkol lamang sa isang espasyo ng pangalan na hindi pinaglilingkuran ng sumasagot.

Ginagawa ng mga kaayusang split-horizon na karaniwan ito: ang parehong pangalan ng zone ay umiiral sa publiko at sa loob na may magkaibang nilalaman, at ang panloob na resolver lamang ang nakakaalam ng mga pribadong record. Kaya ang pagkuha ng negatibong sagot na mukhang may awtoridad ay patunay kung aling resolver ang sumagot, hindi patunay ng kalagayan ng interface.

Dalawang detalye ng configuration ang nagtatakda ng resulta. Dapat itulak o piliin ng tunnel ang panloob na resolver, at dapat ilapat ng client ang pagpiling iyon sa pangalang hinahanap. Ang tuntunin sa bawat domain na nagpapangalan ng suffix na bahagyang naiiba sa record na iyong tina-type ay magpapadala ng query sa pampublikong landas, at ang sagot ay magiging tama ngunit walang silbi.

Itanong sa tamang resolver gamit ang tamang pangalan

Itala ang sumasagot bago itala ang hatol. Ang paghahanap na hindi nagpapakita kung aling server ang sumagot ay hindi makakapaghiwalay ng problema sa patakaran mula sa problema sa espasyo ng pangalan, at ang dalawa ay may magkaibang pagkukumpuni.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Ipinapakita ng unang dalawang linya kung ano ang pinagpasyahan ng lokal na resolver at kanino ito tatanong. Ginagaya ng paghahanap na +search ang ginagawa ng application kapag nagdadagdag ito ng suffix ng paghahanap, na kadalasan ay ang tunay na query at hindi ang tina-type sa isang diagnostic tool. Direktang tinatanong ng huling linya ang panloob na server, na nilalampasan ang patakaran ng client; kung nagtagumpay iyon habang nabigo ang karaniwang paghahanap, maayos ang zone at hindi maayos ang routing ng mga query.

Ipinapaliwanag ng negatibong caching ang pagkaantala pagkatapos ng pagkukumpuni

Ang mga negatibong sagot ay naka-cache ayon sa disenyo, at inilalarawan ng RFC 2308 kung paano hinango ang buhay ng negatibong cache mula sa authority record ng zone. Kaya ang pagwawasto ng record o ng tuntunin ng resolver ay hindi ginagarantiyahan ang agarang pagbabago sa client, at ang muling pagsubok sa paghahanap na patuloy na nagbabalik ng naka-cache na sagot ay walang bagong pinapatunayan. Tanging ibang sumasagot, ibang pangalan o na-clear na cache ang nagbibigay ng sariwang patunay.

I-clear ang lokal na cache, pagkatapos ulitin ang parehong query laban sa parehong sumasagot. Sa mga sistemang gumagamit ng lokal na serbisyo ng resolver, isa itong utos; sa iba, ito ay restart ng serbisyo o utility ng platform, at ang partikular na tool ay hindi gaanong mahalaga kaysa sa pag-ulit ng magkatulad na pagsubok pagkatapos.

Ihiwalay ang pangalan sa landas

Kapag na-resolve na ang pangalan sa inaasahang pribadong address, tapos na ang DNS bilang paksa at ang landas ng application ang susunod na tanong. Ang host na sumasagot sa mga paghahanap ngunit tumatanggi sa koneksyon ay may ibang problema, at ang patuloy na pagsasaayos ng mga resolver pagkatapos ng tamang sagot ay ang paraan ng pagkakaroon ng isang insidente ng tatlong walang kaugnayang pagbabago. Ihambing ang na-resolve na address sa address na aktuwal na pinakikinggan ng serbisyo bago ipagpalagay na pareho sila.

Itago ang transcript: ang query, ang sumasagot, ang code at ang na-resolve na address. Ang rekord na iyon din ang nagpapaging-verifyable sa isang ulat sa hinaharap, at iyon ang pagkakaiba ng isang diagnosis at isang kuwento tungkol sa tunnel na tila mabagal.