mDNS wewnątrz VPN: dlaczego nazwy .local nie są rozwiązywane

Drukarka w biurze pojawia się w każdej aplikacji na biurku i znika w VPN, choć możesz pingować adres, o którym wiesz, że ma. W tunelu nic nie jest zepsute: wykrywanie i osiągalność to osobne usługi, a domyślnie tylko jedna z nich przekracza routowany tunel. Poniższe kontrole rozdzielają je, zanim zaczniesz dodawać trasy. Trasa nie naprawi zapytania, które nigdy nie opuściło łącza.

Sprawdź, co jest dziś rozwiązywane, a co tylko wygląda na rozwiązane

Najpierw rozdziel dwa pytania: zapytanie unicast o nazwę hosta pyta resolver, natomiast wyszukiwanie _ipp._tcp pyta lokalne łącze. W Linuksie avahi-browse -a pokazuje, co może zobaczyć multicast DNS, a resolvectl query name.local pokazuje, co stos resolvera robi z tą nazwą. W macOS dns-sd -B _ipp._tcp wymienia wykryte usługi bez potrzeby wcześniejszego adresu.

Jeśli adres odpowiada, a nazwa nie, routing działa, a wykrywanie nie. Nazwę .local można też odpowiedzieć na samym hoście przez nss-mdns bez zainstalowanego avahi-browse, więc udany getent lub ping do tej nazwy nie jest dowodem, że wykrywanie przekroczyło tunel; wynik wyszukiwania i wynik resolvera to różne dowody. Aplikacje buforują to, co wykryły, dlatego awaria często pojawia się godziny po połączeniu, a nie przy połączeniu. Zamknij i otwórz ponownie aplikację, a następnie sprawdź, czy buforowany wpis zawiera nazwę czy adres, ponieważ adres działa jeszcze długo po zatrzymaniu wykrywania.

Dlaczego zapytanie nigdy nie przekracza tunelu

Multicast DNS wysyła zapytania na 224.0.0.251, wewnątrz bloku sterowania siecią lokalną, na port UDP 5353. Routery nie przekazują adresów z tego bloku, więc zapytanie zostaje na łączu, na które je wysłano. Nadawcy ustawiają też IP TTL, czyli limit skoków IPv6, na 255, aby odbiorca mógł odrzucić pakiet, który już przekroczył router; tak protokół wykrywa fałszowanie poza łączem, a nie tak pozostaje lokalny. Lokalność pochodzi z adresu docelowego, a nie z TTL jednego skoku.

Typ tunelu też ma znaczenie. Interfejs w stylu tun przenosi pakiety IP i nic więcej, więc żadna grupa multicast przez niego nie przechodzi. Most w stylu tap rozszerza samą domenę rozgłaszania, dlatego niektóre stare projekty mostkowały zamiast routować i odziedziczyły każdy problem, jaki niesie most.

Wyjątek dla zaufanej sieci LAN niczego z tego nie zmienia, bo decyduje, który ruch może korzystać z tunelu, zamiast uczyć tunel przekazywania multicastu. Pakiet nadal nie ma wspólnego segmentu, na którym byłby słyszalny.

Wybierz projekt nazewnictwa, który możesz utrzymać

Dla zasobów firmowych trwałą odpowiedzią jest routowana nazwa hosta obsługiwana przez resolver, który VPN wypycha, wraz z podzielonym DNS, aby nazwy wewnętrzne trafiały do wewnętrznych serwerów, a wszystko inne nie. Windows udostępnia to jako tabelę zasad rozwiązywania nazw, macOS używa resolverów z zakresem na interfejs, a większość klientów ma równoważne ustawienie wypychania. Urządzenie zachowuje swoją zwykłą nazwę w wewnętrznym DNS, a wykrywanie przestaje być częścią ścieżki.

Proxy wykrywania lub reflektor mDNS może wypełnić tę lukę i jest to prawdziwy projekt z własnym hostem, własną ekspozycją i własnymi wymaganiami klienta. Nie pojawia się dlatego, że dodałeś trasę. Nigdy nie przekazuj zapytań .local do publicznego resolvera: domena jest zarezerwowana do lokalnego użytku multicast przez RFC 6762, a wysyłanie jej na zewnątrz daje powolne awarie i niepotrzebne ujawnianie danych.

Weryfikuj usługę, nie nazwę

Nazwa na liście wyszukiwania dowodzi kroku wykrywania, a nie tego, że usługa odpowiada. Otwórz kolejkę wydruku lub interfejs webowy i wykonaj prawdziwą operację, a potem powtórz ją po ponownym połączeniu.

Wykrywanie agresywnie buforuje nazwy, więc nieaktualny wpis może wyglądać jak sukces. Jeśli pojawi się certyfikat lub prośba o uwierzytelnienie, to następna warstwa i osobny problem. Zapisz, który mechanizm zmieniłeś, resolver czy wykrywanie, aby następna osoba nie musiała otwierać całego pytania od nowa.