mDNS inne i en VPN: hvorfor .local-navn ikke løses opp

Skriveren på kontoret dukker opp i alle programmer på skrivebordet og forsvinner på VPN-en, selv om du kan pinge adressen du vet den har. Ingenting i tunnelen er ødelagt: oppdagelse og tilgjengelighet er separate tjenester, og bare én av dem krysser en rutet tunnel som standard. Kontrollene nedenfor skiller dem før du begynner å legge til ruter. En rute kan ikke reparere en spørring som aldri forlot linken.

Sjekk hva som løses opp i dag, og hva som bare ser oppløst ut

Skill de to spørsmålene først: en unicast-spørring om et vertsnavn spør en resolver, mens et søk etter _ipp._tcp spør den lokale linken. På Linux viser avahi-browse -a hva multicast-DNS kan se, og resolvectl query name.local viser hva resolverstakken gjør med det navnet. På macOS viser dns-sd -B _ipp._tcp oppdagede tjenester uten å trenge en adresse først.

Hvis adressen svarer og navnet ikke, virker rutingen og oppdagelsen ikke. Et .local-navn kan også besvares på verten selv via nss-mdns uten at avahi-browse er installert, så en vellykket getent eller ping til det navnet er ikke bevis for at oppdagelsen krysset tunnelen; søkeresultatet og resolverresultatet er forskjellige bevis. Programmer cacher det de oppdaget, og derfor dukker feilen ofte opp timer etter tilkobling i stedet for ved tilkobling. Lukk og åpne programmet på nytt, og sjekk deretter om den cachede oppføringen inneholder et navn eller en adresse, for en adresse virker lenge etter at oppdagelsen stoppet.

Hvorfor spørringen aldri krysser tunnelen

Multicast DNS sender spørringer til 224.0.0.251, inne i kontrollblokken for det lokale nettet, på UDP-port 5353. Rutere videresender ikke adresser fra den blokken, så spørringen blir værende på linken den ble sendt til. Avsendere setter også IP TTL, eller IPv6-hopgrensen, til 255 slik at en mottaker kan avvise en pakke som allerede har krysset en ruter; det er slik protokollen oppdager spoofing utenfor linken, ikke slik den blir lokal. Lokalitet kommer fra måladdressen, ikke fra en TTL på én hop.

Tunneltypen har også noe å si. Et grensesnitt i tun-stil frakter IP-pakker og ingenting annet, så ingen multicast-gruppe overlever det. En bro i tap-stil utvider selve kringkastingsdomenet, og derfor broet noen eldre design i stedet for å rute, og arvet alle problemene en bro fører med seg.

Et unntak for klarert LAN endrer ingenting av dette, fordi det avgjør hvilken trafikk som kan bruke tunnelen i stedet for å lære tunnelen å videresende multicast. Pakken har fortsatt ikke noe felles segment å bli hørt på.

Velg et navnedesign du kan drifte

For bedriftens ressurser er det varige svaret et rutet vertsnavn som betjenes av resolveren VPN-en pusher, med delt DNS slik at interne navn går til interne servere og alt annet ikke. Windows viser det som en tabell for navneoppløsningspolicy, macOS bruker avgrensede resolvere per grensesnitt, og de fleste klienter har en tilsvarende push-innstilling. Enheten beholder sitt vanlige navn i intern DNS, og oppdagelse slutter å være en del av veien.

En oppdagelsesproxy eller en mDNS-reflektor kan bygge bro over gapet, og det er et ekte design med sin egen vert, sin egen eksponering og sine egne klientkrav. Det dukker ikke opp fordi du la til en rute. Videresend aldri .local-spørringer til en offentlig resolver: domenet er forbeholdt lokal multicast-bruk av RFC 6762, og å sende det utover gir langsomme feil og unødvendig datalekkasje.

Bekreft tjenesten, ikke navnet

Et navn i en søkeliste beviser oppdagelsestrinnet, ikke at tjenesten svarer. Åpne utskriftskøen eller nettgrensesnittet og fullfør en ekte operasjon, og gjenta den etter en gjentilkobling.

Oppdagelse cacher navn aggressivt, så en foreldet oppføring kan se ut som suksess. Hvis et sertifikat eller en autentiseringsforespørsel dukker opp, er det neste lag og et separat problem. Skriv ned hvilken mekanisme du endret, resolver eller oppdagelse, slik at neste person ikke må åpne hele spørsmålet på nytt.