Bir OpenVPN mərkəzi, üç LAN: ünvan planı və iroute faylları

Üç özəl LAN bir mərkəzdə görüşə bilər və heç bir sahə digərinin daxilini öyrənməz, bütün dizayn isə dörd qısa konfiqurasiya qərarına dayanır. Onu işlədən ekzotik protokol xüsusiyyəti deyil, heç kimin təxmin etməli olmadığı ünvan planı və mərkəzə hər sahənin hansı prefiksə sahib olduğunu deyən müştəri üzrə marşrutlardır. Bunlardan birini səhv etsəniz, tunel yenə qalxır və məhz bu, nasazlığı çaşdırıcı edir.

Addımları sıra ilə keçin. Hər biri əvvəlki addımın planından asılıdır və heç biri yeni sertifikat orqanı tələb etmir.

Heç kimin təxmin etməli olmadığı planla başlayın

Konfiqurasiya faylına toxunmazdan əvvəl dörd bir-birini kəsməyən prefiks yazın: mərkəzin öz LAN-ı, hər sahənin LAN-ı və gəzən müştərilərə verilən hovuz. Bir-birini kəsməmə hər şeyi sadə saxlayır, çünki üst-üstə düşən aralıqlar marşrutlaşdırmanı ən uzun uyğunluq tapmacasına çevirir və müştəri üzrə heç bir konfiqurasiya bunu düzəltmir. Sonra hər LAN üçün hansı maşının defolt şlüz olduğunu təsdiqləyin, çünki öz LAN-ının şlüzü olmayan sahə marşrutlaşdırıcısı uzaq marşrutları tamamilə başqa yerdə quraşdırmalıdır. Nəhayət, hər sahəni identifikasiya edən autentifikasiya olunmuş adları müəyyənləşdirin, çünki müştəri üzrə fayllar məhz həmin adlarla axtarılır.

İllüstrativ plan hovuzu üç LAN-dan kifayət qədər uzaq saxlayır. Sizin planınız fərqli olacaq və yeganə sərt qayda odur ki, heç iki aralıq üst-üstə düşməsin.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Mərkəzin nüvəsinə sahələrin harada olduğunu deyin

Mərkəz hər sahə üçün iki məlumat parçasına ehtiyac duyur: prefiksi tunel cihazına göndərən nüvə marşrutu və iroute yazısı, hansı ki OpenVPN prosesinə hansı müştərinin ona sahib olduğunu deyir. Tək nüvə marşrutu paketləri tunelə çatdırır və orada dayanır, çünki demon hələ də onları hansı həmsöhbətin alacağına qərar verməlidir. Tək iroute yazısı isə həmin paketləri nüvədə marşrutsuz qoyur. Hər iki sətir demonun həqiqətən yüklədiyi konfiqurasiyaya aiddir və başqa bir şeyi sazlamazdan əvvəl bunu yoxlamağa dəyər.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Nüvə icra nöqtəsi olmalıdırsa, müştəridən müştəriyə əlaqəni söndürün. Bu seçim həmsöhbət trafikini demonun içində ötürür, bu rahatdır və həm də o deməkdir ki, yönləndirmə qaydalarınız axını heç vaxt görmür. Aşağıdakı hər şey nüvənin hər sahədən sahəyə paketi gördüyünü fərz edir.

Hər sahəyə lazım olan marşrutları verin

Hər sahəyə digər sahələr və mərkəzin LAN-ı üçün marşrutlar lazımdır, öz qoşulmuş LAN-ı üçün isə lazım deyil. Uzaq prefiksləri hər marşrutlaşdırıcıya yapışdırmaq əvəzinə mərkəzdən göndərin, belə ki sonradan dördüncü sahə dörd düzəliş yerinə bir yeni müştəri üzrə fayl demək olsun. Müştəri üzrə fayl həm də iroute sətrini daşıyır və bu, sahibliyi və elanı eyni yerdə saxlayır. Qovluğu və fayllarını serverin imtiyaz modelinə uyğun oxunaqlı edin, əks halda axtarış mesajsız uğursuz olur.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Dördüncü sahə eyni nümunəni izləyir: fərqli autentifikasiya olunmuş ad, sahibi olan prefiks, mərkəz nüvəsində marşrut, iroute yazısı və yalnız ona çatmağa icazə verilmiş sahələrə elanlar.

Bitmiş saymazdan əvvəl hər iki istiqamətdə sınaqdan keçirin

Üç marşrutlaşdırıcının hamısında IPv4 yönləndirməsini aktivləşdirin, sonra firevorun nəzərdə tutulan axınlara hər iki istiqamətdə icazə verdiyini təsdiqləyin, çünki birtərəfli sınaq pozulmuş geri dönüş yolu ilə gözləniləndən daha çox keçir. Sahələr arasında mənbə tərcüməsi lazım deyil və orijinal mənbəyin qorunması hər sahəyə öz siyasətini sorğuya tətbiq etməyə imkan verir.

Bir sahə LAN-ındakı hostdan digərindəki xidmətə sınaq edin, sonra istiqaməti tərsinə çevirin, sonra sahədən mərkəzin LAN-ına sınaq edin. Bu üç nəticə fərqli dəlillərdir və heç biri digərlərini nəzərdə tutmur. Əgər sahə marşrutlaşdırıcısı öz LAN-ının defolt şlüzü deyilsə, uzaq prefiksləri həqiqi şlüzə quraşdırın və tunel müştəriləri həmin LAN-a bağlantı başlatmalı olduqda hovuzu da əlavə edin.

Planı, müştəri üzrə faylları və firevor qaydalarını bir sənəd kimi qeyd edin, çünki növbəti sahə əlavəsi onlarla ölçüləcək.

Dizayn bütöv qalır, çünki hər təbəqənin bir işi var: plan prefiksləri unikal saxlayır, nüvə marşrutu paketləri hərəkət etdirir, iroute sahibi adlandırır və firevor nəyə icazə verildiyini qərar verir. Nəsə pozulduqda, həmin siyahı onu yoxlamaq sırasıdır da.