mDNS inuti ett VPN: varför .local-namn inte löses upp

Skrivaren på kontoret dyker upp i alla program på skrivbordet och försvinner på VPN:et, trots att du kan pinga adressen du vet att den har. Inget i tunneln är trasigt: upptäckt och nåbarhet är separata tjänster, och bara en av dem korsar en routad tunnel som standard. Kontrollerna nedan skiljer dem åt innan du börjar lägga till rutter. En rutt kan inte reparera en fråga som aldrig lämnade länken.

Kontrollera vad som löses upp i dag, och vad som bara ser upplöst ut

Skilj först de två frågorna: en unicast-fråga om ett värdnamn frågar en resolver, medan en sökning efter _ipp._tcp frågar den lokala länken. På Linux visar avahi-browse -a vad multicast-DNS kan se, och resolvectl query name.local visar vad resolverstacken gör med det namnet. På macOS listar dns-sd -B _ipp._tcp upptäckta tjänster utan att först behöva en adress.

Om adressen svarar och namnet inte, fungerar routingen och upptäckten inte. Ett .local-namn kan också besvaras på värden själv via nss-mdns utan att avahi-browse är installerat, så en lyckad getent eller ping till det namnet är inte bevis för att upptäckten korsade tunneln; sökresultatet och resolverresultatet är olika bevis. Program cachar det de upptäckte, och därför dyker felet ofta upp timmar efter anslutning i stället för vid anslutning. Stäng och öppna programmet igen och kontrollera sedan om den cachade posten innehåller ett namn eller en adress, eftersom en adress fortsätter att fungera länge efter att upptäckten stoppade.

Varför frågan aldrig korsar tunneln

Multicast DNS skickar frågor till 224.0.0.251, inne i kontrollblocket för det lokala nätet, på UDP-port 5353. Routrar vidarebefordrar inte adresser från det blocket, så frågan stannar på länken den skickades till. Avsändare sätter också IP TTL, eller IPv6-hopgränsen, till 255 så att en mottagare kan avvisa ett paket som redan korsat en router; det är så protokollet upptäcker spoofing utanför länken, inte så det förblir lokalt. Lokalitet kommer från destinationsadressen, inte från en TTL på ett hopp.

Tunneltypen spelar också roll. Ett gränssnitt i tun-stil transporterar IP-paket och inget annat, så ingen multicast-grupp överlever det. En bro i tap-stil utökar själva broadcastdomänen, och därför bryggade vissa äldre designer i stället för att routa, och ärvde alla problem som en bro för med sig.

Ett undantag för betrott LAN ändrar inget av detta, eftersom det avgör vilken trafik som får använda tunneln i stället för att lära tunneln att vidarebefordra multicast. Paketet har fortfarande inget delat segment att höras på.

Välj en namndesign du kan underhålla

För företagets resurser är det hållbara svaret ett routat värdnamn som betjänas av resolvern VPN:et skjuter ut, med delad DNS så att interna namn går till interna servrar och allt annat inte. Windows exponerar det som en tabell för namnupplösningspolicy, macOS använder avgränsade resolvers per gränssnitt, och de flesta klienter har en motsvarande push-inställning. Enheten behåller sitt vanliga namn i intern DNS, och upptäckt slutar vara en del av vägen.

En upptäcktsproxy eller en mDNS-reflektor kan överbrygga gapet, och det är en riktig design med egen värd, egen exponering och egna klientkrav. Det dyker inte upp för att du la till en rutt. Vidarebefordra aldrig .local-frågor till en offentlig resolver: domänen är reserverad för lokal multicast-användning av RFC 6762, och att skicka den utåt ger långsamma fel och onödig dataexponering.

Verifiera tjänsten, inte namnet

Ett namn i en söklista bevisar upptäcktssteget, inte att tjänsten svarar. Öppna utskriftskön eller webbgränssnittet och utför en riktig åtgärd, och upprepa den efter en återanslutning.

Upptäckt cachar namn aggressivt, så en inaktuell post kan se ut som en framgång. Om ett certifikat eller en autentiseringsfråga dyker upp är det nästa lager och ett separat problem. Skriv ned vilken mekanism du ändrade, resolver eller upptäckt, så att nästa person inte behöver öppna hela frågan igen.