Hər iki tərəfdə eyni subnet: uzaq LAN-ı sərbəst aralığa xəritələyin

Ev və ofis hər ikisi 192.168.1.0/24 istifadə edir, buna görə 192.168.1.1-ə sorğunun iki mümkün cavabı var və müştəri soruşmadan birini seçir. İşlək ofis şəbəkəsini yenidən nömrələmək nadir hallarda populyardır və marşrutlaşdırıcı ünvanları çox vaxt printerlərə, kameralara və sənədlərə həkk olunub. Müştəri tərəfində ünvan xəritələmə uzaq şəbəkəni əvəzinə sərbəst aralıq altında təqdim edə bilər və host hissəsi eyni qala bilər ki, 192.168.1.20 10.203.41.20 kimi görünsün. İncə məqam budur ki, bunu yalnız bəzi müştərilər tətbiq edir və onun geri dönüş yolu üçün heç bir faydası yoxdur.

Eyni hostun iki görünüşü

Xəritələmə host hissəsini saxlayır və yalnız şəbəkə hissəsini dəyişdirir. Sonra eyni maşın harada dayandığınızdan asılı olaraq iki ünvanda cavab verir. Hər şeyi konfiqurasiya etməzdən əvvəl hər iki sütunu yazmaq sonradan jurnalların və firewall qaydalarının səhv oxunmasının qarşısını alır.

Evdəki yerli cihazlar öz 192.168.1.x ünvanlarını saxlayır və məşqin məqsədi də budur. Qonşu otaqdakı printer əlçatan qalır, ofis isə toqquşmayan aralıq altında görünür.

Arqument sırası bütün hiylədir

Seçim istiqamət, şəbəkə və maska, həmçinin ləqəb alır: birinci şəbəkə müştərinin gördüyü, ləqəb isə serverin gördüyüdür. Uzaq şlüz arxasında yerləşən resurslar üçün istiqamət təyinat formasıdır. Son arqument ləqəb adlandırıldığı üçün iki şəbəkəni tərsinə çevirmək, qoşulan amma heç nə xəritələməyən tunel yaradan səhvdir.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Marşrut müştərinin yeni aralıq üçün paketlərini tunelə göndərəndir; tərcümə isə keçid zamanı təyinatı yenidən yazır. 192.168.1.20-dən cavab 10.203.41.20-yə geri yazılır ki, müştəridəki soket uyğun qalsın. Tək host tam uzunluqlu maska ilə eyni şəkildə işləyir, bir şərtlə ki, marşrut və xəritələmə eyni ünvanı təsvir etsin.

Bu ünvan xəritələməsidir, port xəritələməsi deyil. Bir hostdakı iki xidməti bununla ayırmaq mümkün deyil və IP ünvanlarını yükünün içində daşıyan protokol hələ də həqiqi ünvanları görəcək.

Xəritələmə geri dönüş yolu yaratmır

Tərcümə müştəridə baş verir, ona görə server hələ də cavabları tunelə yönləndirməli və firewall-u onlara icazə verməlidir. Uzaq şlüz tunel subnetinə necə çatacağını bilmirsə, sorğu gəlir və cavab yanlış qapıdan çıxır; xəritələmə sadəcə nasazlığı müştəri problemi kimi göstərir.

Server tərəfindəki qaydalar tərcümədən sonra serverdə mövcud olan ünvanları təsvir etməlidir, müştəriyə görünən aralığı deyil. Ləqəbi icazə qaydasına köçürmək bir axşamı boşa verir, çünki o tərəfdə heç bir paket onu daşımır.

Müştərinin marşrutlaşdırdığı başqa heç nə ilə toqquşmayan ləqəb aralığı seçin: başqa VPN, konteyner şəbəkəsi, ikinci ofis. Burada toqquşma ilkin qeyri-müəyyənliyi fərqli nömrə altında geri qaytarır və ünvanlar tanış olmadığı üçün görmək daha çətindir.

Adlar və yüklər tərcümədən sağ çıxır

Həqiqi 192.168.1.20-ə həll olunan host adı brauzeri uzaq cihaz əvəzinə yerli cihaza göndərir, marşrut cədvəlinin nə dediyindən asılı olmayaraq. Şəxsi DNS cavabı müştəriyə görünən aralığa işarə etməlidir, TLS sertifikatı isə hələ də tətbiqin gözlədiyi adı daşıyır. Ünvanla deyil, adla sınaqdan keçirin, çünki ünvan işləyə bilər, ad isə səssizcə yanlış istiqamətə həll olunur. Uzaq şlüz də həmin zonaya xidmət edəndə onun öz qeydləri də müştəriyə görünən aralığa ehtiyac duyur.

Yönləndirmələr, daxil edilmiş URL-lər və öz ünvanını yükün içində verən tətbiqlər heç bir paket xəritələməsinin düzəldə bilməyəcəyi şəkildə poza bilər. Bunları tətbiq problemi kimi qəbul edin və yenidən nömrələmənin lazımsız olduğuna söz verməzdən əvvəl səyi buna uyğun ölçün.

Öhdəlik götürməzdən əvvəl üç yoxlama

Birincisi, müştəri tətbiqini təsdiqləyin. Community OpenVPN bu seçimi dəstəkləyir; OpenVPN 3 kod bazası onu dəstəklənməyən xüsusiyyətlər arasında sadalayır, buna görə Connect tipli müştəriyə göndərilən profil onu sadəcə laqeyd edə bilər. Qəbul edilən və heç vaxt tətbiq olunmayan direktiv xətadan daha pisdir, çünki tunel sağlam görünür.

İkincisi, marşrutu və tərcüməni qısa bir diaqnostik pəncərədə yüksək detallıqla ayrı-ayrılıqda yoxlayın, sonra ping əvəzinə faktiki xidməti sınayın. Üçüncüsü, yerli marşrutlaşdırıcının və uzaq resursun müştəridən fərqləndirilə bildiyini təsdiqləyin, çünki ilkin məqsəd bu idi.

Müştəri tərcüməni edə bilmirsə, şlüz tərəfindən kömək istəyin və ya yenidən nömrələməni qəbul edin. Eyni ünvan üçün daha çox marşrut əlavə etmək dizayn deyil.