VPN-ийн DNS бүх хайлтыг авав: NetworkManager дахь dns-priority-г засаарай

Оффисын VPN-д холбогдоход гэнэт бүх нэрийн хайлт корпорацийн resolver руу явна. Нийтийн нэрс хэвээр шийдэгддэг тул локал принтерийн нэр бүтэлгүйтэх эсвэл split-horizon бичлэг оффисын хаягийг буцаатал ямар нэгэн зүйл эвдэрсэн мэт харагдахгүй. Зарим Fedora тохиргоонд эсрэгээрээ тохиолддог: нийлүүлэгчийн resolver нь туннель боссны дараа ч хариу үргэлжлүүлдэг. Хоёулаа нэг асуулт — энэ хүсэлтийг аль resolver эзэмшиж байна — бөгөөд NetworkManager системд хариулт нь холболт бүрийн DNS шинж чанарт амьдардаг.

Хоёр холболт, нэг ялсан resolver

Холболт бүр DNS тэргүүлэх чиглэлийг зарладаг. Энгийн холболтууд анхдангаараа 50, VPN холболтууд 0 байх бөгөөд бага утга ялдаг. Яг энэ анхдагч утга нь VPN холболт шаардсан домэн бүрийн хувьд утаслаг холболтыг чимээгүйхэн давж гардгийн шалтгаан: хэн ч сонгоогүй байхад тэг тавьдыг ялдаг.

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

Тэргүүлэх чиглэл дарааллыг, хайлтын жагсаалт эзэмшилтийг шийднэ

nmcli -f connection.id,ipv4.dns,ipv4.dns-search,ipv4.dns-priority con show "Corp VPN"
resolvectl status
readlink -f /etc/resolv.conf

Хайлтын жагсаалт бол эзэмшлийн мэдэгдэл юм. corp.example мэтийн нүцгэн домэйн нь хайлтын дагавар ба маршрутын домэйн болдог. Зөвхөн маршрутлалтын хэлбэр ~corp.example нь тухайн дагаварын доорх хайлтыг домэйныг богино нэрсэд нэмэхгүйгээр энэ холболт руу илгээдэг. Тэр тильда нь «энэ серверээс асуу» ба «энэ серверээс асуугаад миний бичсэнийг гүйцээ» хоёрын ялгаа юм.

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

Дараа нь давуу эрхийг тодорхой болгож, холболтыг дахин идэвхжүүлээрэй:

nmcli con modify "Corp VPN" ipv4.dns-priority -100
nmcli con modify "Corp VPN" ipv6.dns-priority -100
nmcli con modify "Corp VPN" ipv4.dns-search "~corp.example,corp.example"
nmcli con up "Corp VPN"

Сөрөг тэргүүлэх чиглэл нь «энэ холболтыг илүүд үз» гэж хэлэх баримтжуулсан арга бөгөөд хоёр хаягийн гэр бүлийг хоёуланг нь тогтоох нь IPv6 холболттой хост дээр зан төлөвийг жигд байлгадаг. Холболтыг дахин идэвхжүүлэхгүйгээр шинж чанарыг өөрчлөх нь одоо ажиллаж байгаа зүйлээс юу ч өөрчлөхгүй, иймд дараалал нь тодорхой up-ээр төгсдөг.

Хуваалтыг systemd-resolved бариулаарай

Анхдагч dnsmasq залгаас хүсэлтүүдийг нэг локал resolver руу цутгадаг тул холбоос бүрийн тусгаарлалт бүдүүлэг хэвээр үлддэг. systemd-resolved хуваалтыг холбоос бүрээр илрүүлдэг бөгөөд resolvectl query хариулсан холбоосыг нэрлэдэг.

systemctl enable --now systemd-resolved
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart systemd-resolved NetworkManager
resolvectl query build.corp.example

Үүний дараа корпорацийн холбоос corp.example-г үүрч, нийтийн resolver үлдсэнийг үйлчилнэ. Хүсэлт буруу холбоос дээр очиход тушаал түүнд хариулсан холбоосыг нэрлэдэг бөгөөд үүнийг мэдэх нь зөвхөн хаягийг мэдэхээс дээр.

DNS загварыг туннелийн төрөлд тохируулаарай

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

Дараа нь туннелиас гадуур DNS-ийг хаадаг kill switch байна. Нэрс туннелийн бүсүүдэд шийдэгдэж, бусад бүх газарт бүтэлгүйтдэг боловч холболт бүрэн эрүүл байна. Ажиллах боломжтой хариултууд нь LAN resolver-т өгөх тодорхой зөвшөөрөл эсвэл зөвхөн корпорацийн бүсийг дамжуулдаг локал кэш бөгөөд аль аль нь туннелийн гэмтэл биш, эзэнтэй үл хамаарах зүйл юм.

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

Холбоос бүрээр шалгаж, дахин холбогдсоны дараа дахин шалгаарай

Нэг дотоод, нэг нийтийн нэр асуугаад хүсэлт үнэхээр хаашаа явж байгааг хараарай. Алдагдал шалгах хуудас аль resolver хариулсныг хэлдэг, систем аль холбоосыг сонгосныг биш, иймд саяхан тохируулсан дарааллын талаар юу ч хэлдэггүй.

Салгаж, дахин холбогдсоны дараа хоёр хүсэлтийг дахин ажиллуулаарай. Холболт идэвхжихэд тэргүүлэх чиглэл дахин хэрэгжинэ, хуучин симболын холбоос хэн ч санахгүй шинэчлэлийг даван туулж чадна. Төгсгөлд нь бичих ёстой зүйл бол аль resolver аль дагаварыг эзэмшиж байгаа, дээр нь маргааш ч хүчинтэй шалгалт юм.