Mount CIFS Anda gagal lewat VPN karena urutan nsswitch

Tunelnya hidup. Server file menjawab ping lewat alamat. Lalu mount.cifs dengan nama host duduk di situ beberapa saat dan melaporkan bahwa host tidak dapat dijangkau, dan Anda mulai membangun ulang profil VPN yang sama sekali bukan masalahnya. Di Linux, nama diselesaikan oleh glibc sebelum ada satu paket SMB pun, dan urutan di resolver itu bisa mengakhiri pencarian sebelum DNS pernah ditanya. Inilah langkah yang saya lakukan, dimulai dari perintah yang gagal, bukan dari klien.

Baca kegagalan di tempat yang benar

Dua alat menempuh jalur berbeda ke nama yang sama, dan membandingkannya hanya butuh satu perintah. getent menyusuri tumpukan layanan nama yang dikonfigurasi; host dan dig menanyakan DNS langsung dan mengabaikan tumpukan itu. Jika kueri langsung mengembalikan alamat dan getent tidak mengembalikan apa pun, server DNS dapat dijangkau dan konfigurasi resolver Andalah yang gagal.

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

Perintah ketiga adalah penentunya: ia memaksa sumber DNS dan melewati sisa tumpukan. Ketika perintah itu berhasil dan getent biasa tidak, Anda sudah membuktikan bahwa urutannya yang salah, bukan tunelnya dan bukan servernya.

Baris hosts adalah urutan yang berhenti lebih awal

Resolver glibc membaca /etc/nsswitch.conf dan menelusuri entri hosts: dari kiri ke kanan. Banyak distro mengirim baris yang menempatkan pencarian multicast lebih dulu dengan aksi kembali lebih awal menempel padanya. Aksi itu bukan hiasan: ketika mDNS menjawab “not found”, [NOTFOUND=return] mengakhiri seluruh pencarian, sehingga nama korporat tidak pernah dikirim ke resolver yang didorong VPN. Tidak ada yang mencatatnya, karena tidak ada kueri yang dikirim untuk ditolak resolver. Itulah sebabnya mount tampak menggantung lalu melaporkan host yang tidak dapat dijangkau.

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 depan aksi kembali lebih awal alih-alih menghapus mDNS, dan ubah lewat manajemen konfigurasi. Suntingan tangan bertahan sampai build image berikutnya, lalu tiket yang sama datang dari mesin lain yang tidak mengingat perbaikannya.

Resolver bukan domain pencarian

Resolusi juga menuntut nama itu dicoba. Nama tanpa kualifikasi seperti fileserver baru menjadi fileserver.corp.example ketika sebuah domain pencarian dilekatkan pada antarmuka yang membawa kueri. VPN yang mendorong server DNS tanpa daftar pencarian menghasilkan pemisahan yang sangat khas: nama yang sepenuhnya terkualifikasi berhasil diselesaikan dan setiap nama pendek gagal.

Uji kedua bentuk sebelum menyunting profil, karena kedua kegagalan menunjuk arah yang berbeda. Pada host dengan systemd-resolved, tautan tunel memiliki server dan domain perutean sendiri, jadi baca tautannya, bukan file global.

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

Jika kueri dikaitkan dengan tautan yang tidak membawa tunel, domain perutean itu hilang meskipun alamat DNS ada. Itu masalah kebijakan pada konfigurasi resolved, bukan masalah perutean pada tunel.

Kontainer membawa salinan jawabannya sendiri

Kontainer yang dibangun dari image umum biasanya membawa resolv.conf tetap. Perubahan resolver di host tidak sampai ke sana, begitu pula domain pencarian, sehingga tugas build yang me-mount share lewat tunel gagal sementara perintah yang sama berhasil di luar kontainer. Beri kontainer setelan DNS dan pencariannya sendiri di file compose atau di argumen run, bukan hanya di profil host.

Periksa di dalam kontainer sebelum menyalahkan image. Dua perintah mereproduksi seluruh diagnosis dalam beberapa detik, dan yang kedua membuktikan resolver mana yang benar-benar menjawab.

Baru setelah itu lihat share dan filternya

Setelah nama terselesaikan, kegagalan yang tersisa adalah masalah jaringan biasa. SMB membutuhkan TCP 445 ke server, dan menelusuri daftar grup kerja bergantung pada layanan nama yang kemungkinan tidak diteruskan tunel. Petakan berdasarkan nama host alih-alih menunggu daftar terisi, dan biarkan klien memberi tahu Anda tahap mana yang dicapainya. Koneksi yang ditolak dan timeout yang senyap juga layak dipisahkan, karena yang pertama biasanya berarti ada yang menjawab dan yang kedua berarti tidak ada.

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 terselesaikan dengan port 445 ditolak atau kedaluwarsa adalah masalah firewall atau listener di sisi jauh. Nama yang tidak terselesaikan adalah masalah resolver. Dan mount yang berhasil mengautentikasi tetapi mengembalikan galat izin bukan keduanya, jadi jangan buka lagi pertanyaan jaringan setelah sesi terbentuk.

Jaga kesimpulan sekecut buktinya. Ketika alamat berhasil dan nama tidak, tunel menjalankan tugasnya dan perbaikan ada pada urutan resolver, domain pencarian, atau konfigurasi kontainer itu sendiri.