VPN-ийн DNS ажиллаж байгаа ч .local нэрс шийдэгдэхгүй байна: тэдгээрийг хэн шийддэг вэ?

Ижил VPN дээрх хоёр машин, ижил хостны нэр, тэдгээрийн зөвхөн нэг нь үүнийг шийддэг: ялгаа нь ихэвчлэн туннельд биш, харин аль шийдэгч хариулсан явдал юм. Linux ширээний компьютер дээр тэр нэр нэр үйлчилгээний шилжүүлэгчээр, systemd-resolved-ийн stub-аар эсвэл програм өөрөө авчирсан шийдэгчээр дамжиж болох бөгөөд тэдгээр нь тус бүр ижил дагаварт өөрийн дүрмийг хэрэглэдэг. Дүрмүүд яг дагавар дээр салдаг, учир нь .local төвийг сахисан шошго биш юм. Ямар нэг зүйлийн ажиллах дарааллыг өөрчлөхөөс өмнө бүтэлгүйтэж буй программ үнэндээ аль замаар явдагийг тодорхойлоорой.

Хоёр шийдэгч, хоёр өөр хариулт

Уламжлалт glibc хайлт nsswitch.conf-ийн hosts: мөрөөр явж, нэг нь хариулах хүртэл модуль бүрээс ээлжлэн асуудаг. Stub сонсогчийн замаар systemd-resolved-той ярьдаг клиент оронд нь нэг процессоос асуудаг бөгөөд тэр процесс холбоос бүрийн бодлого болон өөрийн онцгой тохиолдлуудыг хэрэглэдэг. Өөрийн шийдэгчийг авчирсан эсвэл үүнийг хийдэг номын санг холбосон програм хоёуланг нь тойрч болно. Ингээд нэг хостны нэр нэг машин дээр гурван эзэнтэй байж болох бөгөөд тэдгээрийн зөвхөн нэг нь VPN юу гэсэн үг болохыг мэддэг.

Ямар нэг зүйлийг өөрчлөхөөс өмнө эзнийг тодорхойлоорой, учир нь засвар нь гурвын хувьд өөр өөр байна. Нэг ширээний компьютер дээрх хөтөч ба командын мөрийн хэрэгсэл хуулийн хувьд санал нийлэхгүй байж болох бөгөөд тэр санал зөрөлдөөн нь сэжүүр бөгөөд алдаа биш юм. Хэрэв хөтөч нэрийг шийдэж, хэрэгсэл шийдэхгүй бол та шийдэгчийн замд алдаа засаж байна, VPN-ийн маршрут дээр биш. Маршрутыг тусад нь баталгаажуулж, маршрутжуулалтын гэмтлийг нэр үйлчилгээний гэмтэл гэж андуурахгүй байх болно. Хоёулаа санал нийлж байвал алдаа нь хостноос дээгүүр байна, энд байгаа шийдэгчийн тохиргоо өөр нэг засвар хийх үнэ цэнэгүй юм.

Аль команд үнэндээ таны шийдэгчээс асуусан бэ

Зөвхөн унших хоёр команд холбогдох асуултад хариулдаг бөгөөд тэдгээрийг харьцуулах нь тохиргоог уншихаас илүү хурдан асуудлыг локалчилдаг. Жинхэнэ дотоод нэрийг ашиглаж, гаралтыг хувийн байлгаарай, учир нь дотоод бичлэгүүд дотоод хэвээр үлддэг. Хоёуланг нь бүтэлгүйтэж буй программ ажиллаж буй ижил сессэд ажиллуулаарай:

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

Эхнийх нь тохируулсан модулиудаар асуудаг бөгөөд ердийн программ үүнийг мэдэрдэг. Хоёр дахь нь systemd-resolved-ээс шууд асууж, хариулсан холбоос, протокол, серверийг мэдээлдэг. Серверээс хаягаар асуух нь серверт бичлэг байгааг л нотолно, учир нь програм хэзээ нэгэн цагт асуусан эсэхийг энэ нь юу ч хэлэхгүй. VPN-ийг зөөж буй холбоос болон түүний мэдэгдэж буй домэйнуудыг уншаад, тэр жагсаалтыг бүтэлгүйтэж буй нэрийн дагавартай харьцуулаарай.

Яагаад .local таны unicast бүсийг алгасах вэ

systemd-resolved-ийн лавлагаа дээр .local-аар төгсдөг олон шошгот нэрс mDNS идэвхтэй үед ердийн unicast DNS-ийн оронд ихэвчлэн multicast DNS руу явдаг гэж заасан. RFC 6762 тэр нэрийн орон зайг link-local multicast-д зориулж тусгаарладаг тул корпорацийн бүс тэр дагаварт хэзээ ч асуудаггүй зөв бичлэгтэй байж болно. Туннель шийдэгчийг төгс маршрутжуулж чадвал ч уралдаанд ялагдаж болно. Кэшээс амжилттай ping нь дөнгөж болсон хайлтын талаар юу ч хэлэхгүй.

Баримтжуулсан үл хамаарах зүйл байгаа бөгөөд энэ нь эдгээр тохиолдлын ихэнхийг шийддэг: холбоос тэр дагаврыг хайлтын домэйн эсвэл маршрутжуулалтын домэйн гэж зарлавал демон үүнийг unicast зам дээр үлдээж, multicast-ийн онцгой тохиолдлыг алгасдаг. Энэ нь холбоос бүрийн бодлого бөгөөд дэлхийн давуу эрх биш юм. Ижил VPN сервертэй хоёр машин сүлжээний нэг профайл домэйныг зарлаж, нөгөө нь зарлахгүй үед өөрөөр ажиллаж болох тул санаж байгаа профайл биш, идэвхтэй профайлыг уншаарай.

Нарийн үл хамаарах зүйл дэлхийн дахин эрэмбэлэлтийг ялна

Нэрийг өөрчилж чадахгүй байгаа одоо байгаа бүсийн хувьд шийдэгч болон VPN-ийн эзэд тэр домэйныг зөөж буй холболт дээр зарлаарай. Тэр нэг дагаварт зориулсан маршрутжуулалтын домэйны бичлэг болон төлөвлөсөн серверийн хаяг нь нэрлэсэн эзэнтэй жижиг өөрчлөлт бөгөөд гар аргаар засварласан файлд биш, холбоостойгоо амьдардаг.

Энэ нь тасарсны дараа ч хадгалагдана, учир нь холбоос буцаж ирэхэд холбоосын бодлого дахин хэрэглэгддэг. Хамтын nsswitch.conf-г засварлах нь уруу татагч, илүү үнэтэй хувилбар юм, учир нь энэ нь машин дээрх нэр бүрийн хайлтын зан төлөвийг, локал илрүүлэлтийг оролцуулан өөрчилдөг. Multicast демоныг идэвхгүй болгох нь мөн адил биш: энэ нь локал зан төлөвийг арилгаж, ямар ч шийдэгчид корпорацийн бүсийг заахгүй. Хэрэв үйлчилгээ өвлөгдөөгүй, шинэ бол түүнийг танай байгууллага хянадаг дэд домэйнд байрлуулж, өрсөлдөөнийг бүрэн алгас. Нэр нь firmware-д тогтоосон эсвэл шошгонд хэвлэгдсэн бол нарийн үл хамаарах зүйлийг сонго, харин клиентийг хянаж байгаа бол шинэ дэд домэйн сонго.

Өөрчлөлтийн дараа юу нотлох вэ

Засварыг туршихын тулд суулгасан хэрэгслээр биш, програмын өөрийн хайлтаар нотлоод, түүний оронд хариулж чадах кэшийг хоослоорой. Дараа нь шийдэгчийн зам болон хариулт өгсөн холбоосыг баталгаажуулна. Эцэст нь локал илрүүлэлт өөрчлөлтийн өмнөх шигээ ажиллаж байгаа эсэхийг шалгаарай, учир нь харагдахаа болих принтер бол хүмүүсийн хамгийн сүүлд анзаардаг хэсэг юм. Эдгээр гурван команд нэр, зам, TLS таних тэмдгийг яг энэ дарааллаар шалгадаг:

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

Зөв хаяг буруу гэрчилгээтэй бол хатуу клиентийг мөн бүтэлгүйтүүлдэг тул шийдэл ажилласны дараа программ хүлээж буй нэрийг шалгаарай. Үйлчилгээ зөвхөн оффисын хүрээнээс гадна VPN хаягаас холболт хүлээж авдаг эсэхийг баталгаажуулаарай. Домэйны хүрээ, сервер, эзнийг холболтын баримт бичигт бичээрэй. Эс бөгөөс энэ гэмтэлтэй тулгарсан дараагийн хүн дөнгөж зайлсхийсэн тэр дэлхийн засвар руу хандана.