Яагаад дотоод хост нэрс dig-д шийдэгдэж, харин curl-д VPN дээр бүтэлгүйтдэг вэ
dig хариулдаг ч curl нь хост нэрийг шийдэж чадахгүй гэж мэдээлдэг. Хоёр хайлтын гинжийг харьцуулж, дараа нь nsswitch, холболт тус бүрийн DNS эсвэл буруу хайлтын дагаврыг засаарай.
Таны зөөврийн компьютер VPN-д байна, dig service.internal.example нь 10.x хаягаар хариулж, curl нь Could not resolve host-ээр гарсаар байна. Туннель нь асуудал биш: dig-ийн асуулгыг гомдолгүй дамжуулсан. Ялгаа нь асуултыг хэн тавьдагт байна. dig нь таны нэрлэсэн нэг сервер рүү нэг асуулт илгээдэг бол curl нь үйлдлийн системийн хайлтын гинжин хэлхээгээр дамждаг, тэр гинжин хэлхээнд аль серверээс асуух тухай өөрийн дүрэм бий.
Нэг нэрэнд хоёр хайлт
dig бол өөрийн stub resolver юм. Энэ нь /etc/resolv.conf-ыг уншиж, нэрийн сервер сонгож, нэг A эсвэл AAAA асуулт илгээж, хариултыг хэвлэдэг. Энэ нь nsswitch-ийг бүрэн алгасаж, systemd-resolved эсвэл NetworkManager-ийн тэр файлаас гадуур хадгалдаг холболт тус бүрийн төлөвийн талаар юу ч мэдэхгүй, тиймээс dig-ийн хариулт зөв байж болох ч таны програмын харах зүйлийн талаар юу ч хэлэхгүй байж болно.
Програмууд getaddrinfo-г дуудаж, getaddrinfo нь илүү урт гинжин хэлхээгээр явдаг: nsswitch модулиудын дараалал, дараа нь нэрийг боловсруулах модуль, эцэст нь одоогийн холболтын тохиргооноос бүтээсэн resolver. systemd машин дээр асуулт 127.0.0.53 руу явж, systemd-resolved нь tun интерфейст холбогдсон чиглүүлэлтийн домэйнд үндэслэн холболт бүрд дээд сервер сонгодог.
Хоёр команд эдгээр давхаргыг таамаглалгүйгээр тусгаарладаг:
getent ahosts service.internal.example
resolvectl query service.internal.examplegetent нь curl-тэй ижил замыг ашигладаг тул ажиллаж буй dig-ийн хажууд getent алдаа гарвал алдааг пакетийн чиглүүлэлтэд биш, хайлтын бодлогод тодорхойлно. resolvectl query нь хариулт өгсөн интерфейс болон дээд серверийг мөн хэвлэдэг бөгөөд энэ нь шийдвэрийг туннелийн холболт эсвэл физик холболт хожсоныг харуулна.
Програм үнэхээр ашигладаг resolver-ийг уншина уу
/etc/resolv.conf нь ихэнх ажлын ширээн дээр үүсгэгддэг бөгөөд VPN клиент үүнтэй харилцах гурван аргатай: нэрийн серверийг урд нь тавих, файлыг дарж бичих, эсвэл серверүүдээ NetworkManager-т өгч, демонг дахин бичихийг зөвшөөрөх. Зөвхөн гурав дахь загвар нь холболт тус бүрийн DNS-ийг хадгалдаг, учир нь серверүүд нэг дэлхийн жагсаалт болж хавтгайрсанаас илүү интерфейст холбогдсон хэвээр үлддэг.
NetworkManager системд үр дүн /etc/NetworkManager/NetworkManager.conf дахь backend-ээс хамаарна:
[main]
dns=systemd-resolveddns=default тохиолдолд клиентийн серверүүд resolv.conf-д ялах дарааллаар нэгдэж, хувийн асуулт нийтийн resolver руу явж болно. Холболтыг ойлгодог backend-тэй, systemd-resolved эсвэл dnsmasq, туннелийн серверүүд туннельд хязгаарлагдаж, зөвхөн түүний чиглүүлэлтийн домэйнтой тохирох нэрс тийшээ явна. Энэ хязгаарлалт нь split DNS практикт илэрхийлдэг зүйл бөгөөд клиент үүнийг дэмждэг гэж мэдэгдэх үед хамгийн их дутагддаг хэсэг юм.
Ямар нэг зүйлийг өөрчлөхөөс өмнө төлөвийг уншина уу:
resolvectl status
resolvectl dns tun0Та tun интерфейсийг DNS сервер болон хувийн дагаварт зориулсан чиглүүлэлтийн домэйнтой жагсаасан, ~internal.example хэлбэрээр харахыг хүсч байна. Холболт дээр сервер байхгүй нь клиент юу ч илгээгээгүйг илтгэнэ. Домэнгүй сервер нь асуултууд бүгд тийшээ явах эсвэл нэг ч явахгүй гэсэн үг, клиентээс хамаарна, аль аль нь split DNS биш.
nsswitch хайлтыг хэт эрт дуусгадаг газар
Энгийн ажлын ширээний мөр иймэрхүү харагдана:
hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns myhostnamemdns4_minimal нь multicast DNS-ийг хариуцаж, .local-оор төгсдөг бүх нэрийг шаарддаг. api.infra.svc.cluster.local зэрэг Kubernetes үйлчилгээ мөн .local-оор төгсдөг. mDNS модуль NOTFOUND мэдэгдэх үед [NOTFOUND=return] үйлдэл нь dns модуль руу үргэлжлүүлэхийн оронд бүх хайлтыг дуусгадаг тул нэр хэзээ ч VPN resolver руу илгээгддэггүй. dig нь файлыг бүрэн тойрч гардаг, яг ийм учраас хоёр хэрэгсэл санал нийлдэггүй.
Энэ бол энэ асуудлын хамгийн хурц ялгаа бөгөөд таны VPN-ээс хуучин тохиргооны файл дахь нэг үгэн дээр тогтдог. Үйлдлийг [NOTFOUND=continue] болгож өөрчилбөл mDNS нь принтер болон орон нутгийн төхөөрөмжүүдэд хадгалагдаж, DNS нэрийг харж чадна. Мөрийг hosts: files dns-ээр солих нь бас ажилладаг бөгөөд бүдүүлэг: таны үнэхээр ашигладаг принтерийн .local шийдлийг хасдаг.
Яг нэг сүлжээнд амьдардаг нэрс
Хувийн бүсүүд яг нэг газарт эрх мэдэлтэй байдаг. ip-10-0-4-31.eu-west-1.compute.internal зэрэг AWS нэр нь тухайн бүсийн VPC resolver-оор хариулагдаж, зөвхөн таны VPN төгсгөлийн цэг нөөцтэй нэг бүсэд байх хугацаанд л хариулагдана. Франкфуртын төгсгөлийн цэгт холбогдож, Ирландын compute.internal нэрийг асуувал ямар ч орон нутгийн тохиргоо тус болохгүй: бичлэгийг хадгалж буй бүс тэндээс хүрэхгүй.
Хайлтын домэйнүүд толин тусгалыг үүсгэдэг. Нүцгэн service нь resolver тохиромжтой гэж үзсэн дагавраар нөхөгдөж, VPN холболттой үед орон нутгийн домэйн корпорацийнхоос давамгайлж болно. Таамаглалыг арилгахын тулд төгсгөлд нь цэгтэй асууна уу, getent ahosts service.internal.example., хэрэв энэ ажиллаж, богино нэр бүтэлгүйтвэл засвар нь туннель дээрх хайлтын домэйн, серверийн хаяг биш.
Удирдлагатай клиентүүд системийн resolver-ийн дээр гурав дахь давхаргыг нэмдэг. Windows VPN профайл өөрийн нэр шийдвэрлэх бодлого, програм тус бүрийн дүрэм, туннель унтарсан ч үйлчилдэг NRPT хүснэгтийг авч явж болно. Өөрийн DNS кэштэй програмууд, .NET болон Java орчинд түгээмэл, гинжин хэлхээг зассаны дараа ч хуучирсан алдааг удаан хадгалдаг. Apple клиентүүд split DNS-ийг DNS тохиргоон дахь тохирох домэйнүүдээр тохируулдаг, resolv.conf-оор биш, харин Chromium эсвэл Firefox аюулгүй DNS горимд нийтийн нэрсийн хувьд системийн resolver-ийг тойрч болно. Microsoft-ийн VPN нэр шийдвэрлэх лавлагаа нь энэ бодлогын давхаргын Windows талыг тайлбарладаг.
Аль давхаргыг засахаа шийдээрэй
Засваруудыг дараалан туршихын оронд шинж тэмдгээс давхарга руу явна уу:
| Symptom | What it means | Check first |
|---|---|---|
| dig answers, getent fails | lookup chain, not the packet path | nsswitch line and resolvectl status |
| Timeout rather than NXDOMAIN | private resolver unreachable through the tunnel | resolvectl dns tun0, route to that address |
| NXDOMAIN | an authority answered and does not know the name | zone owner, endpoint region |
| FQDN works, short name fails | search suffix mismatch | resolvectl domain on the tun link |
| getent works, app fails | app cache or its own resolver | restart the app, check secure DNS |
Хоёр мөр гол ачааллыг үүрдэг. Хугацаа хэтрэх нь хүртээмжийн асуудал: хувийн resolver туннелээр хариулдаггүй тул түүний хаяг руу чиглэсэн замыг болон холболт дээрх DNS сервер таны бодож байгаа эсэхийг шалгана уу. NXDOMAIN нь эрх мэдлийн асуудал: ямар нэг зүйл хариулсан бөгөөд нэрийг мэдэхгүй байна, энэ нь бүс, регион эсвэл асуултыг хэзээ ч авах ёсгүй байсан resolver руу заана.
Сүүлийн мөр нь хүмүүсийн алгасдаг мөр, учир нь хоёр тал нь амжилт мэт харагддаг. FQDN-ээс өөрөөр шийдэгддэг богино нэр нь дагаврын зөрүү бөгөөд туннелийг дахин холбох нь клиентийн илгээдэг дагаврыг өөрчлөхгүй.
Тохиргооны файлыг засахаас өмнө төлөвийг тэмдэглэж аваарай, ингэснээр засвар ямар нэг зүйл хийсэн эсэхийг хэлж чадна:
resolvectl status > before.txt
getent ahosts service.internal.example >> before.txtШалгалтуудыг энэ дарааллаар гүйцэтгэж, эхний бүтэлгүйтсэн дээр зогсоно уу. getent болон resolvectl query тохирсон байх ёстой; хэрэв getent бүтэлгүйтэж, dig хариулж байвал хайлтын гинжин хэлхээнд үлдэж, чиглүүлэлтэд хүрч болохгүй. resolvectl status нь tun интерфейс дээр DNS сервер болон чиглүүлэлтийн домэйн харуулах ёстой. nsswitch нь шалгаж буй дагаврын хувьд NOTFOUND-оор эрт буцаж болохгүй. Нэр нь таны төгсгөлийн цэг холбогдсон сүлжээнд эрх мэдэлтэй байх ёстой, төгсгөлд нь цэгтэй шалгасан. Програм өөрийн кэш эсвэл аюулгүй DNS-ийн дарж бичилтийг хадгаж болохгүй.
Зөвхөн эхний бүтэлгүйтсэн давхаргыг засаад, дараа нь ижил командуудыг дахин ажиллуулна уу. Нэг дор хоёр өөрчлөлт хийвэл аль нь чухал байсныг хэлж чадахгүй, дараагийн гэмтэл мөрдөн шалгалтыг тэгээс эхэлнэ.