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 пайдалануға арналған, ал оны сыртқа жіберу баяу ақаулар мен қажетсіз деректердің ашылуын тудырады.

Қызметті тексеріңіз, атауды емес

Шолу тізіміндегі атау анықтау қадамын дәлелдейді, қызметтің жауап беретінін емес. Басып шығару кезегін немесе веб-интерфейсті ашып, нақты әрекетті орындаңыз, содан кейін қайта қосылғаннан кейін оны қайталаңыз.

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