mDNS ene de VPN: kial .local-nomoj ne solviĝas

La printilo de via oficejo aperas en ĉiu aplikaĵo ĉe via labortablo kaj malaperas en la VPN, kvankam vi povas pingi la adreson, kiun ĝi laŭ vi havas. Nenio en la tunelo estas difektita: malkovro kaj atingeblo estas apartaj servoj, kaj nur unu el ili transiras enkursigitan tunelon defaŭlte. La subaj kontroloj apartigas ilin antaŭ ol vi komencos aldoni vojojn. Vojo ne povas ripari demandon, kiu neniam lasis la ligon.

Kontrolu, kio solviĝas hodiaŭ, kaj kio nur ŝajnas solvita

Unue apartigu la du demandojn: unicast-demando pri gastiga nomo demandas solvilon, dum serĉo de _ipp._tcp demandas la lokan ligon. En Linux, avahi-browse -a montras, kion multicast-DNS povas vidi, kaj resolvectl query name.local montras, kion la solvila stako faras kun tiu nomo. En macOS, dns-sd -B _ipp._tcp listigas malkovritajn servojn sen bezoni unue adreson.

Se la adreso respondas kaj la nomo ne, enkursigado funkcias kaj malkovro ne. Nomo .local ankaŭ povas esti respondata sur la gastiganto mem per nss-mdns sen ke avahi-browse estu instalita, do sukcesa getent aŭ ping al tiu nomo ne estas pruvo, ke malkovro transiris la tunelon; la serĉrezulto kaj la solvila rezulto estas malsamaj pruvoj. Aplikaĵoj kaŝmemorigas tion, kion ili malkovris, tial la fiasko ofte aperas horojn post konekto anstataŭ ĉe konekto. Fermu kaj remalfermu la aplikaĵon, poste kontrolu, ĉu la kaŝmemora ero enhavas nomon aŭ adreson, ĉar adreso daŭre funkcias longe post kiam malkovro ĉesis.

Kial la demando neniam transiras la tunelon

Multicast-DNS sendas demandojn al 224.0.0.251, ene de la stirbloko de la loka reto, sur UDP-pordo 5353. Enkursigiloj ne plusendas adresojn el tiu bloko, do la demando restas sur la ligo, al kiu ĝi estis sendita. Sendintoj ankaŭ agordas la IP-TTL, aŭ la IPv6-salton, al 255, por ke ricevanto povu malakcepti paketon, kiu jam transiris enkursigilon; tiel la protokolo detektas ekster-ligan falsadon, ne tiel ĝi restas loka. Lokeco venas de la celadreso, ne de TTL de unu salto.

Ankaŭ la tunela tipo gravas. Fasado de stilo tun portas IP-paketojn kaj nenion alian, do neniu multelsenda grupo postvivas ĝin. Ponto de stilo tap etendigas la dissendan domajnon mem, tial kelkaj malnovaj dezajnoj pontis anstataŭ enkursigi kaj heredis ĉiun problemon, kiun ponto alportas.

Escepto por fidinda LAN ŝanĝas nenion el tio, ĉar ĝi decidas, kiu trafiko rajtas uzi la tunelon, anstataŭ instrui la tunelon plusendi multelsendon. La paketo ankoraŭ ne havas komunan segmenton, sur kiu ĝi estu aŭdata.

Elektu nomadan dezajnon, kiun vi povas subteni

Por entreprenaj rimedoj la daŭra respondo estas enkursigita gastiga nomo servata de la solvilo, kiun la VPN puŝas, kun dividita DNS, por ke internaj nomoj iru al internaj serviloj kaj ĉio alia ne. Windows elmetas tion kiel tabelon de nomrezolva politiko, macOS uzas limigitajn solvilojn por fasado, kaj la plej multaj klientoj havas ekvivalentan puŝan agordon. La aparato konservas sian normalan nomon en la interna DNS, kaj malkovro ĉesas esti parto de la vojo.

Malkovra prokuro aŭ mDNS-reflektilo povas ponti la breĉon, kaj tio estas reala dezajno kun propra gastiganto, propra elmeto kaj propraj klientaj postuloj. Ĝi ne aperas ĉar vi aldonis vojon. Neniam plusendu .local demandojn al publika solvilo: la domajno estas rezervita por loka multelsenda uzo de RFC 6762, kaj sendi ĝin eksteren produktas malrapidajn fiaskojn kaj senbezonan datumkonigon.

Kontrolu la servon, ne la nomon

Nomo en serĉlisto pruvas la malkovran paŝon, ne ke la servo respondas. Malfermu la printvicon aŭ la retan interfacon kaj plenumu realan operacion, poste ripetu ĝin post rekonekto.

Malkovro kaŝmemorigas nomojn agreseme, do malnova ero povas aspekti kiel sukceso. Se aperas atestilo aŭ aŭtentiga peto, tio estas la sekva tavolo kaj aparta problemo. Notu, kiun mekanismon vi ŝanĝis, solvilon aŭ malkovron, por ke la sekva persono ne remalfermu la tutan demandon.