Pelekap CIFS anda gagal melalui VPN kerana susunan nsswitch

Terowong sudah naik. Pelayan fail menjawab ping melalui alamat. Kemudian mount.cifs dengan nama hos duduk di situ beberapa ketika dan melaporkan bahawa hos tidak dapat dihubungi, dan anda mula membina semula profil VPN yang tidak pernah menjadi masalah. Pada Linux, nama diselesaikan oleh glibc sebelum sebarang paket SMB wujud, dan susunan dalam penyelesai itu boleh menamatkan carian sebelum DNS pernah ditanya. Inilah langkah yang saya lakukan, bermula daripada arahan yang gagal, bukan daripada klien.

Baca kegagalan di tempat yang betul

Dua alat menempuh laluan berbeza ke nama yang sama, dan membandingkannya hanya memerlukan satu arahan. getent menyusuri tindanan perkhidmatan nama yang dikonfigurasikan; host dan dig menanyakan DNS secara langsung dan mengabaikan tindanan itu. Jika pertanyaan langsung mengembalikan alamat dan getent tidak mengembalikan apa-apa, pelayan DNS boleh dihubungi dan konfigurasi penyelesai andalah yang gagal.

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

Arahan ketiga ialah penentunya: ia memaksa sumber DNS dan melangkau baki tindanan. Apabila ia berjaya dan getent biasa tidak, anda telah membuktikan bahawa susunan itulah yang salah, bukan terowong dan bukan pelayan.

Baris hosts ialah urutan yang berhenti awal

Penyelesai glibc membaca /etc/nsswitch.conf dan menyusuri entri hosts: dari kiri ke kanan. Banyak distribusi menghantar baris yang meletakkan carian multicast lebih dahulu dengan tindakan pulang awal terlekat padanya. Tindakan itu bukan hiasan: apabila mDNS menjawab “not found”, [NOTFOUND=return] menamatkan seluruh carian, jadi nama korporat tidak pernah dihantar kepada penyelesai yang didorong oleh VPN. Tiada apa yang merekodkannya, kerana tiada pertanyaan dihantar untuk ditolak oleh penyelesai. Itulah sebabnya pelekap kelihatan tergantung dan kemudian melaporkan hos yang tidak dapat dihubungi.

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

Letakkan DNS di hadapan tindakan pulang awal dan bukan memadam mDNS, dan ubahnya melalui pengurusan konfigurasi. Suntingan tangan bertahan sehingga pembinaan image seterusnya, dan kemudian tiket yang sama tiba dari mesin lain yang tidak mengingati pembaikan itu.

Penyelesai bukan domain carian

Penyelesaian juga memerlukan nama itu dicuba. Nama tanpa kelayakan seperti fileserver hanya menjadi fileserver.corp.example apabila domain carian dilampirkan pada antara muka yang membawa pertanyaan. VPN yang mendorong pelayan DNS tanpa senarai carian menghasilkan pemisahan yang sangat khusus: nama yang layak sepenuhnya diselesaikan dan setiap nama pendek gagal.

Uji kedua-dua bentuk sebelum menyunting profil, kerana kedua-dua kegagalan menunjuk arah yang berbeza. Pada hos systemd-resolved, pautan terowong memiliki pelayan dan domain penghalaan sendiri, jadi baca pautan itu dan bukan fail global.

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

Jika pertanyaan dikaitkan dengan pautan yang tidak membawa terowong, domain penghalaan itu hilang walaupun alamat DNS ada. Itu masalah dasar dalam konfigurasi resolved, bukan masalah penghalaan dalam terowong.

Kontena membawa salinan jawapan mereka sendiri

Kontena yang dibina daripada image generik biasanya membawa resolv.conf tetap. Perubahan penyelesai pada hos tidak sampai ke sana, begitu juga domain carian, jadi tugas build yang melekapkan kongsi melalui terowong gagal manakala arahan yang sama berjaya di luar kontena. Berikan kontena tetapan DNS dan cariannya sendiri dalam fail compose atau dalam argumen run, bukan hanya dalam profil hos.

Periksa di dalam kontena sebelum menyalahkan image. Dua arahan menghasilkan semula seluruh diagnosis dalam beberapa saat, dan yang kedua membuktikan penyelesai mana yang benar-benar menjawab.

Barulah selepas itu lihat kongsi dan penapisnya

Setelah nama diselesaikan, kegagalan yang tinggal ialah masalah rangkaian biasa. SMB memerlukan TCP 445 ke pelayan, dan menyemak imbas senarai kumpulan kerja bergantung pada perkhidmatan nama yang mungkin tidak diteruskan oleh terowong. Petakan mengikut nama hos dan bukan menunggu senarai dipenuhi, dan biarkan klien memberitahu anda peringkat mana yang dicapainya. Sambungan yang ditolak dan timeout yang senyap juga wajar dipisahkan, kerana yang pertama biasanya bermaksud sesuatu menjawab dan yang kedua bermaksud tiada apa yang menjawab.

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

Alamat yang diselesaikan dengan port 445 ditolak atau tamat masa ialah masalah firewall atau pendengar di sebelah sana. Nama yang tidak diselesaikan ialah masalah penyelesai. Dan pelekap yang mengesahkan tetapi mengembalikan ralat kebenaran bukan kedua-duanya, jadi jangan buka semula soalan rangkaian setelah sesi terbentuk.

Kekalkan kesimpulan sesempit bukti. Apabila alamat berjaya dan nama tidak, terowong menjalankan tugasnya dan pembaikan terletak pada susunan penyelesai, domain carian atau konfigurasi kontena itu sendiri.