resolvectl chiqishidan har bir ulanish uchun VPN DNS yo'naltirishini qanday o'qish kerak
resolvectl status har bir ulanish uchun serverlar, domenlar va standart yo'lni ko'rsatadi. Ularni birga o'qing, so'ng nomni so'rab, qaysi ulanish javob berganini belgilang.
resolvectl status ni ishga tushiring va har bir ulanish uchun bloklar devorini olasiz, har birida o'z serverlari va o'z domen satri bor. Yo'naltirishni hal qiladigan satr — domenlar ro'yxati, nom serverining manzili emas, chunki mahalliy stub har bir so'rovni nomni da'vo qilgan ulanishga yuboradi. Javobni o'qishdan oldin o'sha da'volarni o'qing, so'ng nomni so'rab, uni qaysi ulanish yaratganini tekshiring. To'g'ri ulanishdan noto'g'ri javob noto'g'ri ulanishdan to'g'ri javobdan boshqa muammo.
Har bir ulanish bloki sizga nima aytadi
Har bir blok hal qiluvchi o'sha interfeys uchun ishlatadigan serverlarni, domenlar ro'yxatini va ulanish standart yo'l ekanini sanab o'tadi. Domenlar ro'yxati da'volar to'plami, hal qiluvchi esa eng uzun qo'shimchaning mosligini qo'llaydi: host.corp.example uchun so'rovni corp.example bor ulanish faqat standart yo'li bor ulanishdan oldin da'vo qiladi. Bir xil qo'shimchani da'vo qilgan ikki ulanish natijani ustuvorlik va tartibga qoldiradi, shuning uchun nusxalar birinchi navbatda e'tiborga loyiq. Joriy server satri ro'yxatdagi serverlardan qaysi biri o'sha paytda ishlatilayotganini ko'rsatadi.
/etc/resolv.conf dagi 127.0.0.53 kabi stub manzili faqat stub oldinda ekanini aytadi. U javob bergan yuqori manbani nomlamaydi, shuning uchun faqat resolv.conf ga tayangan diagnostika tiqilib qoladi.
Domen yozuvlarining uch turini to'g'ri o'qing
| Yozuv | Nimani da'vo qiladi | Odatiy xato |
|---|---|---|
| corp.example | yo'naltirish domeni va qidiruv qo'shimchasi: uning ostidagi nomlar shu ulanishga boradi va satr yalang'och nomlarga qo'shiladi | olib tashlangan, chunki yo'naltirish baribir ishlayotgandek ko'rinadi |
| ~corp.example | faqat yo'l: uning ostidagi nomlar shu ulanishga boradi, lekin qo'shimcha qo'shilmaydi | yo'naltirish uchun zarur deb taxmin qilingan |
| ~. | standart yo'l: boshqa hech qaysi ulanish qoplamaydigan so'rovlarni da'vo qiladi | bo'lingan profilda faol qoldirilgan, shuning uchun ommaviy nomlar tunnelga ergashadi |
Tilda qidiruv xatti-harakatini o'zgartiradi, yo'naltirishni emas. Tildasiz yozuv ham yo'naltirish domeni, ham qidiruv domeni bo'ladi, shuning uchun uning ostidagi nomlar o'sha ulanishga yuboriladi va bir yorliqli nomlarga qo'shimcha qo'shiladi. Tildali yozuv o'sha qo'shimchani yo'naltiradi, lekin uni qidiruv ro'yxatidan tashqarida tutadi. Shuning uchun tildani olib tashlash qaysi yalang'och nomlar hal qilinishini o'zgartiradi va shuning uchun tilda yo'qligi qidiruv muammosi, bo'lingan DNS nosozligi emas.
Standart yo'l yozuvi boshqa hech qaysi ulanish qoplamaydigan hamma narsani da'vo qiladi. To'liq tunnel profili odatda uni xohlaydi, bo'lingan profil odatda xohlamaydi, chunki ommaviy nomlar shunda xususiy hal qiluvchiga boradi va u yerda muvaffaqiyatsiz bo'lishi mumkin. Profillar orasida bayroqlarni nusxalash o'rniga jadvalni profil niyatiga qarab o'qing. Ikki ulanish bir xil qo'shimchani da'vo qilsa, boshqa narsani tahrirlashdan oldin ustuvorlik masalasini hal qiling.
Nom so'rab, qaysi ulanish javob berganini ko'ring
query quyi buyrug'i manzilni, protokolni va javobni yaratgan ulanish yoki doirani chop etadi. Xususiy qo'shimcha da'vo qilishi kerak bo'lgan bir nomni va bitta oddiy ommaviy nomni sinab ko'ring, so'ng xabar qilingan manbalarni solishtiring. Agar xususiy nom simsiz ulanishdan javob bersa, da'vo yo'q yoki tunnel o'chgan; agar bo'lingan profilda ommaviy nom tunneldan javob bersa, standart yo'l juda keng. Bu ikki nosozlik brauzerda bir xil, bu chiqishda esa teskari ko'rinadi.
resolvectl status
resolvectl query host.corp.exampleXabar qilingan protokolga ham e'tibor bering, chunki kesh yoki hosts faylidan javob hech qaysi yuqori manbadan so'ramasdan kelishi mumkin. Keshdan kelgan javob nom qachondir hal qilinganini isbotlaydi, joriy siyosat uni to'g'ri yo'naltirishini emas.
Nom yo'naltirishini paket yo'naltirishidan alohida tuting
Hal qiluvchi qarori yo'l yaratmaydi. Tanlangan server hali ham o'z manziliga yo'l kerak, qaytarilgan manzil esa hali ham xususiy tarmoqqa yo'l kerak, shuning uchun to'g'ri DNS siyosati hech qachon ochilmaydigan ulanish bilan birga bo'lishi mumkin. Nom hal qilinib, ilova muvaffaqiyatsiz bo'lsa, DNS ni yana o'zgartirish o'rniga manzil va yo'lni tekshiring. Nom hal qilish va yetib borish — ikki xil egasi bo'lgan ikki savol.
Ilovalar o'zlarining xavfsiz DNS sozlamasi yoki ichki hal qiluvchi orqali tizim hal qiluvchisini butunlay chetlab o'tishi mumkin. resolvectl natijasi tizim yo'lini tasvirlaydi va uni e'tiborsiz qoldirgan brauzer siz qilgan har bir sinovga zid bo'ladi. Siyosat buzilgan degan xulosaga kelishdan oldin o'sha sozlamani tekshiring.
Nom hal qilingan manzilni ulanish yoniga yozib qo'ying. Noto'g'ri manzilga ishora qilgan to'g'ri nom yo'naltirish emas, yozuv muammosi.
Ulanish o'zgargandan keyin yana tekshiring
Qayta ulanish yoki simsiz tarmoq almashinuvi ulanish holatini qayta quradi va tarmoq menejeri qo'lda o'rnatilgan hamma narsa ustiga o'z domenlari va serverlarini qayta o'rnatishi mumkin. So'ng o'sha ikki nomni so'rab, yozilgan tayanch chiziq bilan solishtiring. Agar qo'lda kiritilgan o'zgartirish yo'qolgan bo'lsa, tuzatish ulanish profilida bo'lishi kerak shell buyrug'ida emas. Oldin va keyin yozib olish aynan shuni ko'rinadigan qiladi.
Hisobotga kerak bo'lgan nomlar va server kontekstini ulashing, chunki ichki qo'shimchalar topologiyani oshkor qiladi. Domenlarni yo'naltirish haqidagi systemd-resolved hujjati eng uzun moslik qoidasini va tilda xatti-harakatini qamrab oladi, bir marta o'qish yuqoridagi jadval xatolarining ko'pini oldini oladi: systemd-resolved da so'rovlarni yo'naltirish.