VPN daxilində mDNS: .local adları niyə həll olunmur

Ofisinizdəki printer masanızdakı hər tətbiqdə görünür və VPN-də yox olur, hətta bildiyiniz ünvanı ping edə bilsəniz də. Tuneldə heç nə pozulmayıb: kəşf və əlçatanlıq ayrı xidmətlərdir və yalnız biri standart olaraq marşrutlaşdırılmış tuneldən keçir. Aşağıdakı yoxlamalar marşrut əlavə etməzdən əvvəl onları ayırır. Marşrut heç vaxt linkdən çıxmayan sorğunu düzəldə bilməz.

Bu gün nəyin həll olunduğunu və nəyin yalnız həll olunmuş göründüyünü yoxlayın

Əvvəlcə iki sualı ayırın: host adı üçün unicast sorğu resolvertən soruşur, _ipp._tcp üçün axtarış isə lokal linkdən. Linux-da avahi-browse -a multicast DNS-in nə görə bildiyini göstərir, resolvectl query name.local isə resolver yığınının həmin adla nə etdiyini göstərir. macOS-da dns-sd -B _ipp._tcp kəşf edilmiş xidmətləri əvvəlcə ünvana ehtiyac olmadan sadalayır.

Ünvan cavab verirsə və ad vermirsə, marşrutlaşdırma işləyir, kəşf işləmir. .local adı həm də avahi-browse quraşdırılmadan nss-mdns vasitəsilə hostun özündə cavablandırıla bilər, ona görə də həmin ada uğurlu getent və ya ping kəşfin tuneldən keçdiyinə sübut deyil; axtarış nəticəsi və resolver nəticəsi fərqli sübut parçalarıdır. Tətbiqlər kəşf etdiklərini keşləyir, buna görə nasazlıq tez-tez qoşulma zamanı deyil, qoşulmadan saatlar sonra görünür. Tətbiqi bağlayıb yenidən açın, sonra keşlənmiş girişin ad yoxsa ünvan saxladığını yoxlayın, çünki ünvan kəşf dayandıqdan çox sonra da işləyir.

Sorğu niyə heç vaxt tuneldən keçmir

Multicast DNS sorğuları 224.0.0.251 ünvanına, lokal şəbəkə nəzarət blokunun içərisinə, UDP portu 5353 ilə göndərir. Marşrutizatorlar həmin blokdan ünvanları yönləndirmir, ona görə sorğu göndərildiyi linkdə qalır. Göndərənlər həmçinin IP TTL-ni, yaxud IPv6 hop limitini 255-ə qoyur ki, qəbul edən artıq marşrutizatordan keçmiş paketi rədd edə bilsin; protokol linkdən kənar saxtakarlığı belə aşkarlayır, lokal qalması isə bu yolla deyil. Lokallıq təyinat ünvanından gəlir, bir hopluq TTL-dən deyil.

Tunel növü də vacibdir. tun tipli interfeys yalnız IP paketlərini daşıyır, ona görə heç bir multicast qrupu ondan keçərək yaşamır. tap tipli körpü yayım domenini özünü genişləndirir, buna görə bəzi köhnə dizaynlar marşrutlaşdırma yerinə körpü qurdu və körpünün gətirdiyi hər problemi miras aldı.

Etibarlı LAN istisnası bunların heç birini dəyişmir, çünki o, tunelin multicast yönləndirməsini öyrətmək yerinə hansı trafikin tuneldən istifadə edə biləcəyini müəyyən edir. Paketin hələ də eşidiləcəyi ortaq seqmenti yoxdur.

Dəstəkləyə biləcəyiniz adlandırma dizaynı seçin

Şirkət resursları üçün davamlı cavab VPN-in itələdiyi resolver tərəfindən xidmət olunan marşrutlaşdırılmış host adıdır, daxili adların daxili serverlərə getməsi və qalan hər şeyin getməməsi üçün split DNS ilə. Windows bunu ad həlli siyasəti cədvəli kimi təqdim edir, macOS interfeys başına məhdudlaşdırılmış resolverlər istifadə edir və əksər müştərilərdə ekvivalent itələmə parametri var. Cihaz daxili DNS-də adi adını saxlayır və kəşf yolun bir hissəsi olmaqdan çıxır.

Kəşf proksisi və ya mDNS reflektor bu boşluğu körpüləyə bilər və bu, öz hostu, öz məruz qalması və öz müştəri tələbləri olan real dizayndır. Yalnız marşrut əlavə etdiyiniz üçün görünmür. .local sorğularını heç vaxt ictimai resolverlərə yönləndirməyin: domen RFC 6762 ilə lokal multicast istifadəsi üçün qorunur və onu bayıra göndərmək yavaş nasazlıqlar və lazımsız məlumat açıqlaması yaradır.

Xidməti yoxlayın, adı deyil

Axtarış siyahısındakı ad kəşf addımını sübut edir, xidmətin cavab verdiyini deyil. Çap növbəsini və ya veb interfeysi açın və real əməliyyat yerinə yetirin, sonra yenidən qoşulduqdan sonra təkrarlayın.

Kəşf adları aqressiv keşləyir, ona görə köhnə giriş uğur kimi görünə bilər. Sertifikat və ya autentifikasiya tələbi görünürsə, bu növbəti təbəqədir və ayrı problemdir. Hansı mexanizmi dəyişdiyinizi, resolveri yoxsa kəşfi, yazın ki, növbəti şəxs bütün sualı yenidən müzakirə etməsin.