SoftEther SecureNAT: DHCP və NAT iki ayrı qərardır

SecureNAT iki xidməti bir anda işə salan tək seçim qutusudur və onunla bağlı çaşqınlığın çoxu elə buradan gəlir. Virtual DHCP server müştəriyə ünvan, maska, şlüz və çox vaxt həlledici verir. Virtual NAT isə paketləri həmin şlüzdən server hostunun öz şəbəkə yığını ilə ötürür. Onlar konfiqurasiyada yan-yana durur və bir-birindən asılı olmadan sıradan çıxır: müştərinin kamil icarəsi olub işlək yolu olmaya bilər, ya da işlək yolu olub parametrləri səhv həllediciyə baxa bilər. Onları iki qərar kimi yoxlayın, diaqnoz qısalır.

Bir seçim qutusunun arxasında iki xidmət

Virtual DHCP tərəfi konfiqurasiya sualına cavab verir: bu müştəri bu Virtual Hub daxilində hansı parametrləri alır. Virtual NAT tərəfi isə ötürmə sualına cavab verir: müştəri hub-dan kənar ünvana paket göndərdikdə server onu tərcümə edib ötürürmü. Birincisi hub üçün lokaldır və yuxarı şəbəkəyə ehtiyac duymur. İkincisi tamamilə hostdan asılıdır.

Virtual host interfeysi ikinci deyil, birinci qərara aiddir. Onun ünvanı, çox vaxt susmaya görə 192.168.30.1 kimi bir şey, DHCP xidmətinin təklif etdiyi şlüzdür. Bu, serverin ictimai dinləmə ünvanı deyil və ikisini qarışdırmaq, o şəbəkədə mövcud olmayan maşına yönəlmiş firewall qaydaları və müştəri parametrləri yaradır.

Qərar 1: ünvanı kim verir

Virtual DHCP aktivdirsə, müştərilər qurduğunuz hovuzda icarə almalıdır: şlüz kimi virtual host interfeysi, həlledici kimi isə təqdim etdiyiniz həlledici. Müştərinin status mətninə deyil, icarənin özünə baxın, çünki «qoşulub» tuneli təsvir edir, ünvan təyinatını yox:

vpncmd localhost /SERVER /CMD SecureNatStatusGet
vpncmd localhost /SERVER /CMD DhcpGet
ip -4 addr show
ip route

Başqa bir şeyi sazlamazdan əvvəl iki nasazlıq rejimini bilməyə dəyər. Əvvəlki dizayndan qalan statik ünvanı olan müştəri onu saxlayıb icarəyə məhəl qoymayacaq və bu, DHCP-nin cavab verməkdən imtina etməsi kimi görünəcək. Körpülənmiş seqmentdə ikinci DHCP mənbəyi isə eyni müştərilər üçün rəqabət aparacaq, bu da fasilələrlə dəyişən ünvanlar və problemi təkrarlaya bilməyən dəstək növbəsi yaradır.

Üst-üstə düşən hovuzlar da bura aiddir. Virtual DHCP hovuzu hostun LAN subneti ilə və ya başqa hub-ın hovuzu ilə üst-üstə düşürsə, müştəri qeyri-müəyyən marşrutlaşdırılan ünvan alır və sonrakı hər test qeyri-qəti olur.

Qərar 2: virtual şlüzün arxasına kim ötürür

Virtual NAT aktiv olduqda hub-dan çıxan trafik server tərəfindən tərcümə olunur və hostun marşrutlaşdırma cədvəlindən keçirilir. Bu o deməkdir ki, ötürmə zənciri belədir: müştəridən virtual şlüzə, virtual NAT-dan host yığınına, host yığınından öz susmaya görə marşrutuna. Hər halqa digərlərinə toxunmadan sıradan çıxa bilər və nasazlıq əlamətləri fərqlidir.

İkinci qərarı hub-dan çıxmalı olan bir şeylə sınayın, onun daxilindəki lokallıqla yox. Virtual şlüzü ping etmək yalnız birinci halqanı sübut edir, başqa heç nə:

vpncmd localhost /SERVER /CMD NatGet
vpncmd localhost /SERVER /CMD NatTable
dig +short example.com
ip route get 203.0.113.10

Ad həlli işləyirsə, amma ictimai ünvana qoşulmalar uğursuz olursa, siz DHCP-də deyil, ötürmə zəncirindəsiniz. İkisi də uğursuz olursa, əvvəlcə həllediciyə baxın, çünki əlçatmaz daxili ünvan kimi ötürülən həlledici işlək yolu tamamilə sınıq göstərəcək.

SecureNAT-ın ötürməsini körpü ilə istifadə edəcəyiniz nüvə ötürmə yolu deyil, server prosesi həyata keçirir. Bu rahatdır və körpüləmədən yavaşdır, həm də o deməkdir ki, hostun öz firewall qaydaları və marşrut qərarları tərcümə olunmuş trafikə hələ də tətbiq olunur. Virtual NAT hostun siyasətini yan keçmir; ondan istifadə edir.

Hostun öz yolu üçüncü bir şeydir

Yuxarıdakıların hamısı server hostunun təyinat nöqtəsinə çata bildiyini fərz edir. İşlək yuxarı marşrutu olmayan, çıxış siyasəti məhdud olan və ya hostun malik olmadığı ünvan ailəsi ilə üzləşən host, hub konfiqurasiyası nə qədər düzgün olsa da, ikinci qərarda uğursuz olacaq. Uğursuzluğunu SoftEther-ə bağlamazdan əvvəl hostu tuneldən kənarda, təkbaşına yoxlayın.

SecureNAT həm də serverə qoşulmuş hər şəbəkəyə çatmaq üçün icazə deyil. O, özünə çatan trafiki tərcümə edib ötürür; hostun nəyə çata biləcəyini qərar vermək hələ də hostun firewall və marşrut işidir və giriş verməyi tunelə həvalə edən dizayn, həddindən artıq giriş verməkdən bir pis qayda uzaqdır.

Ünvan ailələri öz yoxlamasını haqq edir. İşlək IPv4 DHCP nümunəsi, işlətdiyiniz buraxılışda hər IPv6 imkanının olduğunu təsdiqləmir, ona görə ikili yığın davranışı vəd etməzdən əvvəl həqiqətən işlətdiyiniz versiyanın təlimatını oxuyun. Təlimatın SecureNAT bölməsi cari buraxılış üçün virtual NAT və DHCP funksiyalarını əhatə edir.

Hər qərarı öz testi ilə yoxlayın

Birinci qərarı icarə yoxlaması ilə qəbul edin: ünvan hovuzdadır, şlüz virtual host interfeysinə bərabərdir, həlledici sizin qurduğunuzdur. İkincisini müştəridən çıxan sorğu və serverdə NAT cədvəlinə baxışla qəbul edin, çünki artan sessiya sayı tərcümənin sadəcə aktiv olmasının deyil, həqiqətən baş verməsinin yeganə birbaşa sübutudur.

Sonra bölgünü dizayn qeydinə yazın: ünvanı hansı komponent verir, hansı komponent ötürür və trafik hansı host interfeysindən çıxır. Yenidən başlatma davranışı dəyişdikdə, həmin qeyd hər şeyi yenidən başladıb simptomun yer dəyişəcəyinə ümid etmək əvəzinə üçündən hansını yoxlamalı olduğunuzu söyləyir.

Daha bir qərar qeydə aiddir, hətta bu gün onu vermirsinizsə də: SecureNAT və yerli körpü eyni hub üçün fərqli dizaynlardır və hər ikisinə ehtiyacı olan hub fərqli plana ehtiyacı olan hubdır. Qərarı bilərəkdən verin, səbəbini yazın, sonrakı adam onu işləyən konfiqurasiyadan tərsinə mühəndislik etməli olmayacaq.