mDNS vnútri VPN: prečo sa mená .local neprekladajú

Tlačiareň v kancelárii sa objaví v každej aplikácii na vašom stole a na VPN zmizne, hoci dokážete pingnúť adresu, o ktorej viete, že ju má. V tuneli nie je nič pokazené: objavovanie a dostupnosť sú samostatné služby a predvolene prekračuje smerovaný tunel len jedna z nich. Kontroly nižšie ich oddeľujú skôr, než začnete pridávať trasy. Trasa nedokáže opraviť dopyt, ktorý nikdy neopustil spojenie.

Skontrolujte, čo sa dnes prekladá a čo len vyzerá preložené

Najprv oddeľte dve otázky: unicast dopyt na názov hostiteľa sa pýta prekladača, kým hľadanie _ipp._tcp sa pýta miestneho spojenia. V Linuxe avahi-browse -a ukazuje, čo multicast DNS vidí, a resolvectl query name.local ukazuje, čo prekladačový zásobník s tým názvom robí. V macOS dns-sd -B _ipp._tcp vypisuje objavené služby bez toho, aby najprv potreboval adresu.

Ak adresa odpovedá a názov nie, smerovanie funguje a objavovanie nie. Názov .local možno odpovedať aj na samotnom hostiteľovi cez nss-mdns bez nainštalovaného avahi-browse, takže úspešný getent alebo ping na tento názov nie je dôkazom, že objavovanie prešlo tunelom; výsledok hľadania a výsledok prekladača sú rôzne dôkazy. Aplikácie si ukladajú do vyrovnávacej pamäte to, čo objavili, preto sa porucha často objaví hodiny po pripojení, nie pri pripojení. Ukončite a znova otvorte aplikáciu, potom skontrolujte, či záznam vo vyrovnávacej pamäti obsahuje názov alebo adresu, pretože adresa funguje ešte dlho po tom, čo sa objavovanie zastavilo.

Prečo dopyt nikdy neprekročí tunel

Multicast DNS posiela dopyty na 224.0.0.251, vnútri riadiaceho bloku miestnej siete, na UDP port 5353. Smerovače adresy z tohto bloku nepreposielajú, takže dopyt zostáva na spojení, kam bol odoslaný. Odosielatelia tiež nastavujú IP TTL, alebo limit skokov IPv6, na 255, aby príjemca mohol odmietnuť paket, ktorý už prešiel smerovačom; tak protokol odhaľuje falšovanie mimo spojenia, a nie tak zostáva lokálny. Lokálnosť pochádza z cieľovej adresy, nie z TTL jedného skoku.

Aj typ tunela je dôležitý. Rozhranie v štýle tun prenáša IP pakety a nič iné, takže cez neho neprejde žiadna multicastová skupina. Most v štýle tap rozširuje samotnú vysielaciu doménu, preto niektoré staré návrhy mostili namiesto smerovania a zdedili každý problém, ktorý most prináša.

Výnimka pre dôveryhodnú LAN nič z toho nemení, pretože rozhoduje, ktorá prevádzka smie tunel používať, namiesto toho, aby tunel učila preposielať multicast. Paket stále nemá žiadny spoločný segment, na ktorom by bol počuť.

Vyberte si návrh pomenovania, ktorý dokážete udržať

Pre firemné zdroje je trvalou odpoveďou smerovaný názov hostiteľa, ktorý obsluhuje prekladač, ktorý VPN pretláča, spolu s rozdeleným DNS, aby interné názvy išli na interné servery a všetko ostatné nie. Windows to vystavuje ako tabuľku zásad prekladu názvov, macOS používa obmedzené prekladače pre jednotlivé rozhrania a väčšina klientov má ekvivalentné nastavenie pretláčania. Zariadenie si zachováva svoj obvyklý názov v internom DNS a objavovanie prestáva byť súčasťou cesty.

Sprostredkovateľ objavovania alebo mDNS reflektor môže túto medzeru premostiť a je to skutočný návrh s vlastným hostiteľom, vlastnou expozíciou a vlastnými požiadavkami klienta. Neobjaví sa preto, že ste pridali trasu. Nikdy nepreposielajte dopyty .local verejnému prekladaču: doména je vyhradená na miestne multicastové použitie podľa RFC 6762 a jej odoslanie von spôsobuje pomalé poruchy a zbytočné odhaľovanie údajov.

Overte službu, nie názov

Názov v zozname hľadania dokazuje krok objavovania, nie to, že služba odpovedá. Otvorte tlačovú frontu alebo webové rozhranie a vykonajte skutočnú operáciu, potom ju po opätovnom pripojení zopakujte.

Objavovanie agresívne ukladá názvy do vyrovnávacej pamäte, takže zastaraný záznam môže vyzerať ako úspech. Ak sa objaví certifikát alebo výzva na overenie, je to ďalšia vrstva a samostatný problém. Zapíšte si, ktorý mechanizmus ste zmenili, prekladač alebo objavovanie, aby ďalší človek nemusel celú otázku otvárať znova.