OpenVPN serveri nopool: açıq hovuz aralığını elan edin

Server köməkçiləri alt şəbəkəni qurur və sonra onu öz seçdikləri dinamik hovuzla doldurur. Bu standart, bəzi ünvanlar bölgüdən kənarda qalmalı olana qədər rahatdır — istər sabit təyinatlar üçün saxlanılsın, istərsə də gələcək seqment üçün gözlədilsin. Avtomatik hovuzu söndürmək və aralığı özünüz elan etmək iki sətir və bölgü üçün olmayan ünvanlarla bağlı bir şüurlu qərar tələb edir. Qalanı əməliyyat intizamıdır: inventarlaşdır, tətbiq et, yoxla, geri qaytar.

Bu, işləyən xidmətə dəyişiklikdir, ona görə də ona əməliyyat tapşırığı kimi yanaşın: əvvəlcə inventar, sonra adi həyat dövrü ilə tətbiq, təzə müştəri ilə yoxlama və geri qaytarma imkanı.

Artıq malik olduğunuz alt şəbəkədən başlayın

Cari server konfiqurasiyasını və müştərilərin həqiqətən saxladığı ünvanları oxuyun. Hovuz dəyişikliyi yalnız bu baza nisbətən məna kəsb edir və baza həmişə faylın təklif etdiyi şey deyil, çünki idarə olunan məhsul və ya konfiqurasiya generatoru oxuduğunuz faylın sahibi ola bilər.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Qüvvədə olan topologiyanı təsdiqləyin. Alt şəbəkə topologiyasında hər müştəri hovuzdan bir ünvan götürür; köhnə net30 sxemləri hər müştəri üçün kiçik blok ayırır və hesab tamamilə başqadır. Server hələ net30-dadırsa, bu səhifə yanlış miqrasiya təlimatıdır və hovuz rəqəmləri gözlədiyiniz mənanı verməyəcək. Ünvan hesabını başqa yerdən köçürməzdən əvvəl o sətri yoxlayın.

Serverin öz ünvanını, müştəri konfiqurasiyası qovluğundakı hər sabit təyinatı və marşrutun və ya giriş qaydasının asılı olduğu hər ünvanı yazın. Dinamik aralıqdan kənarda qalmalı olan ünvanlar bunlardır. Onları əvvəlcə yazmaq aralığı təxmin deyil, qərar edir. Bu həm də geri qaytarmaya bərpa üçün konkret bir şey verir.

nopool əlavə edin və aralığı elan edin

Köməkçi açar sözü nopool qəbul edir; bu, alt şəbəkə konfiqurasiyasını saxlayır və avtomatik dinamik hovuzu söndürür, OpenVPN 2.6 təlimatında təsvir olunduğu kimi. Sonra açıq ifconfig-pool sətri nəzərdə tutduğunuz daxil olan aralığı verir və onun netmaskı alt şəbəkə ilə uyğundur. Hər iki sətir eyni server blokuna aiddir, çünki alt şəbəkəsi olmayan hovuzun mənası yoxdur. Aralarındakı sıra yalnız oxunaqlıq üçün vacibdir, çünki köməkçi xidmət başlayanda cütü genişləndirir.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Hər iki sərhəd daxildir, yəni nümunə yetmiş bir ünvan təklif edir. Server ünvanını və hər sabit təyinatı bu aralıqdan kənarda saxlayın; dinamik aralığın içərisinə düşən sabit təyinat qoşulma sırasından asılı olan toqquşma yaradır ki, bu da sazlamaq üçün ən pis növdür. Sabit təyinatların artma ehtimalı varsa, ayrılmış dəstlə aralıq arasında marja saxlayın.

Aralığın ölçüsü və paralellik ayrı məhdudiyyətlərdir. Yüz ünvan, max-clients başqa cür demirsə, yüz eyni vaxtlı müştəri demək deyil və paralellik həddindən böyük hovuz israf deyil, normaldır. Vacib olan odur ki, iki məhdudiyyət standartdan miras alınmayaraq şüurlu seçilsin.

Sabit təyinatları dinamik aralıqdan kənarda saxlayın

Müştəriyə xas ifconfig-push hovuz bölgüsündən fərqli mexanizmdir və aktiv topologiyaya uyğun parametrlər işlətməlidir. Alt şəbəkə rejimində bu, tək ünvan və netmaskdır; köhnə nümunədə göründüyü üçün net30 cütünü köçürmək geniş yayılmış səhvdir.

Bölgü tarixçəsi işarədir, səlahiyyət deyil. Persist faylı hansı müştərinin hansı ünvana sahib olduğunu xatırlayır, ona görə yenidən qoşulan müştərilər çox vaxt eyni ünvanı alır və o, ünvanları ayırmır, azad etmir və sabit təyinatı əvəz etmir. Müəyyən cihaz həmişə müəyyən ünvana sahib olmalıdırsa, persist faylına güvənmək əvəzinə sabit təyinat istifadə edin.

Sonra ünvanlardan asılı olan yolları yoxlayın. Müştərilərə ötürülən marşrut, alt şəbəkəyə icazə verən firewall qaydası və ya müəyyən hostu gözləyən monitorinq yoxlaması köhnə aralığı güman edə bilər. Onları oxumadan hovuzu dəyişmək nasazlığı əlaqəsiz görünən yerə köçürür.

Həyat dövrü ilə tətbiq edin, sonra yoxlayın

Dəyişikliyi xidmətin konfiqurasiyanı adi qəbul etdiyi üsulla tətbiq edin; istər birbaşa fayl və yenidən başlatma, istərsə də faylı yenidən yaradan idarəetmə qatı olsun. Yaradılmış fayla əl ilə düzəliş növbəti yaradılışa qədər yaşayır, daha çox deyil. Faylın hansı mexanizmə aid olduğunu qeyd edin, çünki növbəti operator eyni dəyişikliyi harada etməli olduğunu bilməli olacaq. Sonra bir dəfə yenidən başladın və müştəri dəvət etməzdən əvvəl jurnalı oxuyun.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Əvvəllər qoşulmamış müştərini qoşun və ünvanın elan edilmiş aralığın içində, ayrılmış dəstin xaricində olduğunu təsdiqləyin. Sonra geri yolu təsdiqləyin: müştəri siyasətin icazə verdiyinə çatmalı, daha çoxuna yox. Plana uyğun olub işlək marşrutu olmayan ünvan uğurlu dəyişiklik deyil.

Köhnə aralıqdan ünvana sahib olmuş müştərini yenidən qoşun. O, yeni aralıqdan ünvan almalı və köhnə ünvana bağlı istənilən sessiya səviyyəli vəziyyət yox olmalıdır. Əgər köhnə ünvanı saxlayırsa, onu başqa bir şey təyin edir və hovuz sizin düşündüyünüz sahib deyil.

Aralıq dəyişikliyini geri qaytarmaq

Dəyişiklik qeydinizdə əvvəlki üç sətri saxlayın, təkcə əvvəlki faylı yox. Onları bərpa edib yenidən başlatmaq bölgünü köhnə davranışa qaytarır və sonra yenidən qoşulan müştərilər oradan ünvan alacaq.

Qeydə iki xəbərdarlıq aiddir. Geri qaytararkən artıq qoşulmuş müştərilər yenidən qoşulana qədər mövcud ünvanlarını saxlayır, yəni geri qaytarma bütün park üzrə ani deyil. Və köhnə aralıq sabit təyinatla üst-üstə düşürdüsə, onu bərpa etmək toqquşmanı da bərpa edir; o üst-üstə düşmə dəyişikliyin səbəbidir və geri qaytarmadan fərqli bir həll tələb edir.

Hovuz dəyişikliyi təzə müştəri aralıq daxilində ünvan aldıqda, ayrılmış ünvan heç vaxt verilmədikdə və bu ünvanları istifadə edən marşrutlar və qaydalar nəzərdə tutulduğu kimi davrandıqda bitmiş sayılır. Bundan azı növbəti şəxsin üçündən hansının doğru olmadığını kəşf etməsinə imkan verir.