VPN ичиндеги mDNS: .local аттары эмнеге чечилбейт

Кеңсеңиздин принтери столиңиздеги ар бир колдонмодо көрүнүп, VPNде жоголот, бирок сиз анын бар экенин билген дарекке ping жөнөтө аласыз. Туннелде эч нерсе бузулган эмес: аныктоо жана жетүү өзүнчө кызматтар, жана демейкиде алардын бир гана түрү маршрутталган туннелден өтөт. Төмөнкү текшерүүлөр маршрут кошууну баштаардан мурун аларды ажыратат. Эч качан байланыштан чыкпаган сурамды маршрут оңдой албайт.

Бүгүн эмне чечилерин жана эмне гана чечилгендей көрүнөрүн текшериңиз

Алгач эки суроону ажыратыңыз: хост атына unicast сурамы чечүүчүдөн сурайт, ал эми _ipp._tcp боюнча издөө жергиликтүү байланыштан сурайт. Linuxте avahi-browse -a multicast DNS эмнени көрө аларын көрсөтөт, resolvectl query name.local чечүүчү стектин бул ат менен эмне кыларын көрсөтөт. macOSте dns-sd -B _ipp._tcp алдын ала дарек талап кылбастан табылган кызматтарды тизмелейт.

Эгер дарек жооп берип, ат бербесе, маршруттоо иштейт, ал эми аныктоо иштебейт. .local атына avahi-browse орнотулбаса да nss-mdns аркылуу хосттун өзүндө жооп берүүгө болот, ошондуктан ошол атка ийгиликтүү 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 сурамдарын эч качан коомдук чечүүчүгө жөнөтпөңүз: домен RFC 6762 боюнча жергиликтүү multicast колдонууга арналган, ал эми аны сыртка жөнөтүү жай бузулууларды жана ашыкча маалыматтын ачылышын жаратат.

Кызматты текшериңиз, атты эмес

Издөө тизмесиндеги ат аныктоо кадамын далилдейт, кызматтын жооп берерин эмес. Басып чыгаруу кезегин же веб-интерфейсти ачып, чыныгы аракетти бүтүрүңүз, анан кайра туташкандан кийин кайталаңыз.

Аныктоо аттарды агрессивдүү кэштейт, ошондуктан эскирген жазуу ийгилик сыяктуу көрүнүшү мүмкүн. Сертификат же аутентификация сурамы пайда болсо, бул кийинки катмар жана өзүнчө маселе. Кайсы механизмди өзгөрткөнүңүздү, чечүүчүнүбү же аныктоонубу, жазып коюңуз, кийинки адам бүт суроону кайра ачпашы үчүн.