CIFS mount’ingiz VPN orqali nsswitch tartibi tufayli ishlamaydi

Ulashma manzil bo‘yicha javob beradi, nom bo‘yicha esa osilib qoladi, shuning uchun qidiruv SMB boshlanishidan oldin o‘ladi. getent ni host bilan solishtiring, so‘ng hosts satrini tartib bilan o‘qing.

Tunnel ishlayapti. Fayl serveri ping ga manzil bo‘yicha javob beradi. Keyin mount.cifs xost nomi bilan bir muddat shunday o‘tirib, xostga yetib bo‘lmayotganini xabar qiladi, siz esa hech qachon muammo bo‘lmagan VPN profilini qaytadan qurishga kirishasiz. Linux da har qanday SMB paketi paydo bo‘lishidan oldin nomni glibc hal qiladi va o‘sha resolverdagi tartib DNS so‘ralishidan oldin qidiruvni tugatishi mumkin. Bu men yuradigan yo‘l, mijozdan emas, muvaffaqiyatsiz bo‘lgan buyruqdan boshlanadi.

Xatoni to‘g‘ri joyda o‘qing

Ikki asbob bir nomga turli yo‘llar bilan boradi va ularni solishtirish bitta buyruqqa tushadi. getent sozlangan nom xizmati stekidan o‘tadi; host va dig DNS dan bevosita so‘raydi va bu stekni e’tiborsiz qoldiradi. Agar bevosita so‘rov manzil qaytarsa, getent esa hech narsa qaytarmasa, DNS server yetib boradigan joyda va muvaffaqiyatsizlik sizning resolver sozlamangizda.

getent hosts fileserver.corp.example
host fileserver.corp.example 10.61.0.1
getent -s dns hosts fileserver.corp.example

Uchinchi buyruq hal qiluvchi: u DNS manbasini majburan tanlaydi va stekning qolganini o‘tkazib yuboradi. U ishlab, oddiy getent ishlamasa, ayb tartibda ekanini, tunnelda ham, serverda ham emasligini isbotladingiz.

hosts satri erta to‘xtaydigan ketma-ketlik

glibc resolver /etc/nsswitch.conf ni o‘qib, hosts: yozuvini chapdan o‘ngga yuradi. Ko‘p distributivlar multicast qidiruvi birinchi turadigan va unga erta qaytish amali biriktirilgan satrni yetkazadi. Bu amal bezak emas: mDNS “not found” deb javob berganda, [NOTFOUND=return] butun qidiruvni tugatadi, shuning uchun korporativ nom VPN majburlagan resolverga hech qachon yuborilmaydi. Hech narsa buni jurnalga yozmaydi, chunki resolver rad eta oladigan so‘rov umuman yuborilmagan. Shuning uchun mount osilib qolgandek ko‘rinadi va keyin xostga yetib bo‘lmayotganini xabar qiladi.

cat /etc/nsswitch.conf | grep '^hosts:'
# illustrative repair: dns before the early-return action
hosts: files myhostname mdns4_minimal dns [NOTFOUND=return] wins mdns4

mDNS ni o‘chirish o‘rniga DNS ni erta qaytish amalidan oldinga suring va buni konfiguratsiyani boshqarish orqali o‘zgartiring. Qo‘lda qilingan tuzatish keyingi image qurilishigacha yashaydi, keyin o‘sha chipta tuzatishni eslamaydigan boshqa mashinadan keladi.

Resolver qidiruv domeni emas

Hal qilish uchun nom sinab ko‘rilishi ham kerak. fileserver kabi to‘liq bo‘lmagan nom faqat so‘rovni olib yuruvchi interfeysga qidiruv domeni biriktirilganda fileserver.corp.example bo‘ladi. Qidiruv ro‘yxatisiz DNS server majburlaydigan VPN juda aniq bo‘linish keltiradi: to‘liq malakali nom hal bo‘ladi va har bir qisqa nom muvaffaqiyatsiz bo‘ladi.

Profilni tahrirlashdan oldin ikkala shaklni ham sinab ko‘ring, chunki ikkala muvaffaqiyatsizlik turli tomonga ishora qiladi. systemd-resolved xostida tunnel havolasining o‘z serverlari va marshrutlash domenlari bor, shuning uchun global faylni emas, havolani o‘qing.

resolvectl status
resolvectl query fileserver.corp.example
resolvectl dns
resolvectl domain

Agar so‘rov tunnelni olib yurmaydigan havolaga tegishli bo‘lsa, DNS manzili bor bo‘lsa ham marshrutlash domeni yetishmaydi. Bu resolved konfiguratsiyasidagi siyosat muammosi, tunneldagi marshrutlash muammosi emas.

Konteynerlar javobning o‘z nusxasini olib yuradi

Umumiy image dan qurilgan konteyner odatda qat’iy resolv.conf olib keladi. Xostda qilingan resolver o‘zgarishlari unga yetib bormaydi, qidiruv domeni ham yetib bormaydi, shuning uchun tunnel orqali ulashmani mount qiladigan build ishi muvaffaqiyatsiz bo‘ladi, o‘sha buyruq esa konteynerdan tashqarida ishlaydi. Konteynerga o‘zining DNS va qidiruv sozlamalarini compose faylida yoki run argumentlarida bering, faqat xost profilida emas.

Image ni ayblashdan oldin konteyner ichida tekshiring. Ikki buyruq butun diagnostikani bir necha soniyada qayta hosil qiladi va ikkinchisi qaysi resolver haqiqatan javob berganini isbotlaydi.

Shundan keyingina ulashma va filtrga qaraysiz

Nom hal bo‘lgach, qolgan muvaffaqiyatsizliklar oddiy tarmoq muammolari. SMB ga servergacha TCP 445 kerak, ish guruhi ro‘yxatini ko‘rish esa tunnel, ehtimol, uzatmaydigan nom xizmatlariga bog‘liq. Ro‘yxat to‘lishini kutish o‘rniga xost nomi bo‘yicha xaritalang va mijoz qaysi bosqichga yetganini aytsin. Rad etilgan ulanish va jim timeout ni ham ajratish kerak, chunki birinchisi odatda nimadir javob berganini, ikkinchisi hech narsa javob bermaganini bildiradi.

getent hosts fileserver.corp.example
nc -vz fileserver.corp.example 445
mount -t cifs //fileserver.corp.example/share /mnt/share \
  -o vers=3.1.1,username=svc_mount,uid=1000

Hal bo‘lgan manzilda 445 port rad etilgan yoki vaqti tugagan bo‘lsa, bu narigi tomondagi firewall yoki listener muammosi. Hal bo‘lmagan nom — resolver muammosi. Va autentifikatsiyadan o‘tib, ruxsat xatolarini qaytaradigan mount ikkalasi ham emas, shuning uchun sessiya o‘rnatilgach tarmoq savolini qayta ochmang.

Xulosani dalil qadar tor tuting. Manzil ishlab, nom ishlamasa, tunnel o‘z ishini qilyapti, tuzatish esa resolver tartibiga, qidiruv domeniga yoki konteynerning o‘z konfiguratsiyasiga tegishli.

O'xshash maqolalar