Hər OpenVPN node-unda bir xidmət IP-si: bunun etmədiyi işlər

Müştəri bir neçə OpenVPN serverindən birinə qoşulur və sonra həmin node-da işləyən kiçik bir xidmətə ehtiyac duyur: status səhifəsi, metrika son nöqtəsi, ehtiyat nüsxə agenti. Hər node-a eyni özəl xidmət ünvanını vermək müştərinin konfiqurasiyasını hansı serverə düşdüyündən asılı olmayaraq eyni edir. Bu rahatlıq realdır və onu həddindən artıq oxumaq da asandır: ortaq ünvan sizə hansı node-a çatdığınızı deyir, nəyinsə artıq olduğunu deyil.

Niyə eyni ünvan hər node-da işləyir

Hər node ünvanı yerli olaraq saxlayır və onun adından cavab verir, buna görə cari tuneli vasitəsilə ona çatan müştəri xidməti həmin tunelin o biri ucunda alır. Node-lar arasında heç nə əlaqələndirilmir və heç bir trafik bir node-dan digərinə keçmir.

Ünvan replikasiya olunmuş deyil, təkrarlanan yerli etiketdir. Hər node yalnız özü üçün cavab verir və heç biri başqa node-dakı ünvan adından trafik yönləndirmir. Bir müştəri konfiqurasiyasını serverlər müstəqil qalarkən etibarlı saxlayan budur. Dizaynın node-lar arasında heç bir əlaqələndirməyə ehtiyac duymamasının səbəbi də budur.

Buna görə eyni konfiqurasiya aralarında marşrutlaşdırma protokolu olmadan hər serverdə işləyir. Dizaynın sağlamlıq barədə heç nə deməməsinin səbəbi də budur: ünvan qeyri-sağlam node-da da sağlam node-dakı kimi mövcuddur, çünki o, xidmətin faydalı olmasına deyil, host-a bağlıdır.

Onu tunelə deyil, loopback-ə təyin edin

Ünvanı loopback interfeysinə qoymaq onu hər hansı tunel cihazının ömründən ayırır, buna görə yenidən qoşulma və ya konfiqurasiyanın yenidən yüklənməsi onu silmir. Ünvan host mövcud olduqca mövcuddur.

Ünvan lo üzərindədirsə, bu filtr deyil. Xidmət yenə də onu dinləməlidir və host-un firewall-ı real gələn yolu yenə də qiymətləndirir, hansı ki tunel interfeysindən gəlir. Loopback-in yalnız yerli demək olduğunu düşünən hər kəs ya qanuni müştəriləri bloklayır, ya da nəzərdə tutmadığı nəyisə açıq qoyur.

Təyinatı hook-dan yenidən əlavə etmək əvəzinə host-un şəbəkə konfiqurasiyası vasitəsilə qalıcı edin. Quraşdırma hook-u tunelin qalxmadığı node-da işləməyəcək və xidmət ünvanı tunel fəaliyyətindən asılı olmamalıdır. Ünvanı distributivinizin sahib olduğu interfeys konfiqurasiyasına qoyun, sonra bir dəfə yenidən başladın və yoxlayın. Yenidən başlatma sonrakı konfiqurasiya dəyişikliyinə tab gətirən yeganə sınaqdır.

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

Bir marşrut göndərin və bir təyinat nəzərdə tutun

Müştəri ünvan üçün host marşrutuna ehtiyac duyur və bunu qoşulduğu server təqdim edir. Hər server eyni təyinatı təqdim etdiyi üçün müştəri yerini dəyişdikdə profil dəyişmir.

Xidməti günahlandırmadan əvvəl müştərinin nə quraşdırdığını yoxlayın.

ip route get 10.250.0.1

HTTP xidməti üçün ünvana bir ad və həmin ad üçün sertifikat verin. Ortaq IP bir kimlik deyil və o, TLS yoxlamasını aradan qaldırmır, həm də bir özəl açarı hər node-a köçürməyi əsaslandırmır. Ortaq ünvana çevrilən ad sertifikat məsələsini adi saxlayır və lazım olsa, hər node üçün ayrı kimlik saxlamağa imkan verir.

Ortaq ünvanın edə bilmədikləri

O, failover təmin etmir. Seçilmiş node ölərsə, ünvan da onunla ölür və müştəri başqa yerdə yenidən qoşulmalıdır.

O, canlı TCP sessiyasını köçürmür, çünki yeni bağlantı köhnəsi barədə heç bir məlumatı olmayan başqa host-da bitir.

O, sağlam node seçmir, yükü balanslaşdırmır və node-lar arasında məlumat sinxronlaşdırmır. Bunların hər biri öz uğursuzluq rejimləri olan ayrı mexanizmdir və ünvanlama hiyləsinin onları əhatə etdiyini iddia etmək sadə dizaynın dayanıqlıq üçün haqsız reputasiya qazanma yoludur. Eyni anda iki tunel aktivdirsə, təyinatın mənası qeyri-müəyyən olur, ona görə bir aktiv tunel fərziyyəsini açıq saxlayın.

Xidmət kimliyini adla birlikdə saxlayın

Ünvanın nə demək olduğunu yazın: o, müştərinin hazırda qoşulduğu node-dakı xidmətə çatır. Bu tək cümlə bu nümunənin cəlb etdiyi anlaşılmazlığın çoxunu qarşısını alır.

Sonra hissələri birlikdə sənədləşdirin: ünvan, onun yaşadığı interfeys, serverin göndərdiyi marşrut və xidmətin təqdim etdiyi ad və sertifikat. Gələcək oxucunun yoxlayacağı sıra ilə dörd kiçik fakt.

Tələb node-daxili xidmət üçün sabit təyinatdırsa, nümunə uyğundur və demək olar heç nəyə başa gəlmir.

Tələb əlçatanlıqdırsa, bir qat yuxarı qalxın: yük balanslayıcı, sağlamlıq yoxlamaları olan xidmət adı və ya node-u əvəz etməyi artıq bilən orkestrasiya sistemi.

Bunu erkən qərarlaşdırmaq ortaq ünvanı olduğu şey kimi saxlayır — rahat bir etiket, heç vaxt dizayn olunmadığı işi görməsi səssizcə gözlənilən komponent kimi deyil.