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 и изпращането му навън води до бавни откази и ненужно разкриване на данни.

Проверете услугата, не името

Име в списък за търсене доказва стъпката на откриване, а не че услугата отговаря. Отворете опашката за печат или уеб интерфейса и извършете реална операция, после я повторете след повторно свързване.

Откриването кешира имена агресивно, затова остарял запис може да изглежда като успех. Ако се появи сертификат или подкана за удостоверяване, това е следващият слой и отделен проблем. Запишете кой механизъм сте променили, резолвер или откриване, за да не преразглежда следващият човек целия въпрос.