mDNS sa loob ng VPN: bakit hindi nareresolba ang mga pangalang .local

Lumilitaw ang printer sa opisina sa bawat app sa iyong mesa at nawawala sa VPN, kahit na maaari mong i-ping ang address na alam mong mayroon ito. Walang sira sa tunnel: magkaibang serbisyo ang pagtuklas at pag-abot, at sa default ay isa lang sa kanila ang tumatawid sa ruted tunnel. Hinihiwalay sila ng mga tseke sa ibaba bago ka magsimulang magdagdag ng ruta. Hindi kayang ayusin ng ruta ang query na hindi kailanman umalis sa link.

Tingnan kung ano ang nareresolba ngayon, at kung ano ang mukhang nareresolba lang

Hiwalayin muna ang dalawang tanong: ang unicast query para sa hostname ay nagtatanong sa resolver, samantalang ang paghahanap ng _ipp._tcp ay nagtatanong sa lokal na link. Sa Linux, ipinapakita ng avahi-browse -a kung ano ang nakikita ng multicast DNS, at ipinapakita ng resolvectl query name.local kung ano ang ginagawa ng resolver stack sa pangalang iyon. Sa macOS, inililista ng dns-sd -B _ipp._tcp ang mga natuklasang serbisyo nang hindi kailangan muna ng address.

Kung sumasagot ang address at hindi ang pangalan, gumagana ang routing at hindi ang pagtuklas. Ang pangalang .local ay maaari ring sagutin sa host mismo sa pamamagitan ng nss-mdns nang walang naka-install na avahi-browse, kaya ang matagumpay na getent o ping sa pangalang iyon ay hindi patunay na tumawid ang pagtuklas sa tunnel; magkaibang ebidensya ang resulta ng paghahanap at resulta ng resolver. Nag-cache ang mga app ng natuklasan nila, kaya madalas lumitaw ang failure pagkalipas ng mga oras mula sa pagkonekta, hindi sa sandali ng pagkonekta. Isara at muling buksan ang app, pagkatapos ay tingnan kung may pangalan o address ang naka-cache na entry, dahil patuloy na gumagana ang address nang matagal pagkatapos huminto ang pagtuklas.

Bakit hindi kailanman tumatawid ang query sa tunnel

Nagpapadala ang multicast DNS ng mga query sa 224.0.0.251, sa loob ng control block ng lokal na network, sa UDP port 5353. Hindi ipinapasa ng mga router ang mga address mula sa block na iyon, kaya nananatili ang query sa link kung saan ito ipinadala. Itinakda rin ng mga sender ang IP TTL, o ang hop limit ng IPv6, sa 255 upang matanggap ng receiver ang pagtanggi sa packet na dumaan na sa router; ganito natutukoy ng protocol ang spoofing sa labas ng link, hindi ganito ito nananatiling lokal. Ang lokalidad ay nagmumula sa destinasyong address, hindi sa TTL ng isang hop.

Mahalaga rin ang uri ng tunnel. Ang interface na tulad ng tun ay nagdadala lamang ng IP packets at wala nang iba, kaya walang multicast group ang nakakaligtas dito. Ang tulay na tulad ng tap ay nagpapalawak ng broadcast domain mismo, kaya ang ilang lumang disenyo ay nagtulay sa halip na mag-rute, at minana ang bawat problemang dala ng tulay.

Walang binabago ang pagbubukod para sa pinagkakatiwalaang LAN, dahil pinagpapasyahan nito kung aling trapiko ang maaaring gumamit ng tunnel sa halip na turuan ang tunnel na magpasa ng multicast. Wala pa ring shared segment ang packet kung saan ito maririnig.

Pumili ng disenyo ng pagpapangalan na kaya ninyong panatilihin

Para sa mga mapagkukunan ng kumpanya, ang matibay na sagot ay isang ruted hostname na pinaglilingkuran ng resolver na itinutulak ng VPN, kasama ang split DNS upang ang mga panloob na pangalan ay pumunta sa mga panloob na server at ang iba ay hindi. Inilalantad ito ng Windows bilang talahanayan ng patakaran sa pagresolba ng pangalan, gumagamit ang macOS ng mga scoped resolver kada interface, at karamihan ng mga kliyente ay may katumbas na push setting. Pinapanatili ng device ang karaniwang pangalan nito sa panloob na DNS, at tumitigil ang pagtuklas na maging bahagi ng landas.

Ang proxy ng pagtuklas o mDNS reflector ay maaaring magtulay sa puwang na ito, at ito ay isang tunay na disenyo na may sariling host, sariling exposure at sariling mga kinakailangan ng kliyente. Hindi ito lumilitaw dahil nagdagdag ka ng ruta. Huwag kailanman ipasa ang mga query na .local sa pampublikong resolver: ang domain ay nakalaan para sa lokal na paggamit ng multicast ng RFC 6762, at ang pagpapadala nito palabas ay nagdudulot ng mabagal na pagpalya at hindi kailangang pagbubunyag ng data.

Patunayan ang serbisyo, hindi ang pangalan

Ang pangalan sa listahan ng paghahanap ay nagpapatunay ng hakbang ng pagtuklas, hindi na sumasagot ang serbisyo. Buksan ang print queue o web interface at kumpletuhin ang isang tunay na operasyon, pagkatapos ay ulitin ito pagkatapos ng muling pagkonekta.

Aggressibong nag-cache ng mga pangalan ang pagtuklas, kaya ang lumang entry ay maaaring mukhang tagumpay. Kung may lumitaw na certificate o authentication prompt, iyon ang susunod na layer at hiwalay na problema. Isulat kung aling mekanismo ang binago mo, resolver o pagtuklas, upang hindi na kailangang buksan muli ng susunod na tao ang buong tanong.