SMB paylaşımı yalnız VPN üzərindən uğursuz olur: imzalama, yoxsa alt şəbəkə toqquşması?

Ofisdə işləyən, evdə isə vaxt aşımına uğrayan xəritələnmiş disk özlüyündə demək olar ki, heç bir faydalı məlumat vermir. Tunel açıq şəkildə paket daşıyır, əks halda serverə heç nə çatmazdı. Uğursuz olan üç qatdan biridir: ad yanlış ünvana həll olundu, müştəri sessiyanı imzalamaqdan imtina etdi və ya köhnə sessiya onu daşıyan bağlantıdan uzun yaşadı. Hər birinin fərqli təmiri var və üçdən ikisi müştəri tərəfindədir.

Üç nasazlıq eyni xətanı daşıyır

Disk hərfi hansı qatın qırıldığını demir və xəta mətni adətən üçünə də uyğun gələcək qədər ümumidir. Onları iki sürətli sualla ayırın: server IP ünvanından cavab verirmi və 445 portu bağlantı qəbul edirmi?

Bu cavablar təxmin əvəzinə qərar cədvəli verir. IP işləyir, ad işləmir – bu ad həllinə işarə edir. İkisi də işləyir, amma giriş rədd olunur – bu imzalamaya işarə edir. İkisi də işləyir, amma fayl oxunuşu tunel kəsilməsindən sonra donur – bu köhnəlmiş sessiyaya işarə edir.

Onları bu ardıcıllıqla keçin, çünki yanlış hosta həll olunan ad hər sonrakı testi mənasız edir.

Paylaşıma toxunmadan əvvəl adı həll edin

Server öz ünvanından cavab verir, paylaşım adı isə vaxt aşımına uğrayırsa, tunel işini görür və müştəri yanlış yerə baxır. Uzaqdan girişdə bunun çoxunu iki səbəb izah edir.

Birincisi ünvan üst-üstə düşməsidir. Ofis 192.168.70.0/24 istifadə edərkən ev marşrutlaşdırıcısı eyni aralığı paylayırsa, 192.168.70.20-yə həll olunan host adı tunelin arxasındakı server əvəzinə yerli cihazı göstərə bilər. Windows sonra sorğunu yerli olaraq göndərə, marşrutu rədd edə və ya həmin ünvana sahib olan printerə həll edə bilər. Təmir bir tərəfi yenidən nömrələməkdir, başqa marşrut əlavə etmək deyil.

İkincisi DNS əhatəsidir. Daxili DNS serveri olmayan və ya tunel üzərindən əlçatan olmayan VPN adapteri qısa adları açıq resolverə buraxır. Adapterin DNS qeydlərini oxuyun və paylaşıma toxunmadan əvvəl daxili adı birbaşa soruşun:

> 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

Bu sorğu gözlənilən ünvanı qaytarırsa, ad həlli aydınlaşır və problem yığında daha yuxarıdadır.

İmzalama tələbini hər iki tərəfdə oxuyun

Hər girişi rədd edən əlçatan server şəbəkə nasazlığı deyil, siyasət uyğunsuzluğu əlamətidir. Windows müştəridə SMB imzalamasını tələb edə bilər və imzalamayan server və ya NAS, tunel nə qədər sağlam olsa da, sessiyanı tamamlaya bilməz.

Müştəri parametrini siyasət redaktorunda axtarmadan oxuya bilərsiniz:

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

Server tərəfindəki uyğun dəyər serverin SMB konfiqurasiyasındadır və ikisi uyğun olmalıdır. Bildirilən bir halda müştəridə tələb yerli siyasətlə aktiv idi, server isə ümumiyyətlə imzalamırdı; onu söndürmək və gpupdate /force işə salmaq paylaşımı dərhal bərpa etdi. Bu, səbəbi təsdiqləmək üçün diaqnostik addımdır, daimi düzəliş deyil.

Serverin dəstəklədiyi yerlərdə imzalamanı hər iki tərəfdə aktivləşdirməyə üstünlük verin. Bir paylaşımın işləməsi üçün təhlükəsizlik parametrini dəyişmək əvvəlki dəyəri və səbəbi ilə qeyd olunmalıdır ki, növbəti auditdə heç kim onu yenidən kəşf etməli olmasın.

Taymerləri tənzimləməzdən əvvəl köhnəlmiş sessiyanı təmizləyin

Yalnız VPN düşdükdən və yenidən qoşulduqdan sonra donan paylaşım adətən serverin artıq atdığı sessiyanı saxlayır. Server boş SMB sessiyalarını LanmanServer\Parameters altındakı Autodisconnect taymeri ilə bağlayır, bu standart olaraq 15 dəqiqədir, müştərinin isə LanmanWorkstation\Parameters altında öz SessTimeout-i var. Bu dəyərlərdən uzun kəsinti hər iki tərəfi sessiya haqqında fərqli təsəvvürlə qoyur.

Nəticənin mənası olsun deyə sabit ardıcıllıqla təkrarlayın: tuneli qoşun, paylaşımı açın, tuneli iki dəqiqə kəsin, bərpa edin, sonra fayl oxumağa çalışın. Bağlama öz-özünə bərpa olunursa, taymerlərə toxunmayın. Yenidən bağlamadan donursa, tunel qalxdıqdan sonra paylaşımı yenidən qoşun, mövcud olmadan əvvəl bağlamaq əvəzinə, və bağlama köməkçisinin yenidən cəhd edib-etmədiyini yoxlayın.

Vaxt aşımlarını artırmaq qeyri-sabit bağlantı üçün məqbul son addımdır, amma simptomu müalicə edir. Serverin unutduğu sessiyanı daha uzun gözləyən müştəri yenə gözləyir.

Bağlama vasitəsilə bir fayl oxuyub tuneli bir dəfə də kəsib bərpa etməklə bitirin. Bu qəbul testi üç qatı birdən əhatə edir və istifadəçinin həqiqətən etdiyi ilə uyğun gələn yeganə testdir.