Perkongsian SMB gagal hanya melalui VPN: isu tandatangan atau pertembungan subnet?

Pemacu yang dipetakan dan berfungsi di pejabat tetapi tamat masa di rumah hampir tidak memberi maklumat berguna dengan sendirinya. Terowong jelas membawa paket, jika tidak tiada apa yang akan sampai ke pelayan. Yang gagal terletak pada satu daripada tiga lapisan: nama diselesaikan ke alamat yang salah, klien enggan menandatangani sesi, atau sesi lama hidup lebih lama daripada sambungan yang membawanya. Setiap satu mempunyai pembaikan berbeza, dan dua daripada tiga berada di pihak klien.

Tiga kegagalan memakai ralat yang sama

Huruf pemacu tidak memberitahu lapisan mana yang rosak, dan teks ralat biasanya cukup umum untuk menepati ketiga-tiganya. Asingkan dengan dua soalan pantas: adakah pelayan menjawab pada alamat IP-nya, dan adakah port 445 menerima sambungan?

Jawapan itu menghasilkan jadual keputusan dan bukan tekaan. Jika IP berfungsi tetapi nama tidak, ia menunjuk ke resolusi nama. Jika kedua-duanya berfungsi tetapi log masuk ditolak, ia menunjuk ke tandatangan. Jika kedua-duanya berfungsi tetapi bacaan fail tergantung selepas terowong terputus, ia menunjuk ke sesi lapuk.

Lakukan mengikut urutan itu, kerana nama yang diselesaikan ke hos yang salah menjadikan setiap ujian berikutnya tidak bermakna.

Selesaikan nama sebelum menyentuh perkongsian

Jika pelayan menjawab pada alamatnya dan nama perkongsian tamat masa, terowong sedang menjalankan tugasnya dan klien mencari di tempat yang salah. Dalam akses jauh, dua punca menjelaskan sebahagian besar perkara ini.

Yang pertama ialah pertindihan alamat. Apabila pejabat menggunakan 192.168.70.0/24 dan penghala rumah memberikan julat yang sama, nama hos yang diselesaikan ke 192.168.70.20 boleh menunjuk kepada peranti tempatan dan bukan pelayan di belakang terowong. Windows kemudian mungkin menghantar permintaan secara tempatan, menolak laluan, atau menyelesaikannya ke pencetak yang kebetulan mempunyai alamat itu. Pembaikannya ialah menomborkan semula satu pihak, bukan menambah laluan lain.

Yang kedua ialah skop DNS. Penyesuai VPN tanpa pelayan DNS dalaman, atau dengan pelayan yang tidak dapat dicapai melalui terowong, membiarkan nama pendek pergi ke penyelesai awam. Baca entri DNS penyesuai dan tanya nama dalaman secara langsung sebelum menyentuh perkongsian:

> 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.15

Jika pertanyaan itu mengembalikan alamat yang dijangka, resolusi nama sudah jelas dan masalahnya lebih tinggi dalam tindanan.

Baca keperluan tandatangan pada kedua-dua hujung

Pelayan yang boleh dicapai tetapi menolak setiap log masuk adalah tanda ketidakpadanan dasar dan bukan kerosakan rangkaian. Windows boleh mewajibkan tandatangan SMB pada klien, dan pelayan atau NAS yang tidak menandatangani tidak boleh melengkapkan sesi, sekuat mana pun terowong itu.

Anda boleh membaca tetapan klien tanpa menelusuri editor dasar:

> Get-SmbClientConfiguration | Select-Object RequireSecuritySignature
RequireSecuritySignature
-------------------------
True
> Get-SmbConnection

Nilai sepadan di pihak pelayan terdapat dalam konfigurasi SMB pelayan, dan kedua-duanya mesti bersetuju. Dalam satu kes yang dilaporkan, klien mengaktifkan keperluan melalui dasar tempatan manakala pelayan langsung tidak menandatangani; melumpuhkannya dan menjalankan gpupdate /force memulihkan perkongsian serta-merta. Itu langkah diagnostik untuk mengesahkan punca, bukan pembaikan kekal.

Utamakan menghidupkan tandatangan pada kedua-dua hujung di tempat pelayan menyokongnya. Perubahan tetapan keselamatan supaya perkongsian berfungsi perlu direkodkan bersama nilai sebelumnya dan sebabnya, agar tiada siapa perlu menemuinya semula semasa audit seterusnya.

Bersihkan sesi lapuk sebelum menala pemasa

Perkongsian yang hanya tergantung selepas VPN terputus dan bersambung semula biasanya memegang sesi yang telah dibuang pelayan. Pelayan menutup sesi SMB yang melahu mengikut pemasa Autodisconnect di bawah LanmanServer\Parameters, yang secara lalai 15 minit, manakala klien mempunyai SessTimeout sendiri di bawah LanmanWorkstation\Parameters. Gangguan yang lebih lama daripada nilai itu meninggalkan setiap hujung dengan tanggapan berbeza tentang sesi.

Hasilkan semula dalam urutan tetap supaya hasilnya bermakna: sambungkan terowong, buka perkongsian, putuskan terowong selama dua minit, pulihkannya, kemudian cuba baca fail. Jika lekap pulih sendiri, biarkan pemasa. Jika ia tergantung sehingga anda melekap semula, sambung semula perkongsian selepas terowong naik dan bukan melekapnya sebelum ia wujud, dan periksa sama ada pembantu lekap mencuba semula.

Menaikkan tamat masa ialah langkah terakhir yang wajar untuk pautan yang tidak stabil, tetapi ia merawat gejala. Klien yang menunggu lebih lama untuk sesi yang telah dilupakan pelayan masih menunggu.

Akhiri dengan membaca satu fail melalui lekap, kemudian memutuskan dan memulihkan terowong sekali lagi. Ujian penerimaan itu meliputi ketiga-tiga lapisan sekali gus, dan itulah satu-satunya ujian yang sepadan dengan apa yang benar-benar dilakukan pengguna.