mDNS inne i ein VPN: kvifor .local-namn ikkje blir løyste

Skrivaren på kontoret dukkar opp i alle program på skrivebordet og forsvinn på VPN-en, sjølv om du kan pinga adressa du veit han har. Ingenting i tunnelen er øydelagt: oppdaging og tilgjenge er separate tenester, og berre éi av dei kryssar ein ruta tunnel som standard. Kontrollane nedanfor skil dei før du byrjar å leggja til ruter. Ei rute kan ikkje reparera ei spørjing som aldri forlét lenkja.

Sjekk kva som blir løyst i dag, og kva som berre ser løyst ut

Skil dei to spørsmåla først: ei unicast-spørjing om eit vertsnamn spør ein resolver, medan eit søk etter _ipp._tcp spør den lokale lenkja. På Linux viser avahi-browse -a kva multicast-DNS kan sjå, og resolvectl query name.local viser kva resolverstakken gjer med det namnet. På macOS viser dns-sd -B _ipp._tcp oppdaga tenester utan å trengja ei adresse først.

Viss adressa svarar og namnet ikkje, verkar rutinga og oppdaginga ikkje. Eit .local-namn kan også svarast på verten sjølv via nss-mdns utan at avahi-browse er installert, så ein vellukka getent eller ping til det namnet er ikkje bevis for at oppdaginga kryssa tunnelen; søkjeresultatet og resolverresultatet er ulike bevis. Program cachar det dei oppdaga, og difor dukkar feilen ofte opp timar etter tilkopling i staden for ved tilkopling. Lat att og opne programmet på nytt, og sjekk deretter om den cacha oppføringa inneheld eit namn eller ei adresse, for ei adresse verkar lenge etter at oppdaginga stoppa.

Kvifor spørjinga aldri kryssar tunnelen

Multicast DNS sender spørjingar til 224.0.0.251, inne i kontrollblokka for det lokale nettet, på UDP-port 5353. Rutarar videresender ikkje adresser frå den blokka, så spørjinga blir verande på lenkja ho vart send til. Avsendarar set også IP TTL, eller IPv6-hoppgrensas, til 255 slik at ein mottakar kan avvisa ein pakke som allereie har kryssa ein rutar; det er slik protokollen oppdagar spoofing utanfor lenkja, ikkje slik han blir lokal. Lokalitet kjem frå måladdressa, ikkje frå ein TTL på éin hopp.

Tunneltypen har også noko å seia. Eit grensesnitt i tun-stil fraktar IP-pakkar og ingenting anna, så ingen multicast-gruppe overlever det. Ei bru i tap-stil utvidar sjølve kringkastingsdomenet, og difor brua nokre eldre design i staden for å ruta, og arva alle problema ei bru fører med seg.

Eit unntak for klarert LAN endrar ingenting av dette, fordi det avgjer kva trafikk som kan bruka tunnelen i staden for å læra tunnelen å videresenda multicast. Pakken har framleis ikkje noko felles segment å bli høyrd på.

Vel eit namnedesign du kan halda ved like

For bedriftsressursar er det varige svaret eit ruta vertsnamn som blir tent av resolvaren VPN-en pushar, med delt DNS slik at interne namn går til interne tenarar og alt anna ikkje. Windows viser det som ein tabell for namneløysingspolicy, macOS brukar avgrensa resolverar per grensesnitt, og dei fleste klientar har ei tilsvarande push-innstilling. Eininga held på det vanlege namnet sitt i intern DNS, og oppdaging sluttar å vera ein del av vegen.

Ein oppdagingsproxy eller ein mDNS-reflektor kan byggja bru over gapet, og det er eit ekte design med sin eigen vert, si eiga eksponering og sine eigne klientkrav. Det dukkar ikkje opp fordi du la til ei rute. Videresend aldri .local-spørjingar til ein offentleg resolver: domenet er reservert for lokal multicast-bruk av RFC 6762, og å senda det utover gir trege feil og unødig datalekkasje.

Stadfest tenesta, ikkje namnet

Eit namn i ei søkjeliste bevisar oppdagingstrinnet, ikkje at tenesta svarar. Opne utskriftskøen eller nettgrensesnittet og fullfør ein ekte operasjon, og gjenta han etter ei ny tilkopling.

Oppdaging cachar namn aggressivt, så ei forelda oppføring kan sjå ut som suksess. Viss eit sertifikat eller ei autentiseringsførespurnad dukkar opp, er det neste lag og eit separat problem. Skriv ned kva mekanisme du endra, resolver eller oppdaging, slik at neste person ikkje må opna heile spørsmålet på nytt.