mDNS унутар VPN-а: зашто се .local имена не разрешавају

Штампач у вашој канцеларији појављује се у свакој апликацији на вашем столу и нестаје на VPN-у, иако можете да пингујете адресу за коју знате да је има. Ништа у тунелу није покварено: откривање и доступност су одвојене услуге, и подразумевано само једна од њих прелази рутирани тунел. Провере испод их раздвајају пре него што почнете да додајете руте. Рута не може да поправи захтев који никада није напустио везу.

Проверите шта се данас разрешава и шта само изгледа решено

Прво раздвојите два питања: unicast захтев за име домаћина пита resolver, док претрага за _ipp._tcp пита локалну везу. На Linux-у avahi-browse -a показује шта multicast DNS може да види, а resolvectl query name.local показује шта resolver стек ради са тим именом. На macOS-у dns-sd -B _ipp._tcp наводи откривене услуге без потребе за адресом унапред.

Ако адреса одговара, а име не, рутирање ради, а откривање не. Име .local може се одговорити и на самом домаћину преко nss-mdns без инсталираног avahi-browse, па успешан getent или ping на то име није доказ да је откривање прешло тунел; резултат претраге и резултат resolver-а су различити докази. Апликације кеширају оно што су откриле, зато се квар често појављује сатима после повезивања, а не при повезивању. Затворите и поново отворите апликацију, затим проверите да ли кеширани унос садржи име или адресу, јер адреса наставља да ради дуго након што је откривање стало.

Зашто захтев никада не прелази тунел

Multicast DNS шаље захтеве на 224.0.0.251, унутар контролног блока локалне мреже, на UDP порт 5353. Рутери не прослеђују адресе из тог блока, па захтев остаје на вези на коју је послат. Пошиљаоци такође постављају IP TTL, односно ограничење скокова IPv6, на 255 како би прималац могао да одбије пакет који је већ прешао рутер; тако протокол открива лажирање изван везе, а не тако што остаје локалан. Локалност долази од одредишне адресе, а не од TTL-а једног скока.

Тип тунела је такође важан. Интерфејс у tun стилу преноси IP пакете и ништа друго, па ниједна multicast група не преживљава кроз њега. Мост у tap стилу проширује сам домен емитовања, зато су неки стари дизајни мостовали уместо да рутирају и наследили сваки проблем који мост доноси.

Изузетак за поуздан LAN не мења ништа од овога, јер одлучује који саобраћај сме да користи тунел уместо да учи тунел да прослеђује multicast. Пакет и даље нема заједнички сегмент на коме би се чуо.

Изаберите дизајн именовања који можете да одржавате

За ресурсе компаније, трајан одговор је рутирано име домаћина које служи resolver који VPN гура, уз подељени DNS тако да унутрашња имена иду на унутрашње сервере, а све остало не. Windows то излаже као табелу политике разрешавања имена, macOS користи ограничене resolver-е по интерфејсу, а већина клијената има еквивалентну поставку гурања. Уређај задржава своје уобичајено име у унутрашњем DNS-у, а откривање престаје да буде део пута.

Прокси за откривање или mDNS рефлектор може да премости ову празнину и то је стваран дизајн са сопственим домаћином, сопственом изложеношћу и сопственим захтевима клијената. Не појављује се зато што сте додали руту. Никада не прослеђујте .local захтеве јавном resolver-у: домен је резервисан за локалну multicast употребу према RFC 6762, а његово слање напоље производи спора оштећења и непотребно откривање података.

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

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

Откривање агресивно кешира имена, па застарео унос може изгледати као успех. Ако се појави сертификат или захтев за аутентификацију, то је следећи слој и одвојен проблем. Запишите који механизам сте променили, resolver или откривање, да следећа особа не мора поново да отвара цело питање.