mDNS усередині VPN: чому імена .local не розв’язуються

Принтер у вашому офісі з’являється в кожній програмі на столі й зникає у VPN, хоча ви можете пінгувати адресу, яку, як ви знаєте, він має. У тунелі нічого не зламано: виявлення й доступність — різні служби, і за замовчуванням лише одна з них перетинає маршрутизований тунель. Перевірки нижче розділяють їх, перш ніж ви почнете додавати маршрути. Маршрут не може виправити запит, який так і не покинув канал.

Перевірте, що розв’язується сьогодні, а що лише виглядає розв’язаним

Спочатку розділіть два питання: unicast-запит для імені хоста питає розв’язувач, тоді як пошук _ipp._tcp питає локальний канал. У Linux avahi-browse -a показує, що може бачити multicast DNS, а resolvectl query name.local показує, що стек розв’язувача робить із цим ім’ям. У macOS dns-sd -B _ipp._tcp перелічує виявлені служби, не потребуючи спочатку адреси.

Якщо адреса відповідає, а ім’я ні, маршрутизація працює, а виявлення ні. Ім’я .local можна також розв’язати на самому хості через nss-mdns без встановленого avahi-browse, тому успішний getent або ping до цього імені не доводить, що виявлення перетнуло тунель; результат пошуку й результат розв’язувача — різні докази. Програми кешують те, що виявили, тому збій часто з’являється через години після підключення, а не під час підключення. Закрийте й знову відкрийте програму, потім перевірте, чи кешований запис містить ім’я чи адресу, бо адреса продовжує працювати ще довго після того, як виявлення зупинилося.

Чому запит ніколи не перетинає тунель

Multicast DNS надсилає запити на 224.0.0.251, усередині блоку керування локальною мережею, на UDP-порт 5353. Маршрутизатори не пересилають адреси з цього блоку, тож запит залишається в каналі, куди його надіслали. Відправники також встановлюють IP TTL або межу переходів IPv6 у 255, щоб отримувач міг відхилити пакет, який уже пройшов маршрутизатор; так протокол виявляє підробку за межами каналу, а не так він залишається локальним. Локальність походить від адреси призначення, а не від TTL в один перехід.

Тип тунелю теж важливий. Інтерфейс у стилі tun передає IP-пакети й нічого більше, тому жодна multicast-група через нього не проходить. Міст у стилі tap розширює сам домен широкомовлення, тому деякі старі проєкти мостили замість маршрутизації й успадкували всі проблеми, які приносить міст.

Виняток для довіреної LAN нічого з цього не змінює, бо він вирішує, який трафік може використовувати тунель, а не вчить тунель пересилати multicast. Пакет досі не має спільного сегмента, на якому його можна почути.

Оберіть дизайн імен, який зможете підтримувати

Для ресурсів компанії сталий варіант — маршрутизоване ім’я хоста, яке обслуговує розв’язувач, що його просуває VPN, разом із розділеним DNS, щоб внутрішні імена йшли на внутрішні сервери, а все інше — ні. Windows подає це як таблицю політики розв’язання імен, macOS використовує обмежені розв’язувачі для кожного інтерфейсу, і більшість клієнтів мають еквівалентне налаштування просування. Пристрій зберігає своє звичайне ім’я у внутрішньому DNS, і виявлення перестає бути частиною шляху.

Проксі виявлення або mDNS-відбивач може подолати цю прогалину, і це реальний проєкт із власним хостом, власним впливом і власними вимогами до клієнтів. Він не з’являється тому, що ви додали маршрут. Ніколи не пересилайте запити .local публічному розв’язувачу: домен зарезервовано для локального multicast-використання згідно з RFC 6762, і надсилання його назовні дає повільні збої та непотрібне розкриття даних.

Перевіряйте службу, а не ім’я

Ім’я в списку пошуку доводить крок виявлення, а не те, що служба відповідає. Відкрийте чергу друку або веб-інтерфейс і виконайте реальну операцію, потім повторіть її після повторного підключення.

Виявлення агресивно кешує імена, тому застарілий запис може виглядати як успіх. Якщо з’являється сертифікат або запит автентифікації, це наступний рівень і окрема проблема. Запишіть, який механізм ви змінили, розв’язувач чи виявлення, щоб наступній людині не довелося знову відкривати все питання.