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 хэрэглэлд зориулагдсан бөгөөд гадагш илгээх нь удаан алдаа, шаардлагагүй өгөгдөл илчлэлт үүсгэдэг.

Нэрийг биш, үйлчилгээг шалгаарай

Хайлтын жагсаалт дахь нэр нь илрүүлэлтийн алхмыг нотолдог, үйлчилгээ хариулдаг гэдгийг биш. Хэвлэх дараалал эсвэл вэб интерфейсийг нээж бодит үйлдлийг дуусгаад, дахин холбогдсоны дараа давтаарай.

Илрүүлэлт нэрсийг түрэмгий кэшлэдэг тул хуучирсан бичлэг амжилт мэт харагдаж болно. Гэрчилгээ эсвэл баталгаажуулалтын хүсэлт гарч ирвэл энэ нь дараагийн давхарга бөгөөд тусдаа асуудал юм. Ямар механизмыг өөрчилснөө, шийдэгч эсвэл илрүүлэлт гэдгийг бичиж үлдээгээрэй, дараагийн хүн бүх асуултыг дахин нээх шаардлагагүй болно.