mDNS znotraj VPN: zakaj se imena .local ne razrešijo

Tiskalnik v pisarni se pojavi v vsaki aplikaciji na vaši mizi in izgine na VPN, čeprav lahko pingate naslov, za katerega veste, da ga ima. V tunelu ni nič pokvarjeno: odkrivanje in dosegljivost sta ločeni storitvi in privzeto le ena od njiju prečka usmerjeni tunel. Spodnja preverjanja ju ločijo, preden začnete dodajati poti. Pot ne more popraviti poizvedbe, ki nikoli ni zapustila povezave.

Preverite, kaj se danes razreši in kaj se le zdi razrešeno

Najprej ločite vprašanji: poizvedba unicast za ime gostitelja vpraša razreševalnik, medtem ko iskanje _ipp._tcp vpraša lokalno povezavo. V Linuxu avahi-browse -a pokaže, kaj lahko vidi multicast DNS, resolvectl query name.local pa pokaže, kaj sklad razreševalnika naredi s tem imenom. V macOS dns-sd -B _ipp._tcp navede odkrite storitve, ne da bi najprej potreboval naslov.

Če naslov odgovori in ime ne, usmerjanje deluje, odkrivanje pa ne. Ime .local je mogoče odgovoriti tudi na gostitelju samem prek nss-mdns brez nameščenega avahi-browse, zato uspešen getent ali ping na to ime ni dokaz, da je odkrivanje prečkalo tunel; rezultat iskanja in rezultat razreševalnika sta različna dokaza. Aplikacije v predpomnilnik shranjujejo, kar so odkrile, zato se napaka pogosto pojavi ure po povezavi in ne ob povezavi. Zaprite in znova odprite aplikacijo, nato preverite, ali vnos v predpomnilniku vsebuje ime ali naslov, ker naslov deluje še dolgo po tem, ko se je odkrivanje ustavilo.

Zakaj poizvedba nikoli ne prečka tunela

Multicast DNS pošilja poizvedbe na 224.0.0.251, znotraj krmilnega bloka lokalnega omrežja, na vrata UDP 5353. Usmerjevalniki ne posredujejo naslovov iz tega bloka, zato poizvedba ostane na povezavi, kamor je bila poslana. Pošiljatelji nastavijo tudi IP TTL oziroma omejitev skokov IPv6 na 255, da lahko prejemnik zavrne paket, ki je že prečkal usmerjevalnik; tako protokol zazna ponarejanje zunaj povezave, ne pa tako ostane lokalno. Lokalnost izhaja iz ciljnega naslova, ne iz TTL enega skoka.

Tudi vrsta tunela je pomembna. Vmesnik v slogu tun prenaša pakete IP in nič drugega, zato nobena skupina multicast ne preživi. Most v slogu tap razširi samo domeno oddajanja, zato so nekateri stari načrti mostili namesto usmerjali in podedovali vse težave, ki jih prinaša most.

Izjema za zaupanja vredno LAN ne spremeni ničesar od tega, ker odloča, kateri promet sme uporabljati tunel, namesto da bi tunel učila posredovati multicast. Paket še vedno nima skupnega segmenta, na katerem bi bil slišen.

Izberite zasnovo poimenovanja, ki jo zmorete vzdrževati

Za vire podjetja je trajen odgovor usmerjeno ime gostitelja, ki ga streže razreševalnik, ki ga VPN potisne, skupaj z razdeljenim DNS, da gredo notranja imena na notranje strežnike, vse ostalo pa ne. Windows to izpostavi kot tabelo pravilnika razreševanja imen, macOS uporablja omejene razreševalnike za vsak vmesnik in večina odjemalcev ima enakovredno nastavitev potiskanja. Naprava ohrani svoje običajno ime v notranjem DNS in odkrivanje preneha biti del poti.

Poizvedovalni posrednik ali odsevnik mDNS lahko premosti to vrzel in to je resnična zasnova z lastnim gostiteljem, lastno izpostavitvijo in lastnimi zahtevami odjemalca. Ne pojavi se zato, ker ste dodali pot. Nikoli ne posredujte poizvedb .local javnemu razreševalniku: domena je rezervirana za lokalno uporabo multicast po RFC 6762, pošiljanje navzven pa povzroča počasne okvare in nepotrebno razkritje podatkov.

Preverite storitev, ne imena

Ime na seznamu iskanja dokazuje korak odkrivanja, ne da storitev odgovarja. Odprite tiskalno vrsto ali spletni vmesnik in izvedite resnično operacijo, nato jo po ponovni povezavi ponovite.

Odkrivanje agresivno shranjuje imena v predpomnilnik, zato je zastarel vnos lahko videti kot uspeh. Če se pojavi potrdilo ali zahteva za preverjanje pristnosti, je to naslednja plast in ločena težava. Zapišite, kateri mehanizem ste spremenili, razreševalnik ali odkrivanje, da naslednji osebi ne bo treba znova odpreti celotnega vprašanja.