CIFS montajı VPN üzərində nsswitch sırasına görə uğursuz olur

Tunel işləyir. Fayl serveri ping-ə ünvana görə cavab verir. Sonra mount.cifs host adı ilə bir müddət eləcə durur və host-un əlçatmaz olduğunu bildirir, siz də heç vaxt problem olmayan VPN profilini yenidən qurmağa başlayırsınız. Linux-da adı glibc hər hansı SMB paketi yaranmadan əvvəl həll edir və o həlledicidəki sıra DNS-dən heç soruşulmadan axtarışı bitirə bilər. Budur mənim getdiyim yol: müştəridən deyil, uğursuz olan əmrdən başlayaraq.

Uğursuzluğu düzgün yerdə oxuyun

İki alət eyni ada fərqli yollarla gedir və onları müqayisə etmək bir əmrə başa gəlir. getent konfiqurasiya olunmuş ad xidməti yığını ilə gedir; host və dig isə DNS-i birbaşa sorğulayır və o yığına məhəl qoymur. Birbaşa sorğu ünvan qaytarır, getent isə heç nə qaytarmırsa, DNS serveri əlçatandır və uğursuz olan sizin həlledici konfiqurasiyanızdır.

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

Üçüncü əmr həlledicidir: DNS mənbəyini məcbur edir və yığının qalanını keçir. Bu işləyib adi getent işləmirsə, sübut etdiniz ki, günah sıradadır — nə tuneldə, nə də serverdə.

hosts sətri erkən dayanan bir ardıcıllıqdır

glibc həlledicisi /etc/nsswitch.conf faylını oxuyur və hosts: girişini soldan sağa gedir. Bir çox distributiv elə sətir göndərir ki, orada multicast axtarışı əvvəl gəlir və ona erkən qayıdış əməliyyatı bağlanıb. Əməliyyat bəzək deyil: mDNS “not found” cavabı verəndə [NOTFOUND=return] bütün axtarışı bitirir, ona görə də korporativ ad VPN-in itələdiyi həllediciyə heç vaxt göndərilmir. Heç nə bunu jurnala yazmır, çünki rədd ediləcək heç bir sorğu göndərilməyib. Buna görə montaj asılıb qalmış kimi görünür və sonra əlçatmaz host bildirir.

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-i silmək əvəzinə DNS-i erkən qayıdış əməliyyatından qabağa çəkin və bunu konfiqurasiya idarəetməsi ilə dəyişin. Əl ilə düzəliş növbəti image quruluşuna qədər yaşayır, sonra eyni bilet düzəlişi xatırlamayan başqa maşından gəlir.

Həlledici axtarış domeni deyil

Həll üçün həm də adın sınanması lazımdır. fileserver kimi keyfiyyətsiz ad yalnız sorğunu daşıyan interfeysə axtarış domeni bağlandıqda fileserver.corp.example olur. Axtarış siyahısı olmadan DNS serveri itələyən VPN çox konkret bir parçalanma yaradır: tam keyfiyyətli ad həll olunur, hər qısa ad isə uğursuz olur.

Profili redaktə etməzdən əvvəl hər iki formanı sınayın, çünki iki uğursuzluq fərqli istiqamətlərə işarə edir. systemd-resolved olan hostda tunel linkinin öz serverləri və marşrutlaşdırma domenləri var, ona görə qlobal faylı deyil, linki oxuyun.

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

Sorğu tuneli daşımayan linkə aid edilirsə, DNS ünvanı mövcud olsa da marşrutlaşdırma domeni yoxdur. Bu, resolved konfiqurasiyasında siyasət problemi, tuneldə isə marşrutlaşdırma problemi deyil.

Konteynerlər cavabın öz nüsxəsini daşıyır

Ümumi image-dən qurulmuş konteyner adətən sabit resolv.conf faylı ilə gəlir. Hostda edilən həlledici dəyişiklikləri ona çatmır, axtarış domeni də çatmır, ona görə tunel üzərindən paylaşım montaj edən build işi uğursuz olur, halbuki eyni əmr konteynerdən kənarda işləyir. Konteynerə öz DNS və axtarış parametrlərini compose faylında və ya run arqumentlərində verin, yalnız host profilində yox.

Image-i günahlandırmadan əvvəl konteynerin içində yoxlayın. İki əmr bütün diaqnozu bir neçə saniyədə təkrar edir, ikincisi isə hansı həlledicinin həqiqətən cavab verdiyini sübut edir.

Yalnız bundan sonra paylaşıma və filtrə baxın

Ad həll olunduqdan sonra qalan uğursuzluqlar adi şəbəkə problemləridir. SMB serverə TCP 445 tələb edir, iş qrupu siyahısına baxmaq isə tunelin çox güman ötürmədiyi ad xidmətlərindən asılıdır. Siyahının dolmasını gözləmək əvəzinə host adı ilə bağlayın və müştəri sizə hansı mərhələyə çatdığını desin. Rədd edilmiş bağlantı ilə səssiz timeout-u da ayırmağa dəyər, çünki birincisi adətən nəyinsə cavab verdiyini, ikincisi heç nəyin cavab vermədiyini bildirir.

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

Həll olunmuş ünvanla 445 portunun rədd edilməsi və ya timeout olması qarşı tərəfdə firewall və ya listener problemidir. Həll olunmayan ad həlledici problemidir. Autentifikasiyadan keçib icazə xətaları qaytaran montaj isə nə biri, nə də digəridir, ona görə sessiya qurulduqdan sonra şəbəkə sualını yenidən açmayın.

Nəticəni sübut qədər dar saxlayın. Ünvan işləyib ad işləmirsə, tunel öz işini görür və düzəliş həlledici sırasına, axtarış domeninə və ya konteynerin öz konfiqurasiyasına aiddir.