Хувийн DNS нэрс VPN клиент дээр яагаад бүтэлгүйтдэг, хаана шалгах вэ

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

Аль ч профайлыг засахын өмнө клиент нэртэй юу хийдгийг шалгана. Linux дээр resolvectl query files.corp.example хариултыг аль холболт, аль шийдэгч үүсгэснийг харуулна. Windows дээр Resolve-DnsName files.corp.example хариулсан сервер болон буцаасан хаягийг харуулна.

Ямар нэг зүйлийг өөрчлөхийн өмнө хариултыг уншаарай

Нэр хэдэн миллисекундын дотор NXDOMAIN болж буцаж ирвэл хүсэлт таны бүсэд хэзээ ч хүрээгүй бөгөөд оронд нь ямар нэг нийтийн эсвэл зочид буудлын шийдэгч хариулсан. Урт завсарлагын дараа буцаж ирвэл замд ямар нэг зүйл UDP 53 портыг хаяж, клиент эцэст нь нөөц хувилбар руу шилжсэн. Зөв хаягаар хариулсан ч холболт гацсаар байвал хайлт хэвийн, асуудал чинь чиглүүлэлт эсвэл үйлчилгээ өөртөө байна.

Гурав хуваах нь нэг цагийн таамаглалыг хэмнэнэ. Энэ нь VPN-д огт хүрэх шаардлагатай эсэхийг ч хэлнэ: зөв хувийн хаяг руу шийдэгддэг нэр шийдэгчийн замыг аль хэдийн баталсан тул үлдсэн ажил өгөгдлийн замд байна.

Шийдэгчийг туннелийн дотроос тараана

Клиентүүд хоёр бүлэгт хуваагдана. Нэгд нь сервер холболт тогтоох үед шийдэгч өгч болно; нөгөө нь тохиргоог ямар ч гарц зайнаас өөрчилж чадахгүй локал файлд хадгална.

OpenVPN эхний бүлэгт байна. Сервер дээр push "dhcp-option DNS 10.8.0.53" болон push "dhcp-option DOMAIN corp.example" удирдлагын сувгаар дамждаг, гэхдээ клиентийн тохиргоонд pull асаалттай хэвээр байвал л. Гараар зассан, pull-filter ignore "dhcp-option" агуулсан клиент тэднийг хэзээ ч харахгүй бөгөөд тэр ганц мөр «сервер үүнийг түлхэж байна, гэтэл миний зөөврийн компьютер зөвшөөрөхгүй байна» гэсэн гайхалтай олон тохиолдлыг тайлбарлана.

WireGuard хоёр дахь бүлэгт байна, учир нь протоколд сонголтын хэлэлцээр огт байхгүй. Шийдэгч болон хайлтын домэйн клиентийн өөрийн [Interface] блокт DNS = 10.8.0.53, corp.example хэлбэрээр орно. wg-quick үүнийг resolvconf эсвэл systemd-resolved-оор хэрэгжүүлдэг, Windows дээр албан ёсны клиент зөвхөн туннель босоо байх үед оршдог NRPT дүрмийг суулгадаг: Get-DnsClientNrptPolicy тэдгээрийг жагсаадаг нь клиент таны файлыг хэзээ нэгэн цагт хэрэглэсэн эсэхийг харах хурдан арга болдог.

IPsec/IKEv2 голд байна. strongSwan-ы attr залгуур сангаас авсан DNS серверийг буцааж чаддаг, Windows клиент үүнийг ихэвчлэн хүлээн авдаг, гэхдээ өөрийн нэрийн серверийг тогтоосон профайл гарцын санал болгосон бүхнээс давуу болно. Linux клиент дээр тэнцэх гарын алхам нь resolvectl dns wg0 10.8.0.53, дараа нь resolvectl domain wg0 '~corp.example'; хоёулаа интерфэйсийн хамт алга болдог нь туннельд хязгаарлагдсан тохиргоонд яг хэрэгтэй зүйл юм.

Сонголт бүрийг залгихын оронд дагаварыг хязгаарла

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

Дотогш зөвхөн хувийн дагаврыг илгээ. systemd-resolved дээр ~-ээр эхэлсэн домэйн зөвхөн чиглүүлэлтийн зориулалттай тул ~corp.example нь тэр дагаврын доорх хүсэлтүүд тэр холболтын сервер рүү явж, бусад бүхэн физик сүлжээг үргэлжлүүлэн ашиглана гэсэн үг. Windows үүнийг нэрийн орон зайд хязгаарласан NRPT дүрмээр, macOS нь /etc/resolver/ доорх нэмэлт шийдэгч файлаар хийдэг.

Multicast нэрс өөрийн хариултыг хүртэх ёстой. .local нэрс нь зохион бүтээлээрээ link-local (RFC 6762) бөгөөд цэгээс цэг рүү tun интерфэйс тэр multicast бүлгийг зөөдөггүй тул нэмэлт нийтийн шийдэгч тэднийг нийтлэхгүй, дотоод unicast шийдэгчээс тэдний талаар асуувал NXDOMAIN буцаана. avahi зэрэг тусгагч тусгал горимд хоёр сегментийг холбож чаддаг, гэхдээ энэ нь ямар ч клиент шаардаж чадахгүй серверийн талын шийдвэр. Принтер эсвэл NAS нэрээр хүрэх боломжтой байх ёстой бол оронд нь бүсэд нь A бичлэг өг.

Хариулт буцаж чадахыг нотол

Хүрэх боломжгүй хаяг руу заасан зөв хариулт нь замыг шалгах хүртэл яг шийдэгчийн асуудал шиг харагдана. Цөмөөс хариулт хаашаа явахыг асуу: ip route get 10.20.5.20 интерфэйс болон илүү ашигтай нь, ашиглах эх хаягийг нэрлэнэ.

Шийдэгчийн хаягийг өөрөө ажигла. DNS = 10.8.0.53-тай хажууд AllowedIPs = 10.20.0.0/16 байгаа клиент хүсэлтээ физик NIC-ээр гадагш илгээдэг бөгөөд тэнд тэд чимээгүй үхдэг, учир нь шийдэгч туннелийн шаарддаг ямар ч префикс дотор байхгүй. Энэ зөрүү нь энэ бүх салбарын хамгийн түгээмэл нэг шалтгаант алдаа бөгөөд DNS тохиргоог зөвшөөрөгдсөн префикстэй мөр мөрөөр харьцуулахгүй л бол үл үзэгдэнэ.

Давхцсан мужууд эсрэг алдаа үүсгэдэг. Хариулт зөв, зам байгаа бөгөөд буруу хост руу зааж байна, учир нь гэрт байгаа 192.168.0.0/24 туннелийн мөн тэр муж руу хийх замаас илүү тодорхой. Нэг талыг дахин дугаарла эсвэл илүү нарийн зам түлхэ, дараа нь үйлчилгээний хостын галт хана болон буцах замыг баталгаажуул; strongSwan-ы дамжуулалт тухай тэмдэглэл тэр замын sysctl талыг хамарна.

Гэрчилгээ нь хүмүүсийн DNS-д тохож буруутгадаг тусдаа таних шалгалт юм. Хөтөч шийдэлтийн алдааны оронд нэрийн зөрүү мэдээлбэл, хайлт аль хэдийн ажилласан бөгөөд засах зүйл нь гэрчилгээн дэх SAN юм. HTTPS-ийг нэрээр шалга, хэзээ ч нүцгэн IP-ээр биш.

Гарцаас биш, клиентээс дахин шалга

Хэрэглэгчийн гомдолдож буй апп дотор шалга, учир нь командын мөрний хайлт хөтөч мөн замаар явж байгааг нотлохгүй. Chrome-ы аюулгүй DNS болон Firefox-ын network.trr.mode системийн шийдэгчийг бүрэн тойрч чадна, тэгж үед хувийн нэр нь бүтэлгүйтэх эсвэл нийтийн шийдэгч рүү алдагдана. resolvectl query-г гараар ажиллуулсан dig @10.8.0.53 files.corp.example-тай харьцуулбал аль нь болсныг хэлнэ.

Дараа нь зассан гэж хэлэхийн өмнө холболтыг тасалж, дахин холбо. Интерфэйсэд гараар тавьсан тохиргоо интерфэйсийн хамт алга болдог бөгөөд зөвхөн мартагдсан локал өөрчлөлтөөс болж зөв харагдсан профайл дараагийн ачаалалтад бүтэлгүйтнэ.

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