VPN müştəri ünvan hovuzunu uyğun şəkildə necə planlaşdırmaq olar

VPN serverindəki hovuz sahəsindən başlayın, cədvəldən yox. Ora yazdığınız hər şey sonradan qoşulan hər müştəri üçün daxili ünvan məkanına çevrilir və o, bu müştərilərin çatdığı LAN, arxasındakı marşrutlaşdırılmış saytlar və müştərinin evdə artıq saxladığı ünvanla birgə mövcud olmalıdır. Hovuz yadda saxlanılan kimi bir müştəri qoşun, çünki bu ilk qoşulma dəyərin praktikada işlədiyini sizə deyir. Oradan gəzinti xaricə doğru hərəkət edir: müştərinin aldığı ünvan, cavabın keçdiyi yol və arxada qoyduğunuz qeyd.

Hovuz sahəsindən başlayın, heç bir müştəri qoşulmadan əvvəl

Hər məhsul bunu fərqli şəkildə göstərir, ona görə ünvanları həqiqətən təyin edən obyekti tapın. OpenVPN-də növbəti boş ünvanı verən server tərəfli hovuz direktivi var, IKEv2 şlüzunda həmkar konfiqurasiyasına bağlanmış hovuz bölməsi var, WireGuard-da isə heç biri yoxdur, çünki hər həmkar öz ünvanını konfiqurasiya faylında daşıyır. Hovuz direktivi ilə hər həmkar üçün ayrıca ünvan bir-birini əvəz etmir və səhv olanı redaktə etmək gəzintinin qalan hissəsini boşa çıxarır.

Sahəni əldə etdikdən sonra artıq mövcud olan diapazonları sadalayın: ofis LAN-ı, hər marşrutlaşdırılmış sayt, bulud VPC-si və xidmətdə qalan hər hansı digər hovuz. Üst-üstə düşmə prefiks arifmetikası ilə həll olunur, host nömrələrinin tanış görünməsi ilə yox, ona görə aqreqatı həmin diapazonların hər biri ilə müqayisə edin. Hər ikisi 10.x kimi görünən iki diapazon, aqreqatları kəsişmədikdə zərərsiz, kəsişdikdə isə dəstək hadisəsidir.

Sonra ünvanın kimin qoşulduğundan, yoxsa nə vaxt qoşulduğundan asılı funksiya olduğuna qərar verin. Dinamik təyinat boş olanı verir, kimliyə görə təyinat isə sabit ünvanı etimadnaməyə bağlayır. Seçimi yazın, çünki bu, sonradan yenidən qoşulmanın necə görünməli olduğunu dəyişir.

Müştərinin həqiqətən aldığı ünvanı oxuyun

Bir müştəri qoşun və hovuzun vəd etdiyini deyil, tunelin bildirdiyini oxuyun. Müştəri daxili ünvanını qoşulma statusunda göstərir, Linux-da isə interfeys onu birbaşa daşıyır.

Bu ünvanı saxladığınız diapazonla müqayisə edin. Əgər diapazondan kənardadırsa, redaktə etdiyinizdən fərqli bir təyinat yoluna baxırsınız. Prefiks uzunluğunu da yoxlayın, çünki /32 saxlayan müştərinin bağlantı üzərində həmkarı yoxdur və hər təyinatı standart marşrutu ilə göndərir.

ip -4 addr show tun0
ip route get 192.168.50.20

Eyni diapazonu istifadə edən ev routerindən qoşulan müştəri qoşulacaq və sonra demək olar ki, heç nəyə çatmayacaq. Müştəri həmin prefiks üçün yerli marşrutunu saxlayır, ona görə tunel ünvanı arxasındakı şəbəkə ilə toqquşur və trafik səhv interfeysdən çıxır. Bu hal serverdə düzəldilə bilməz; sənədləşdirilmiş çarə ev şəbəkəsini yenidən nömrələmək və ya toqquşmaların nadir qalması üçün kifayət qədər uzaq hovuz diapazonu seçməkdir. Həm nasazlığı, həm də çarəni qeyd edin, çünki dəstək masası bununla yenidən qarşılaşacaq.

Eyni müştərini yenidən qoşun və ünvana baxın. Dinamik hovuz eyni dəyəri və ya fərqli birini qaytara bilər və hər ikisi düzgündür, ünvanı dəyişən kimliyə görə hovuz isə bağlamaya hörmət etmir. Bu yoxlama saniyələr çəkir və birinci bölmədə qeyd etdiyiniz rejimin qüvvədə olan rejim olub-olmadığını həll edir.

Xidmətdən cavabı geriyə izləyin

Hovuz yalnız cavablar ona geri qayıda bildikdə işləyir. LAN-dakı xidmət daxili ünvana cavab verir, ona görə onun şlüzuna hovuz üçün marşrut və ya xidmətin qarşısında translyasiya lazımdır. Sorğu tuneldən gəlib cavab fərqli yoldan çıxdıqda, vəziyyət saxlayan firewall və ya əks-marşrut yoxlaması onu atır və müştəri qoşulan, sonra isə donan bir xidmət görür. Hovuzu hər host üçün marşrutlar əlavə etmək əvəzinə marşrutlaşdırma dizaynına bir yekunlaşdırıla bilən blok kimi daxil edin.

Translyasiya sistemin qalan hissəsinin gördüyünü dəyişir. Mənbə yenidən yazıldıqda, host firewall-unda və tətbiq jurnalında olan ünvan translyasiya olunmuş ünvandır, ona görə hovuz ünvanına qarşı yazılmış qayda heç nəyə uyğun gəlmir və jurnal sətri müştəriyə qədər izlənə bilmir. strongSwan yönləndirmə sənədləşməsi IKEv2 şlüzü üçün həmin yolun server tərəfli yarısını əhatə edir. DNS eyni məhdudiyyəti daşıyır, çünki müştərinin çata bilmədiyi ünvana həll olunan ad sonra və başqa yerdə uğursuz olur.

İki müştəri, sonra bir ləğv

Eyni vaxtda iki müştəri qoşun və hər iki ünvanı oxuyun. Onlar fərqli, istifadə edilə bilən və hovuzun daxilində olmalı, hər biri nəzərdə tutulduğu xidmətə çatmalıdır. Təkrar ünvanlar verən hovuz adətən ilk tək-müştəri testində deyil, burada görünür.

Digər müştəri qoşulu qalarkən bir etimadnaməni ləğv edin, sonra sağ qalan müştəridən xidməti sınayın. Digər sessiyanı pozan ləğv paylaşılan vəziyyətə işarə edir, ən çox bir etimadnamə və ya cihazlar arasında təkrar istifadə olunan bir ünvan. Ləğv edilmiş müştərini yenidən qoşun və azad edilmiş ünvanın verilməsi əvəzinə rədd edildiyini təsdiqləyin.

Rədd edilməli olan bir təyinatla bitirin. Hər şeyə çatan müştəri qoşulmuşdur, sınaqdan keçirilməmişdir.

Dörd dəyəri növbəti dəyişikliyin onları tapacağı yerə yazın

Qeyd qısadır: hovuz diapazonu və prefiksi, təyinat rejimi, istifadədə olan qayıdış yolu və ya translyasiya, və həmin təyinatlar üçün cavab verən DNS əhatəsi. Onu biletdə deyil, server konfiqurasiyasının yanında saxlayın və tarix qoyun. Sonradan dördündən birini dəyişən hər kəs digər üçünü qarşısında görməlidir, çünki hovuzun ölçüsünün dəyişməsi marşrutu, marşrutun dəyişməsi isə DNS cavabını pozur.

Onunla birlikdə mülkiyyət qeydini saxlayın: tunel diapazonu VPN serverinə aiddir və LAN DHCP əhatəsində edilən rezervasiya tunelin içindəki müştəri üçün heç nə rezerv etmir. Bu tək sətir ən çox rast gəlinən yenidən işi qarşısını alır, burada kimsə rezervasiya əlavə edir və tunel ünvanının ona tabe olacağını gözləyir.