Berbagi SMB gagal hanya lewat VPN: masalah tanda tangan atau bentrok subnet?
Berbagi yang berjalan di LAN bisa gagal hanya lewat terowongan. Pisahkan penolakan tanda tangan, subnet yang tumpang tindih, dan sesi SMB yang basi.
Drive yang dipetakan dan berjalan di kantor tetapi kehabisan waktu di rumah hampir tidak memberi informasi berguna apa pun dengan sendirinya. Terowongan jelas sedang membawa paket, jika tidak, tidak ada yang akan mencapai server. Yang gagal ada di salah satu dari tiga lapisan: nama diselesaikan ke alamat yang salah, klien menolak menandatangani sesi, atau sesi lama hidup lebih lama daripada koneksi yang membawanya. Masing-masing punya perbaikan berbeda, dan dua dari tiga ada di sisi klien.
Tiga kegagalan memakai galat yang sama
Huruf drive tidak memberi tahu lapisan mana yang rusak, dan teks galat biasanya cukup umum untuk cocok dengan ketiganya. Pisahkan dengan dua pertanyaan cepat: apakah server menjawab di alamat IP-nya, dan apakah port 445 menerima koneksi?
Jawaban itu menghasilkan tabel keputusan alih-alih tebakan. Jika IP berfungsi tetapi nama tidak, itu menunjuk ke resolusi. Jika keduanya berfungsi tetapi logon ditolak, itu menunjuk ke tanda tangan. Jika keduanya berfungsi tetapi pembacaan berkas menggantung setelah terowongan putus, itu menunjuk ke sesi basi.
| Symptom | Layer to inspect |
|---|---|
| IP works, hostname times out | DNS or subnet overlap |
| TCP 445 opens, logon refused | SMB signing policy |
| Hangs after reconnect | Session state and timers |
Kerjakan dalam urutan itu, karena nama yang diselesaikan ke host yang salah membuat setiap pengujian berikutnya tidak berarti.
Selesaikan nama sebelum menyentuh berbagi
Jika server menjawab di alamatnya dan nama berbagi kehabisan waktu, terowongan sedang menjalankan tugasnya dan klien mencari di tempat yang salah. Pada akses jarak jauh, dua penyebab menjelaskan sebagian besar hal ini.
Yang pertama adalah tumpang tindih alamat. Ketika kantor memakai 192.168.70.0/24 dan router rumah memberikan rentang yang sama, nama host yang diselesaikan ke 192.168.70.20 bisa menunjuk perangkat lokal alih-alih server di balik terowongan. Windows lalu dapat mengirim permintaan secara lokal, menolak rute, atau menyelesaikannya ke printer yang kebetulan memiliki alamat itu. Perbaikannya adalah menomori ulang satu sisi, bukan menambahkan rute lain.
Yang kedua adalah cakupan DNS. Adaptor VPN tanpa server DNS internal, atau dengan server yang tidak terjangkau melalui terowongan, membiarkan nama pendek pergi ke resolver publik. Baca entri DNS adaptor dan tanyakan nama internal secara langsung sebelum menyentuh berbagi:
> ipconfig /all | findstr /i "DNS Servers"
> nslookup files.corp.internal
Server: 10.90.0.2
Address: 10.90.0.2
Name: files.corp.internal
Address: 10.90.0.15Jika kueri itu mengembalikan alamat yang diharapkan, resolusi nama sudah jelas dan masalahnya ada lebih tinggi di tumpukan.
Baca persyaratan tanda tangan di kedua ujung
Server yang dapat dijangkau tetapi menolak setiap logon adalah tanda ketidakcocokan kebijakan, bukan kerusakan jaringan. Windows dapat mewajibkan tanda tangan SMB di klien, dan server atau NAS yang tidak menandatangani tidak dapat menyelesaikan sesi, sekuat apa pun terowongannya.
Anda dapat membaca pengaturan klien tanpa menelusuri editor kebijakan:
> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnectionNilai yang sesuai di sisi server ada di konfigurasi SMB server, dan keduanya harus sepakat. Dalam satu kasus yang dilaporkan, klien mengaktifkan persyaratan melalui kebijakan lokal sementara server sama sekali tidak menandatangani; menonaktifkannya lalu menjalankan gpupdate /force memulihkan berbagi seketika. Itu langkah diagnostik untuk memastikan penyebabnya, bukan perbaikan permanen.
Utamakan mengaktifkan tanda tangan di kedua ujung di tempat server mendukungnya. Mengubah pengaturan keamanan agar berbagi berfungsi harus dicatat bersama nilai sebelumnya dan alasannya, supaya tidak ada yang perlu menemukannya lagi pada audit berikutnya.
Bersihkan sesi basi sebelum menyetel pengatur waktu
Berbagi yang hanya menggantung setelah VPN putus dan tersambung lagi biasanya menahan sesi yang sudah dibuang server. Server menutup sesi SMB yang menganggur menurut pengatur waktu Autodisconnect di bawah LanmanServer\Parameters, yang secara bawaan 15 menit, sementara klien punya SessTimeout sendiri di bawah LanmanWorkstation\Parameters. Gangguan yang lebih lama dari nilai itu membuat tiap ujung punya gambaran berbeda tentang sesi.
Reproduksi dalam urutan tetap agar hasilnya bermakna: sambungkan terowongan, buka berbagi, putuskan terowongan selama dua menit, pulihkan, lalu coba baca berkas. Jika mount pulih sendiri, biarkan pengatur waktu. Jika menggantung sampai Anda me-mount ulang, sambungkan kembali berbagi setelah terowongan naik alih-alih me-mount sebelum terowongan ada, dan periksa apakah pembantu mount mencoba lagi.
Menaikkan batas waktu adalah langkah terakhir yang wajar untuk tautan yang tidak stabil, tetapi itu mengobati gejalanya. Klien yang menunggu lebih lama untuk sesi yang sudah dilupakan server tetap menunggu.
Akhiri dengan membaca satu berkas melalui mount, lalu memutus dan memulihkan terowongan sekali lagi. Uji penerimaan itu mencakup ketiga lapisan sekaligus, dan itulah satu-satunya uji yang cocok dengan apa yang benar-benar dilakukan pengguna.