mDNS uvnitř VPN: proč se jména .local nepřekládají

Tiskárna ve vaší kanceláři se objevuje ve všech aplikacích u vašeho stolu a na VPN mizí, přestože dokážete pingnout adresu, o které víte, že ji má. V tunelu není nic rozbité: objevování a dostupnost jsou oddělené služby a ve výchozím nastavení překračuje směrovaný tunel jen jedna z nich. Následující kontroly je oddělí dřív, než začnete přidávat trasy. Trasa nemůže opravit dotaz, který nikdy neopustil link.

Zkontrolujte, co se dnes překládá a co jen vypadá přeložené

Nejprve oddělte dvě otázky: unicast dotaz na jméno hostitele se ptá překladače, zatímco prohledávání _ipp._tcp se ptá místního linku. V Linuxu avahi-browse -a ukazuje, co multicast DNS vidí, a resolvectl query name.local ukazuje, co s tím jménem dělá překladačový stack. V macOS dns-sd -B _ipp._tcp vypisuje objevené služby bez toho, aby nejprve potřeboval adresu.

Pokud adresa odpovídá a jméno ne, směrování funguje a objevování ne. Jméno .local lze také odpovědět přímo na hostiteli přes nss-mdns bez nainstalovaného avahi-browse, takže úspěšný getent nebo ping na toto jméno není důkaz, že objevování prošlo tunelem; výsledek prohledávání a výsledek překladače jsou různé důkazy. Aplikace si kešují to, co objevily, a proto se závada často objeví hodiny po připojení, ne při připojení. Ukončete a znovu otevřete aplikaci, pak zkontrolujte, zda kešovaná položka obsahuje jméno, nebo adresu, protože adresa funguje dlouho poté, co objevování skončilo.

Proč dotaz nikdy nepřekročí tunel

Multicast DNS posílá dotazy na 224.0.0.251, uvnitř bloku řízení místní sítě, na UDP port 5353. Routery adresy z tohoto bloku nepředávají, takže dotaz zůstává na lince, kam byl odeslán. Odesílatelé také nastavují IP TTL, případně limit skoků IPv6, na 255, aby příjemce mohl odmítnout paket, který už prošel routerem; tak protokol odhaluje podvrh mimo link, ne tak, že zůstává lokální. Lokálnost pochází z cílové adresy, ne z TTL jednoho skoku.

Záleží i na typu tunelu. Rozhraní ve stylu tun přenáší IP pakety a nic jiného, takže přes něj nepřežije žádná multicastová skupina. Most ve stylu tap rozšiřuje samotnou doménu vysílání, a proto některé staré návrhy mostovaly místo směrování a zdědily každý problém, který most přináší.

Výjimka pro důvěryhodnou LAN nic z toho nemění, protože rozhoduje, který provoz smí tunel použít, místo aby tunel učila předávat multicast. Paket stále nemá žádný sdílený segment, na kterém by byl slyšet.

Zvolte návrh pojmenování, který dokážete provozovat

Pro firemní zdroje je trvalou odpovědí směrované jméno hostitele, které obsluhuje překladač, jenž VPN protlačuje, s rozděleným DNS, aby interní jména šla na interní servery a všechno ostatní ne. Windows to vystavuje jako tabulku zásad překladu jmen, macOS používá omezené překladače pro jednotlivá rozhraní a většina klientů má ekvivalentní nastavení protlačení. Zařízení si zachovává své obvyklé jméno v interním DNS a objevování přestává být součástí cesty.

Proxy pro objevování nebo mDNS reflektor může tuto mezeru přemostit a je to skutečný návrh s vlastním hostitelem, vlastní expozicí a vlastními požadavky na klienty. Neobjeví se proto, že jste přidali trasu. Nikdy nepředávejte dotazy .local veřejnému překladači: doména je vyhrazena pro místní multicastové použití podle RFC 6762 a její odeslání ven způsobuje pomalé poruchy a zbytečné odhalování dat.

Ověřte službu, ne jméno

Jméno v seznamu prohledávání dokazuje krok objevení, ne že služba odpovídá. Otevřete tiskovou frontu nebo webové rozhraní a proveďte skutečnou operaci, pak ji po opětovném připojení zopakujte.

Objevování agresivně kešuje jména, takže zastaralá položka může vypadat jako úspěch. Pokud se objeví certifikát nebo výzva k ověření, je to další vrstva a samostatný problém. Zapište si, který mechanismus jste změnili, překladač, nebo objevování, aby příští člověk nemusel celou otázku znovu otevírat.