mDNS inde i en VPN: hvorfor .local-navne ikke slås op

Din kontorskriver dukker op i alle programmer ved dit skrivebord og forsvinder på VPN'et, selv om du kan ping'e den adresse, du ved den har. Intet i tunnelen er i stykker: opdagelse og tilgængelighed er to forskellige tjenester, og kun én af dem krydser en routed tunnel som standard. Kontrollerne nedenfor skiller dem ad, før du begynder at tilføje ruter. En rute kan ikke reparere en forespørgsel, der aldrig forlod linket.

Tjek hvad der slås op i dag, og hvad der kun ser opløst ud

Skil de to spørgsmål ad først: en unicast-forespørgsel på et værtsnavn spørger en resolver, mens en søgning efter _ipp._tcp spørger det lokale link. På Linux viser avahi-browse -a, hvad multicast-DNS kan se, og resolvectl query name.local viser, hvad resolver-stakken gør med det navn. På macOS viser dns-sd -B _ipp._tcp fundne tjenester uden først at have brug for en adresse.

Hvis adressen svarer og navnet ikke, virker routing, og opdagelse gør ikke. Et .local-navn kan også besvares på selve værten via nss-mdns uden at avahi-browse er installeret, så et vellykket getent eller ping til det navn er ikke bevis for, at opdagelsen krydsede tunnelen; søgeresultatet og resolver-resultatet er forskellige beviser. Programmer cacher det, de har opdaget, og derfor dukker fejlen ofte op timer efter forbindelsen i stedet for ved forbindelsen. Luk og åbn programmet igen, og tjek derefter, om den cachede post indeholder et navn eller en adresse, for en adresse virker længe efter, at opdagelsen stoppede.

Hvorfor forespørgslen aldrig krydser tunnelen

Multicast DNS sender forespørgsler til 224.0.0.251, inde i kontrolblokken for det lokale netværk, på UDP-port 5353. Routere videresender ikke adresser fra den blok, så forespørgslen bliver på det link, den blev sendt til. Afsendere sætter også IP TTL, eller IPv6-hopgrænsen, til 255, så en modtager kan afvise en pakke, der allerede har krydset en router; det er sådan protokollen opdager spoofing uden for linket, ikke sådan den bliver lokal. Lokalitet kommer fra destinationsadressen, ikke fra en TTL på ét hop.

Tunneltypen betyder også noget. En grænseflade af tun-typen bærer IP-pakker og intet andet, så ingen multicast-gruppe overlever den. En bro af tap-typen udvider selve broadcast-domænet, og derfor broede nogle ældre designs i stedet for at route og arvede alle de problemer, en bro bringer.

En undtagelse for betroede LAN ændrer intet af dette, fordi den afgør, hvilken trafik der må bruge tunnelen, i stedet for at lære tunnelen at videresende multicast. Pakken har stadig ikke noget fælles segment at blive hørt på.

Vælg et navnedesign, du kan understøtte

For virksomhedens ressourcer er det holdbare svar et routed værtsnavn, der betjenes af den resolver, VPN'en skubber ud, med opdelt DNS, så interne navne går til interne servere og alt andet ikke. Windows viser det som en navneopløsningspolitik-tabel, macOS bruger afgrænsede resolvere per grænseflade, og de fleste klienter har en tilsvarende skubbeindstilling. Enheden beholder sit normale navn i intern DNS, og opdagelse holder op med at være en del af vejen.

En opdagelsesproxy eller en mDNS-reflektor kan bygge bro over kløften, og det er et rigtigt design med sin egen vært, sin egen eksponering og sine egne klientkrav. Det dukker ikke op, fordi du tilføjede en rute. Videresend aldrig .local-forespørgsler til en offentlig resolver: domænet er forbeholdt lokal multicast-brug af RFC 6762, og at sende det udefter giver langsomme fejl og unødig datalækage.

Bekræft tjenesten, ikke navnet

Et navn på en søgeliste beviser opdagelsestrinet, ikke at tjenesten svarer. Åbn udskriftskøen eller webgrænsefladen, og udfør en rigtig handling, og gentag den efter en genopkobling.

Opdagelse cacher navne aggressivt, så en forældet post kan se ud som succes. Hvis der vises et certifikat eller en godkendelsesprompt, er det næste lag og et separat problem. Skriv ned, hvilken mekanisme du ændrede, resolver eller opdagelse, så den næste person ikke skal tage hele spørgsmålet op igen.