Яагаад resolv.conf таны VPN-ийн DNS-ийг харуулдаг ч хайлтууд түүнийг үл тоомсорлодог

Лог дотор буруу зүйл харагдахгүй: интерфэйс ажиллаж, шийдэгч VPN-ийн DNS серверийг мэдээлж, диск дээрх файл түүнийг жагсааж байна. Гэсэн хэдий ч дотоод хост нэр локал чиглүүлэгчээр шийдэгдсээр байна. Эдгээр гурван мэдэгдэл хоорондоо зөрчилдөхгүй, учир нь файл, холбоо бүрийн төлөв болон хайлтын зам нь санамсаргүйгээр ижил нэрийг хуваалцдаг өөр өөр объектууд юм. Дараах нь systemd-resolved бүхий хост дээр асуулга үнэндээ туулах замыг тайлбарлана.

resolv.conf нэртэй гурван объект

resolved бүхий хост дээр /etc/resolv.conf ихэвчлэн /run/systemd/resolve/stub-resolv.conf руу чиглэсэн симбол холбоос байдаг. Тэр зорилтот дотор локал stub сонсогчийн хаяг 127.0.0.53, мөн resolved-ийн тооцоолсон хайлтын домэйнууд байна. Энэ нь төлөвийн дүрс бөгөөд төлөв өөрөө биш.

Төлөв нь resolved-ийн холбоо бүрийн тохиргоонд амьдардаг, тиймээс resolvectl status файлтай зөрчилдөж болох ч зөв хэвээр байж чадна. Холбоо бүр өөрийн серверүүд болон чиглүүлэлтийн домэйнуудыг агуулж, асуулга ирэхэд stub тэр өгөгдөлд ханддаг. systemd-resolved-ийн гарын авлага үүсгэсэн файлууд болон холбоо бүрийн загварыг тайлбарладаг; дүрс ба төлөвийн ялгаа нь санахад үнэ цэнэтэй хэсэг юм. Симбол холбоосын зорилтыг өөрчлөх нь уламжлалт клиентүүд юу уншиж байгааг өөрчилдөг, шийдэгчийн мэддэг зүйлийг биш.

Гурав дахь объект /run/systemd/resolve/resolv.conf нь холбоо бүрийг нэг серверийн жагсаалт болгон хавтгайруулдаг. Тэр файл руу чиглэсэн програм асуулгуудыг шууд жагсаасан серверүүд рүү илгээж, stub-ыг алгасдаг тул холбоо бүрийн бодлого түүнд цаашид үйлчлэхгүй. Тиймээс нэг машин дээрх хоёр програм ижил нэрэнд өөрөөр хариулж болох бөгөөд аль нь ч эвдэрээгүй.

NSS-ээр дамжуулан нэг хайлтыг дага

glibc нэрэнд хэн хариулахыг шийдэхийн тулд /etc/nsswitch.conf-ыг уншдаг. resolve агуулсан hosts мөр асуултыг nss-resolve рүү чиглүүлж, тэр нь D-Bus-ээр resolved-ээс асууж, холбоо бүрийн хариуг авдаг. Зөвхөн files dns агуулсан мөр асуулгыг /etc/resolv.conf-ийн эзэмшиж буй хаяг руу илгээдэг.

Тэр нэг мөр браузер болон dig-ийн хоорондын ихэнх зөрүүг тайлбарладаг. dig resolv.conf-ыг шууд уншиж, NSS-д хэзээ ч хүрдэггүй тул програмын ашигладаг замыг биш, stub эсвэл дээд серверийг шалгадаг. getent hosts internal.example NSS-ээр дамждаг бөгөөд түүний хариуг dig-ийн хариутай харьцуулах нь эхний ашигтай хэмжилт юм.

Өөрийн шийдэгчийг дагуулсан эсвэл тогтмол төгсгөлийн цэг рүү HTTPS-ээр DNS ярьдаг програмууд хоёр замыг хоёуланг нь тойрдог. resolv.conf-д ч, resolved-ийн төлөвт ч тэднийг хязгаарлах зүйл байхгүй.

Файл хэнийх болохыг, хаашаа чиглэж байгааг шалга

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

stat -c '%N' /etc/resolv.conf
resolvectl status --no-pager
grep '^hosts' /etc/nsswitch.conf
ls -l /run/systemd/resolve/

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

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

Холбоосын эзэн дээр зас

VPN холболт өөрийн серверүүд болон домэйнуудыг өөрийн холбоос дээр бүртгэж, дараа нь салгах үед буцааж авах ёстой. NetworkManager-ийн resolved интеграц болон клиентийн өөрийн туслах хоёулаа ингэж ажилладаг; зөвхөн resolv.conf-ыг дахин бичдэг скрипт тийм биш.

Аль хэдийн байгаа холбоос дээр механизмыг ажиллах үеийн тохиргоо харуулдаг. resolvectl dns tun0 10.40.0.53 сервер хавсаргаж, resolvectl domain tun0 '~corp.example' чиглүүлэлтийн домэйн хавсаргана. Тилда бол ачаа үүрсэн тэмдэгт: тэр нь тухайн дагаврын асуулгыг энэ холбоосоор хязгаарлаж, бусад бүхнийг тайван орхидог бол түүнгүйгээр ижил утга нь хайлтын домэйн болж, хуваалт ууршина. Тэдгээр хаяг нь лабораторийн жишээ, байнгын тохиргоо биш. resolvectl query host.corp.example-оор баталгаажуулж, аль холбоос хариулсныг унш.

Бүртгэгдсэн серверт гэсэн ч зам хэрэгтэй. Асуулга зөв холбоосд хүрээд хугацаа нь дуусвал алдаа нь шийдэгчийн эзэмшилд биш, туннелээр хүрэх боломжид байна.

Ажиллаж буй төлөв хэрхэн харагдах вэ

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

Дараа нь салгаж, хоёр асуулгыг давт. Салгасны дараа домэйнуудаа бүртгэлтэй үлдээдэг клиент хэдэн цагийн дараа дотоод хайлтад бүтэлгүйтдэг машин үүсгэдэг, нээлттэй туннелгүй, тодорхой шалтгаангүйгээр.