CIFS bağlamanız VPN üzerinden nsswitch sırası yüzünden başarısız oluyor

Tünel ayakta. Dosya sunucusu ping'e adresle yanıt veriyor. Sonra mount.cifs ana bilgisayar adıyla bir süre öylece bekliyor ve ana bilgisayara ulaşılamadığını bildiriyor; siz de hiçbir zaman sorun olmayan bir VPN profilini yeniden kurmaya başlıyorsunuz. Linux'ta adı, herhangi bir SMB paketi oluşmadan önce glibc çözer ve o çözümleyicideki sıra, DNS'e hiç sorulmadan aramayı sonlandırabilir. İşte benim izlediğim yol; istemciden değil, başarısız olan komuttan başlıyor.

Hatayı doğru yerde okuyun

İki araç aynı ada farklı yollardan gider ve bunları karşılaştırmak tek komuta mal olur. getent yapılandırılmış ad hizmeti yığınından geçer; host ve dig doğrudan DNS'e sorar ve o yığını yok sayar. Doğrudan sorgu bir adres döndürürken getent hiçbir şey döndürmüyorsa, DNS sunucusuna ulaşılabilir ve başarısız olan sizin çözümleyici yapılandırmanızdır.

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

Üçüncü komut belirleyicidir: DNS kaynağını zorlar ve yığının geri kalanını atlar. O çalışırken sıradan getent çalışmıyorsa, suçun sırada olduğunu, tünelde ve sunucuda olmadığını kanıtlamış olursunuz.

hosts satırı erken duran bir dizidir

glibc çözümleyicisi /etc/nsswitch.conf dosyasını okur ve hosts: girdisini soldan sağa geçer. Pek çok dağıtım, multicast aramasının önce geldiği ve ona erken dönüş eylemi eklenmiş bir satır gönderir. O eylem süs değildir: mDNS “not found” diye yanıt verdiğinde [NOTFOUND=return] tüm aramayı bitirir, böylece kurumsal ad VPN'in dayattığı çözümleyiciye hiç gönderilmez. Bunu hiçbir şey günlüğe yazmaz, çünkü çözümleyicinin reddedebileceği bir sorgu hiç gönderilmemiştir. Bu yüzden bağlama takılmış gibi görünür ve ardından ulaşılamayan bir ana bilgisayar 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 silmek yerine DNS'i erken dönüş eyleminin önüne taşıyın ve bunu yapılandırma yönetimi üzerinden değiştirin. Elle yapılan düzeltme bir sonraki image derlemesine kadar yaşar, sonra düzeltmeyi hatırlamayan başka bir makineden aynı bilet gelir.

Çözümleyici bir arama alan adı değildir

Çözümleme, adın denenmesini de gerektirir. fileserver gibi tam niteliksiz bir ad, ancak sorguyu taşıyan arayüze bir arama alan adı eklendiğinde fileserver.corp.example olur. Arama listesi olmadan DNS sunucusu dayatan bir VPN çok belirli bir bölünme üretir: tam nitelikli ad çözülür ve her kısa ad başarısız olur.

Profili düzenlemeden önce iki biçimi de test edin, çünkü iki hata farklı yönleri gösterir. systemd-resolved olan bir ana bilgisayarda tünel bağlantısının kendi sunucuları ve yönlendirme alan adları vardır, bu yüzden genel dosyayı değil bağlantıyı okuyun.

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

Sorgu tüneli taşımayan bir bağlantıya atfedilirse, DNS adresi mevcut olsa bile yönlendirme alan adı eksiktir. Bu, resolved yapılandırmasındaki bir ilke sorunudur, tüneldeki bir yönlendirme sorunu değil.

Konteynerler yanıtın kendi kopyasını taşır

Genel bir image'den oluşturulan konteyner genellikle sabit bir resolv.conf getirir. Ana bilgisayarda yapılan çözümleyici değişiklikleri ona ulaşmaz, arama alan adı da ulaşmaz; bu yüzden tünel üzerinden paylaşım bağlayan build işi başarısız olurken aynı komut konteynerin dışında çalışır. Konteynere kendi DNS ve arama ayarlarını compose dosyasında veya run argümanlarında verin, yalnızca ana bilgisayar profilinde değil.

Image'i suçlamadan önce konteynerin içinde kontrol edin. İki komut tüm tanıyı birkaç saniyede yeniden üretir ve ikincisi hangi çözümleyicinin gerçekten yanıt verdiğini kanıtlar.

Ancak o zaman paylaşıma ve filtreye bakın

Ad çözüldükten sonra kalan hatalar olağan ağ sorunlarıdır. SMB sunucuya TCP 445 ister ve bir çalışma grubu listesine göz atmak, tünelin muhtemelen iletmediği ad hizmetlerine bağlıdır. Listenin dolmasını beklemek yerine ana bilgisayar adına göre eşleyin ve istemcinin hangi aşamaya geldiğini söylemesine izin verin. Reddedilen bağlantı ile sessiz timeout da ayrılmayı hak eder, çünkü ilki genellikle bir şeyin yanıt verdiğini, ikincisi hiçbir şeyin yanıt vermediğini gösterir.

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

Çözülen adreste 445 portu reddedilmiş veya zaman aşımına uğramışsa bu karşı taraftaki güvenlik duvarı veya dinleyici sorunudur. Çözülemeyen ad, çözümleyici sorunudur. Ve kimlik doğrulaması yapıp izin hataları döndüren bağlama ikisi de değildir, bu yüzden oturum kurulduktan sonra ağ sorusunu yeniden açmayın.

Sonucu kanıt kadar dar tutun. Adres çalışıp ad çalışmadığında tünel işini yapıyor demektir ve düzeltme çözümleyici sırasına, arama alan adına veya konteynerin kendi yapılandırmasına aittir.