İki serverdə bir VPN hesabı: üç vəziyyət dəftəri

İki VPN düyünündən hər hansı birinə daxil ola bilən bir hesab, proqram təminatı sualından çox əvvəl dizayn sualı doğurur. Hesab görünüşü, hər düyünün sahib olduğu şəbəkə və qoşulmuş müştərinin saxladığı sessiya üç fərqli vəziyyət növüdür və siz onları bir yerdən digərinə köçürdükdə fərqli şəkildə sıradan çıxırlar. Hər üçünü bir sistemə köçürmək onlardan birini itirməyin geniş yayılmış yoludur.

Aşağıdakı üç dəftəri ardıcıllıqla işləyin. Hər biri nəyin səlahiyyətli, nəyin yerli olduğunu və digər düyün olmadıqda nə baş verdiyini soruşur, cavablar isə bir-birindən irəli gəlmir.

Kim qoşula bilər: bir səlahiyyət, çoxlu düyün

Qəbul dəftərindən başlayın: hansı şəxsiyyət mənbəyi səlahiyyətlidir, hansı sertifikat verənlərə etibar edilir, hansı hesablar uyğundur, hansı ikinci amil tətbiq olunur və hər hesab nəyə çata bilər. Sonra hər düyünün dəyişiklikləri necə və nə qədər tez öyrəndiyini yazın.

Paylaşılan verilənlər bazası bu cavabın mümkün komponentlərindən biridir. O, hər aidiyyəti siyasətin orada yaşadığının və ya hər düyünün dəyişikliyi eyni anda tətbiq etdiyinin sübutu deyil. A düyünündə deaktiv edilmiş, lakin B düyünündə hələ qəbul olunan hesab, çıxış prosesinin bitmədiyini bildirir.

Səlahiyyət əlçatmaz olduqda düyünün nə edəcəyini qərarlaşdırın. Kəsinti zamanı keşlənmiş etimadnamələri qəbul etmək təhlükəsizlik xərci olan siyasət seçimidir, onları rədd etmək isə əlçatanlıq xərci olan siyasət seçimidir. Hər ikisi müdafiə oluna bilər; sənədləşdirilməməsi isə yox.

Verən səlahiyyətini hesab məlumatlarından ayrı saxlayın. Bir neçə şlüz, imzalama açarını saxlamadan eyni CA-ya etibar edə bilər və hər düyün yenə də öz server sertifikatına və öz müştəri tərəfli etibar əlaqəsinə ehtiyac duyur.

Düyünün sahib olduğu: ünvanlar və marşrutlar

İkinci dəftər hər düyünə yerlidir: dinləmə ünvanı, server kimliyi, ünvan hovuzu, xüsusi resurslara marşrutlar, həlledici siyasəti və trafikin internetə necə çıxdığı. Eyni hesab hər iki düyün tərəfindən təqdim oluna bilər, bu obyektlər isə fərqli qalır.

Qayıdış yolu unudulan hissədir. Əgər hər iki düyün ünvanları eyni hovuzdan paylarsa, xüsusi şəbəkə verilmiş müştərinin hansı düyünə məxsus olduğunu ayırd edə bilməz və cavab yanlış yerə göndərilə bilər. Fərqli hovuzlar da marşrut və icazələrə ehtiyac duyur, ona görə fərqli nömrə aralığı tam dizayn deyil.

Müştəriləri qəsdən bir düyünə yönləndirin. DNS seçimi, müştəri son nöqtə siyahıları və ön plan xidməti fərqli sağlamlıq və uğursuzluq keçidi davranışı olan fərqli mexanizmlərdir. Birini seçmək yaxşıdır; “yük balanslaşdırması”nı dizayn kimi qəbul etmək qayıdış yolunu və uğursuzluq davranışını qeyri-müəyyən qoyur.

Sənədləşdirilmiş məhsul nümunəsi burada kömək edir. Pritunl-un replikasiya sənədləri VPN şəbəkəsini hər replika üçün obyekt kimi qəbul edir və fərqli replikalardakı müştərilər bir-birinə çatmaq üçün əlavə marşrut və bağlantıya ehtiyac duyur. Bu məhsula xas bir tənzimləmədir, Community OpenVPN üçün resept deyil, lakin replika əlavə etməyin niyə yalnız hesab anbarını deyil, şəbəkəni də dəyişdiyini göstərir.

Sessiya nədir: sətir deyil, canlı vəziyyət

Üçüncü dəftər canlı sessiyadır. Qoşulmuş müştərinin onu qəbul edən düyündə protokol vəziyyəti və şəbəkə təyinatı var. Hesabın digər düyündə tanınması o düyünə sessiyanı, açarları və ya paketləri davam etdirmə imkanını vermir.

Düyün sıradan çıxdıqda nə baş verdiyini açıq deyin. Dəstəklənən nəticə digər düyünə yeni autentifikasiya və yeni ünvanla yenidən qoşulma ola bilər, bundan sonra tətbiq öz qaydası ilə bərpa olunur. Fasiləsiz ötürmə tələb olunursa, bu tələb verilənlər bazası replikasiyasından çıxarılan nəticə deyil, açıq tətbiq dəstəyi tələb edir. Cavabı növbətçi mühəndisin tapa biləcəyi yerə yazın.

Tutum qaydaları da eyni yanaşmanı tələb edir. Hesab başına iki eyni vaxtlı sessiya həddi yalnız o halda düyünlər arasında tətbiq oluna bilər ki, hansısa səlahiyyət tutulmuş yuvalara dair əlaqələndirilmiş görünüşə malik olsun. Düyün-yerli siyahılar və tarixi hesab qeydi bu görünüşü yaratmır.

Üç dəftərin sınaqdan keçirilməsi

Hər birini ayrıca sınayın. A düyünündən, sonra B düyünündən daxil olun və hər ikisinin gözlənilən ünvan aralıqları ilə uğur qazandığını təsdiqləyin. Bir şəxsiyyəti geri çəkin və yalnız təsadüfən sınadığınızı deyil, hər iki düyünü yoxlayın. Sonra bir düyünü dayandırın və müştərinin və xüsusi tətbiqin əslində nə etdiyini müşahidə edin.

Qəbul testinə qayıdış yolunu daxil edin. B-yə qoşulan, lakin A-nın arxasındakı resursdan cavab ala bilməyən müştəri qəbul yoxlamasını keçmiş və şəbəkə yoxlamasını uduzmuşdur, bu fərq hesabatda görünməlidir.

Çoxdüyünlü hesab dizaynı yalnız o zaman tamamlanır ki, hər üç dəftərin açıq sahibi, dəyişiklik yolu və uğursuzluq davranışı olsun. Konfiqurasiya faylını düyünlər arasında köçürmək bu sualların heç birinə cavab vermir.