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, і адпраўка яго вонкі дае павольныя збоі і непатрэбнае раскрыццё даных.

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

Імя ў спісе пошуку даказвае этап выяўлення, а не тое, што служба адказвае. Адкрыйце чаргу друку або вэб-інтэрфейс і выканайце рэальную аперацыю, затым паўтарыце яе пасля перападключэння.

Выяўленне агрэсіўна кэшуе імёны, таму састарэлы запіс можа выглядаць як поспех. Калі з’яўляецца запыт на сертыфікат або аўтэнтыфікацыю, гэта наступны ўзровень і асобная праблема. Запішыце, які механізм вы змянілі, рэзольвер або выяўленне, каб наступны чалавек не пераглядаў усё пытанне зноў.