Linux-ийн /etc/resolv.conf-ын төлөө өрсөлдөж буй хоёр үйлчилгээг зогсоох
Файлыг засахаасаа өмнө эзэмшигч нь хэн болохыг олж мэдээрэй. Өөрчлөгдөшгүйн туг зөрчилдөөнийг нууж, дахин холболт эсвэл DHCP шинэчлэлт гар аргын DNS засварыг дахин дахин хүчингүй болгодог.
DNS байнга өмнөх төлөв рүү буцаж, VPN-ийн дахин холболт таны засварыг хүчингүй болгож, эцэст нь багийн хэн нэгэн файлыг түгжихийг санал болгодог. Энэ дараалал нь шинж тэмдэг бөгөөд шийдэл биш: хоёр бүрэлдэхүүн хоёулаа /etc/resolv.conf-ыг эзэмшдэг гэж бодож, хамгийн сүүлд бичсэн нь ялдаг. Файлыг түгжих нь эзэмшлийн зөрчилдөөнийг шийдэхгүй, зөвхөн нууж, тэр үед таны үнэхээр хүссэн бүрэлдэхүүнийг эвддэг. Доорх дөрвөн шалгалтыг дарааллаар нь хийж, зохион байгуулалтыг файл дээр биш, түүнийг эзэмшдэг түвшинд зас.
Шалгалт 1: энэ нь симбол холбоос уу, хаашаа
Файлаас эхлээрэй, учир нь таны засаж буй зам файл биш байж магадгүй. Шийдэгчийн ажиллах лавлах руу чиглэсэн симбол холбоос нь клиент скриптийн дахин бичдэг энгийн файлаас огт өөрөөр ажилладаг:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
systemd-resolved-ийн stub зам руу чиглэсэн холбоос нь файлын агуулга үүсгэгддэг гэсэн үг бөгөөд гар аргын засвар дараагийн үйл явдалд дарж бичигдэнэ. nameserver мөртэй энгийн файлыг ихэвчлэн холболтын үед ажилладаг клиент эсвэл DHCP дэгээ бичдэг. Хоёулаа хууль ёсны; гол нь ямар нэгэн зүйл өөрчлөхөөс өмнө аль нь байгааг мэдэх явдал юм.
Шалгалт 2: аль демон ажиллаж байна
Юу суулгасныг биш, юу нь үнэхээр идэвхтэй байгааг олж мэдээрэй. Орчин үеийн дистрибьюцид хэд хэдэн шийдэгч байж болох бөгөөд loopback интерфейс дээр 53 портыг эзэлж байгаа нь хариулдаг:
systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'
Төлөвийн гаралт нь холбоос бүрийн DNS сервер, чиглүүлэлтийн домэйнуудыг нэрлэдэг бөгөөд энэ нь split DNS-д хэрэгтэй газрын зураг юм. Хэрэв дотоод нэрс дотоод сервер рүү, бусад бүх зүйл нийтийн сервер рүү явах ёстой бол энэ бодлого холбоос бүрийн домэйн дотор амьдардаг бөгөөд үүнийг файл дахь статик nameserver жагсаалт болгон хавтгайруулах нь энэ ялгааг чимээгүй алддаг.
NetworkManager-ийн өөрийн тохиргоо эдгээр backend-үүдийн алийг ашиглахаа шийддэг. Үндсэн тохиргооны файл дахь түүний dns= параметр нь дотоод шийдэгч, dnsmasq, systemd-resolved, none-ийн хооронд сонголт хийдэг бөгөөд дистрибьюц таны оронд сонгосон байж магадгүй. Энэ хост дээр “DNS-ийг засах” гэдэг нь юу гэсэн үг болохыг шийдэхээс өмнө тэр параметрийг уншаарай.
Шалгалт 3: VPN клиент юу бичихийг зөвшөөрдөг
Зөрчилдөөн ихэвчлэн энд амьдардаг. Шийдэгчийн файлыг шууд дахин бичдэг VPN клиент түүнийг мөн хадгалдаг аливаа үйлчилгээтэй тэмцэх бөгөөд хожигддог нь эхэлж ажилладаг. Сүүлийн үеийн OpenVPN хувилбарууд файлыг дахин бичихийн оронд DNS тохиргоог systemd-resolved-д шилжүүлж болох бөгөөд энэ нь таны хүсч буй хамтын ажиллагааны зан төлөв юм; хуучин скриптүүд, гараар бичсэн дэгээнүүд ихэвчлэн хуучирсан туслах хэрэгслийг дуудах эсвэл файлыг зүгээр л дарж бичдэг.
WireGuard-ийн байдал хэлбэрийн хувьд ижил: интерфейсийн тохиргоо өөрөө DNS-ийг удирддаггүй, эргэн тойрны хэрэгслүүд шийдэгчийн туслах эсвэл resolved интеграцаар удирддаг. Ийм хоёр туслах суулгасан бол хоёулаа холбогдох үед өөрийн дэлхийн үзэл бодлыг хэрэгжүүлэхийг оролдоно.
Таамаглахын оронд клиентийн up, down дэгээг уншаарай. /etc/openvpn/up.sh эсвэл түүнтэй адил лавлах дахь хэдэн мөр shell нь өөрөөр санамсаргүй мэт санагдах зан төлөвийг тайлбарлаж, клиентийг өрсөлдөх биш хамтран ажиллахад хүргэх газар нь мөн тэнд юм.
Шалгалт 4: эзэмшигчийн дээр зас, файл дээр биш
Эзэмшигчийг мэдсэний дараа DNS-ийг тухайн эзэмшигчийн дэмждэг интерфейсээр тохируул. systemd-resolved-ийн хувьд энэ нь статик файлын оронд холбоос бүрийн тохиргоо, чиглүүлэлтийн домэйн; NetworkManager-ийн хувьд холболтын профайлын DNS тохиргоо, сонгосон backend; resolvconf интеграцтай дистрибьюцийн хувьд тэр туслахыг дамжуулан бичих гэсэн үг.
Файлыг өөрчлөгдөшгүй болгох хэрэггүй. Өөрчлөгдөшгүйн шинж чанар нь хууль ёсны DHCP шинэчлэлт, VPN шинэчлэлтийг таны тэмцэж байсан зүйлсийн хамт зогсоож, системийг дараагийн багц шинэчлэлт эсвэл дахин холболт нь тохиргооноос хэн ч тайлбарлаж чадахгүй алдаа үүсгэдэг төлөвт үлдээдэг. Энэ нь эзэмшлийн зөрчилдөөнийг нуудаг бөгөөд энэ нь яг таны шийдэх гэж оролдсон зүйл юм.
Хоёр бүрэлдэхүүн үнэхээр хамт оршин тогтнох ёстой бол тэдэнд өөр ажил өг. Сүлжээний менежерт интерфейсийн түвшний тохиргоог эзэмшүүл, VPN клиентэд ижил интеграцаар холбоос бүрийн DNS, домэйныг нэмүүл, файлыг шууд бичдэг гурав дахь скриптийг устга. systemd-resolved-ийн баримт бичиг түүний дэмждэг горимууд болон тус бүр нь /etc/resolv.conf-д юу харуулдгийг тайлбарладаг. Хадгалах шаардлагатай бодлогын хэмжээнд тохирсон горимыг сонго. Хэрэв split DNS чухал бол холбоос бүрийн домэйн бүхий stub зохион байгуулалт үүнийг хадгалж, upstream серверүүдийг файл руу хуулдаг горим үүнийг чимээгүй хавтгайруулдаг.
Дахин холбогдсоны дараа шалга, засварын дараа биш
Таны өөрчлөлтийн дараа шууд зөв харагдах файл юу ч нотолохгүй, учир нь дараагийн үйл явдал хараахан болоогүй. Өмнө нь түүнийг эвддэг байсан дарааллыг өдөө: туннелийг буулгаад дахин өргө, DHCP түрээсийг шинэчил эсвэл интерфейсийг соль, дараа нь мөн тэдгээр утгыг дахин унш.
resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40
Дараа нь чухал ялгааг баталгаажуул: дотоод нэр дотоод серверээр шийдэгдэж, нийтийн нэр хэвээр ажиллаж байна. Бүгдийг дотоод сервер рүү илгээдэг тохиргоо хэн нэгэн туннелээр интернетэд гарахыг оролдох хүртэл сайн харагдана, бүгдийг нийтийн рүү илгээдэг тохиргоо дотоод нэрсийг алдагдуулдаг.
Байршуулалтын тэмдэглэлд эзэмшигч, backend, симбол холбоосын горимыг тэмдэглэ. Тэр нэг догол мөр нь ирээдүйн багц шинэчлэлтийг ослоос хяналтын зүйл болгож, дараагийн хүн chattr командаар мөн зөрчилдөөнийг дахин илрүүлэхээс сэргийлнэ.