Linux'ning /etc/resolv.conf uchun kurashayotgan ikki xizmatini to'xtating

DNS doim avvalgi holatiga qaytadi, VPN qayta ulanishi tuzatishingizni bekor qiladi va oxir-oqibat jamoada kimdir faylni qulflashni taklif qiladi. Bu ketma-ketlik alomat, yechim emas: ikki komponent ham /etc/resolv.conf o'ziniki deb hisoblaydi va oxirgi yozgan yutadi. Faylni qulflash egalik mojarosini hal qilmaydi, faqat yashiradi va shu bilan birga siz aslida xohlagan komponentni buzadi. Quyidagi to'rtta tekshiruvni tartib bilan bajaring va tartibni faylda emas, unga egalik qiladigan darajada tuzating.

Tekshiruv 1: bu ramziy havolami va qayerga

Faylning o'zidan boshlang, chunki tahrirlayotgan yo'lingiz fayl bo'lmasligi mumkin. Hal qiluvchining ishlash katalogiga olib boradigan ramziy havola, mijoz skripti qayta yozadigan oddiy fayldan butunlay boshqacha ishlaydi:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

systemd-resolved'ning stub yo'liga havola fayl mazmuni yaratilishini bildiradi va qo'lda tahrirlash keyingi hodisada ustidan yoziladi. nameserver satrlari bo'lgan oddiy faylni odatda ulanish paytida ishlaydigan mijoz yoki DHCP ilgagi yozadi. Ikkalasi ham qonuniy; muhimi biror narsani o'zgartirishdan oldin qaysi biri borligini bilishdir.

Tekshiruv 2: qaysi demon ishlayapti

Nima o'rnatilganini emas, nima haqiqatan faol ekanini aniqlang. Zamonaviy distributivda bir nechta hal qiluvchi bo'lishi mumkin va loopback interfeysida 53-portni ushlab turgani javob beradi:

systemctl status systemd-resolved --no-pager
resolvectl status
ss -lunp | grep ':53'

Holat chiqishi har bir havola bo'yicha DNS serverlarini va marshrutlash domenlarini nomlaydi, bu esa split DNS uchun kerakli xarita. Agar ichki nomlar ichki serverga, qolgan hammasi ommaviy serverga borishi kerak bo'lsa, bu siyosat har bir havola domenlarida yashaydi va uni fayldagi statik nameserver ro'yxatiga tekislash bu farqni jimgina yo'qotadi.

NetworkManager'ning o'z konfiguratsiyasi ushbu backend'lardan qaysi birini ishlatishni hal qiladi. Asosiy konfiguratsiya faylidagi uning dns= parametri uning ichki hal qiluvchisi, dnsmasq, systemd-resolved va none o'rtasidan tanlaydi va distributiv sizning o'rningizga tanlagan bo'lishi mumkin. Bu xostda “DNS'ni tuzatish” nimani anglatishini hal qilishdan oldin o'sha parametrni o'qing.

Tekshiruv 3: VPN mijoziga nima yozishga ruxsat

Mojaro odatda shu yerda yashaydi. Hal qiluvchi faylini to'g'ridan-to'g'ri qayta yozadigan VPN mijozi uni ham saqlaydigan har qanday xizmat bilan kurashadi va yutqazuvchi birinchi ishga tushgani bo'ladi. Yaqindagi OpenVPN nashrlari faylni qayta yozish o'rniga DNS sozlamalarini systemd-resolved'ga bera oladi, bu siz xohlagan hamkorlik xatti-harakati; eski skriptlar va qo'lda yozilgan ilgaklar ko'pincha eskirgan yordamchi vositani chaqiradi yoki shunchaki fayl ustiga yozadi.

WireGuard holati shakli jihatidan o'xshash: interfeys konfiguratsiyasining o'zi DNS'ni boshqarmaydi, buni atrofidagi vositalar hal qiluvchi yordamchisi yoki resolved integratsiyasi orqali qiladi. Agar ikkita shunday yordamchi o'rnatilgan bo'lsa, ikkalasi ham ulanish paytida o'z dunyoqarashini joriy etishga harakat qiladi.

Taxmin qilish o'rniga mijozning up va down ilgaklarini o'qing. /etc/openvpn/up.sh yoki shunga teng katalogdagi bir necha satr shell boshqacha tasodifiy ko'rinadigan xatti-harakatni tushuntiradi va mijozni raqobatga emas, hamkorlikka majbur qiladigan joy ham o'sha.

Tekshiruv 4: uni egasida tuzating, faylda emas

Egasi kimligini bilganingizdan so'ng DNS'ni o'sha egasi qo'llab-quvvatlaydigan interfeys orqali sozlang. systemd-resolved uchun bu statik fayl o'rniga har bir havola sozlamalari va marshrutlash domenlari; NetworkManager uchun ulanish profili DNS sozlamalari va tanlangan backend; resolvconf integratsiyasidan foydalanadigan distributiv uchun o'sha yordamchi orqali yozish.

Faylni o'zgarmas qilmang. O'zgarmaslik atributi qonuniy DHCP yangilanishlari va VPN yangilanishlarini siz kurashganlar bilan birga to'xtatadi va tizimni keyingi paket yangilanishi yoki qayta ulanish konfiguratsiyadan hech kim tushuntira olmaydigan nosozlik keltiradigan holatda qoldiradi. U egalik mojarosini yashiradi, bu esa aynan siz hal qilmoqchi bo'lgan narsa.

Ikki komponent haqiqatan birga yashashi kerak bo'lgan joyda ularga turli vazifalar bering. Tarmoq menejeriga interfeys darajasidagi konfiguratsiyani egalik qilishga ruxsat bering, VPN mijoziga o'sha integratsiya orqali har bir havola DNS'i va domenlarini qo'shishga imkon bering va faylni to'g'ridan-to'g'ri yozadigan uchinchi skriptni olib tashlang. systemd-resolved hujjatlari u qo'llab-quvvatlaydigan rejimlarni va ularning har biri /etc/resolv.conf ichida nimani ko'rsatishini bayon qiladi. Saqlashingiz kerak bo'lgan siyosat hajmiga mos rejimni tanlang. Agar split DNS muhim bo'lsa, har bir havola domenlari bilan stub tartibi uni saqlaydi, upstream serverlarni faylga ko'chiruvchi rejim esa uni jimgina tekislaydi.

Qayta ulangandan keyin tekshiring, tahrirdan keyin emas

O'zgartirishingizdan keyin darhol to'g'ri ko'rinadigan fayl hech narsani isbotlamaydi, chunki keyingi hodisa hali sodir bo'lmagan. Uni avval buzgan ketma-ketlikni ishga tushiring: tunnelnni tushirib, qayta ko'taring, DHCP ijarasini yangilang yoki interfeysni almashtiring, so'ng o'sha qiymatlarni yana o'qing.

resolvectl query build.corp.example
resolvectl query example.com
resolvectl status | head -40

So'ng muhim farqni tasdiqlang: ichki nom ichki server orqali hal qilinadi, ommaviy nom esa hali ishlaydi. Hamma narsani ichki serverga yuboradigan konfiguratsiya kimdir tunnel orqali internetga chiqishga urinmaguncha yaxshi ko'rinadi, hamma narsani ommaviyga yuboradigan konfiguratsiya esa ichki nomlarni oshkor qiladi.

Joylashtirish qaydlarida egasi, backend va ramziy havola rejimini yozib qo'ying. O'sha bitta paragraf kelajakdagi paket yangilanishini hodisadan ko'rib chiqish bandiga aylantiradi va keyingi odamning chattr buyrug'i bilan o'sha mojaroni qayta kashf qilishiga yo'l qo'ymaydi.