OpenVPN-ə qoşulmusunuz, amma ping və SMB paylaşımı yoxdur? Üç keçidi yoxlayın
İşləyən tunel yönləndirmə, SMB portları və ya ad axtarışı barədə heç nə demir. Hər keçidi sıra ilə yoxlayın və ilk uğursuz olanda dayanın.
Tunel qalxır, müştəri ünvan alır və uzaq LAN-da heç nə cavab vermir. Ping uğursuz olur, paylaşım açılmır və VPN jurnalı təmiz görünür, çünki onun nöqteyi-nəzərindən sessiya sağlamdır. Həmin sessiya ilə serverdəki fayl arasında üç müstəqil keçid durur: yönləndirmə siyasəti, xidmətin ehtiyac duyduğu portlar və ünvan yerinə yazdığınız ad.
Hər keçid fərqli simptomla uğursuz olur və yalnız birincisi VPN serverindədir.
Yönləndirmə FORWARD zəncirindəki siyasətdir
OpenVPN dinləyicisinin qəbulu INPUT-da baş verir, buna görə tunel qoşula bilir, halbuki LAN-a yönələn hər paket atılır. tun0 üzərindən gəlib LAN interfeysindən çıxan trafik FORWARD-dan keçir və orada standart DROP siyasəti olan host onu səssizcə atır. Başqa bir şeyə toxunmadan əvvəl həm sysctl-i, həm də zənciri yoxlayın: sysctl net.ipv4.ip_forward və iptables -L FORWARD -v -n.
Nəzərdə tutduğunuz istiqamətə və ona aid cavablara icazə verin, məsələn tunel interfeysindən LAN interfeysinə qəbul qaydası və qurulmuş və əlaqəli trafik üçün vəziyyət əsaslı qayda. LAN başqa marşrutlaşdırıcının arxasındadırsa, həmin marşrutlaşdırıcıya müştəri hovuzuna geri marşrut və ya VPN serverində mənbə NAT lazımdır. Daha çox qayda əlavə etməzdən əvvəl bu yolu bir ping ilə təsdiqləyin, çünki çatılmayan qayda heç vaxt sayğacda görünmür.
SMB bir portdan çoxunu tələb edir
Fayl paylaşımı tək bir TCP 445 söhbəti deyil. Kəşfiyyat UDP 137 və 138 istifadə edir, köhnə NetBIOS sessiyaları TCP 139, müasir SMB sessiyaları isə TCP 445 istifadə edir. Yalnız 445-i açan qayda, xəritələnmiş diskin işlədiyi, şəbəkəyə baxışın işləmədiyi və ya əksinə olduğu qıcıqlandırıcı halı yaradır.
Tuneldən böyük köçürmələr də qırıq paylaşım kimi görünən MSS problemlərinə düşür. LAN-ın tam seqment ölçüsünü elan edən SYN tunelin daha kiçik MTU-su tərəfindən atılır və bağlantı əl sıxışmadan sonra asılır. Yönləndirmə yolunda MSS-in sıxılması, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, bu növ dayanmanı aradan qaldırır. Kataloq siyahısı yerinə bir neçə meqabaytlıq kopya ilə yoxlayın, çünki kiçik cavablar toplu köçürmələr keçmədikdə belə keçir.
Tunel adapteri yeni şəbəkə profili kimi gəlir
Windows hər adapteri bir şəbəkə profilinə təsnif edir və yeni tunel adapteri adətən Public-ə düşür, burada fayl və printer paylaşımı qaydaları bloklanır. Bu, fayl serverindəki host firewall qərarıdır, VPN serverindəki marşrut problemi deyil. Siyasətin buna icazə verdiyini təsdiqlədikdən sonra kateqoriyanı qəsdən Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private ilə dəyişin, çünki kateqoriya hansı daxil olan qaydaların tətbiq olunduğunu da dəyişir.
Eyni profil ping uğursuz olub TCP 445 uğurlu olduğu halı izah edir: əks-səda sorğuları Public-də standart olaraq atılır.
Adlar yönləndirilmiş tuneldən özbaşına keçmir
NetBIOS ad həlli və yerli kəşfiyyat yönləndirilmiş tunelin daşımadığı yayımlara əsaslanır. Buna görə serverin qısa adını yazmaq uğursuz olur, ünvanı isə işləyir və yalnız axtarış problemli olanda paylaşım qırıq görünür. Tunelin verdiyi həlledicidə server üçün DNS qeydi əlavə edin və ya qısayolda ünvanı istifadə edin.
Yerləşdirmə hələ də WINS-dən asılıdırsa, yayım trafikinin görünəcəyinə ümid etmək əvəzinə onu müştəridə konfiqurasiya edin. Əvvəlcə ünvanla yoxlayın ki, ad uğursuzluğu firewall uğursuzluğu ilə qarışdırılmasın.
Bir dəfə bir qatı yoxlayın və ilk uğursuzluğu oxuyun
Yuxarı doğru işləyin: tunel şlüzünü ping edin, LAN hostunu ünvanla ping edin, sonra xidmət portunu Test-NetConnection -ComputerName 10.8.0.5 -Port 445 ilə açın və yalnız ondan sonra paylaşımda kimlik doğrulayın. Uğursuz olan ilk addım düzəldilməli qatdır və hər sonrakı addım keçənə qədər səs-küydür. Cavab verən ping port bağlı qaldıqda fayl serverinin öz firewalluna işarə edir, səssiz pinglərə baxmayaraq açılan port isə ICMP filtrləməsinə işarə edir. Nəyisə dəyişməzdən əvvəl ilk uğursuz addımı yazın, çünki ikinci dəyişiklik birincinin nəticəsini gizlədir.
VPN serveri LAN-ın marşrutlaşdırıcısı deyilsə, serverə daha çox qayda əlavə etməzdən əvvəl həmin marşrutlaşdırıcıda geri marşrutu təsdiqləyin. Onsuz sorğular hosta çatır və cavablar internetə doğru standart marşrutla çıxır, bu da müştəri tərəfindən tam olaraq firewall atması kimi görünür.
Paylaşım hesabını qeydlərinizdə VPN girişindən ayrı saxlayın, çünki uğurlu tunel fayl icazələri barədə heç nə demir. Çatışmayan qaydanı yan keçmək üçün SMB-ni internetə açmaq həll deyil.