Hub-and-spoke və ya tam mesh: hansı VPN topologiyası saytlarınıza uyğundur

İki filial ofisi bütün gün bir-biri ilə danışır və aralarındakı tunel başqa regiondakı data mərkəzindən keçərək uzanır. Hər sorğu bu sapma üçün iki dəfə ödəyir və fayl sinxronizasiyası qəribə görünməyə başlayana qədər heç kim bunu hiss etmir. Topologiya sualı məhz burada başlayır: hansı diaqramın daha dayanıqlı görünməsi ilə deyil, hansı trafik nümunəsi üçün pul ödədiyinizlə. Hər iki dizayn işləyir və onlar fərqli üsullarla, fərqli xərclərlə sıradan çıxır.

Hər şeydən əvvəl peer əlaqələrini sayın

N saytla tam mesh N çarpi N mənfi bir, ikiyə bölünmüş, tunel tələb edir; hub isə N tələb edir. Beş saytda bu, beşə qarşı on deməkdir və hələ idarə oluna bilən görünür. On beşdə isə on beşə qarşı 105 olur və fərq artıq hesab deyil, kadr məsələsidir.

Hər bir bu əlaqə sizin sahib olmalı olduğunuz vəziyyət daşıyır. IPsec-də bu, təhlükəsizlik assosiasiyası, kimlik, açar və ya sertifikat, ölü peer aşkarlanması və hər uzaq prefiks üçün ən azı bir marşrut deməkdir. WireGuard-da isə hər peer üçün açıq açar və AllowedIPs blok deməkdir; bu, hər peer üçün daha ucuzdur, lakin heç bir aşkarlama vermir: yeni sayt hər halda hər mövcud saytda konfiqurasiya dəyişikliyidir.

Qərarı trafik qarışığı versin, rəsm deyil

Filial trafiki əsasən mərkəzi ERP-yə və ya fayl klasterinə sorğulardırsa, hub güzəşt deyil, düzgün formadır: trafik artıq ora getmək istəyirdi və bir siyasət nöqtəsini yoxlamaq cütlük qaydalarından ibarət meshdən asandır. Mesh öz mürəkkəbliyini filiallar bir-biri ilə məlumat mübadiləsi edəndə qazanır — iki ofis arasında replikasiya, saytlar arasında səs, onlarla mühəndisin bütün gün açdığı CAD paylaşımı.

Narahat edici hallar ortada yerləşir və onlar çoxluqdur. Təşkilat sxemindən təxmin etmək əvəzinə mübahisədən əvvəl ölçün.

Cədvəli qayda deyil, həlledici kimi oxuyun. Dörd sətirdən üçünün bir tərəfə işarə etməsi adətən dizaynı həll edir; bölünmə hibrid deməkdir və yetkin şəbəkələrin çoxu onsuz da buna gəlir.

Huba yönləndirmə əmri verilməlidir

İki işləyən spoke-hub tuneli spoke-spoke girişi yaratmır. Hub IP yönləndirməsinin aktivləşdirilməsini, hər spoke şəbəkəsinə marşrut, tranzitə icazə verən firewall qaydası və geri yolun hesablanmasını tələb edir; hər spoke isə digər saytın prefiksləri üçün marşrut tələb edir. Linux hubda bu net.ipv4.ip_forward=1 üstəgəl FORWARD zənciri deməkdir ki, cütü səssizcə atmır; siyasət əsaslı IPsec-də isə hər iki tərəfdə uzaq spoke alt şəbəkəsini sadalayan trafik seçiciləridir. strongSwan-ın yönləndirmə qeydləri kernel və firewall tərəfini əhatə edir, əgər çatışmayan qat məhz budursa. Ucuz test: bir spokedən digərindəki xidmətə trafik göndərib hubun sayğaclarına baxmaqdır; heç artmayan qayda marşrutun deyil, sıranın səhv olduğunu göstərir.

Mərkəzi siyasət də faydalı hissədir. Filiallara bir-birinə çatmadan ümumi xidmətlərə çatmağa icazə vermək olar və bu giriş matrisini açıq şəkildə yazmağa dəyər. Çatışmayan marşrutlar kiminsə oxuya biləcəyi qayda üçün zəif əvəzedicidir.

Yarımçıq versiyaya diqqət edin: spoke A hubdan keçərək spoke B-yə marşrutlaşdırır, hub hər iki tərəfə marşrutlaşdırır və hubun firewallu A-dan yeni bağlantılara icazə verir, B-dən yox. Birinci istiqamət yaxşı sınaqdan keçir, ikincisi isə asılır — bu, marşrut nasazlığı kimi görünür və deyil.

Əvvəlcə nasazlığı, sonra normal yolu dizayn edin

Tək hub ortaq asılılıq və tranzit darboğazıdır və ehtiyatlılıq hub dizaynlarının adətən səhv getdiyi yerdir. İki hub hər spokun iki tunel saxlaması deməkdir və geri yol gediş yolu ilə uzlaşmalıdır; uzlaşmadıqda vəziyyətli firewall cavabları atır və simptom açılıb sonra ölən bağlantı olur. Daha böyük yerləşdirmələr bunu statik prefikslər əvəzinə tunellər üzərində marşrutlaşdırma protokolu ilə həll edir; bu daha çox maşın deməkdir, amma təxmini aradan qaldırır. Nə seçsəniz seçin, geri yolu gediş yolunun yanında yazın, çünki geri yarısını heç kim sınamır.

Mesh bu riski yayır: bir saytın keçidinin düşməsi digərlərini təcrid etmir. O, həm də yol seçiminin sizi təəccübləndirə biləcəyi yerləri çoxaldır və tətbiq sessiyaları hələ də kömək olmadan yol dəyişikliyindən sağ çıxmır.

Heç bir dizayn TCP sessiyasını özü failover boyunca canlı saxlamır. Tətbiq yenidən qoşula bilmirsə, topologiya sizin probleminiz deyil.

Dəyişiklik xərcinə görə seçin, sonra marşrutları yoxlayın

Hubdan başlayın, çünki səhv etmək üçün daha ucuz seçimdir, və trafiki buna haqq qazandıran cütlər üçün birbaşa tunellər əlavə edin. Bu hibrid qərar verməkdən imtina deyil; əksər təşkilatların bir il içində gəldiyi dizayndır. Vacib olan hər birbaşa keçidin bildirilmiş səbəbi və sahibinin olmasıdır.

Sonra bir deyil, iki rəsmi yoxlayın. Normal yol üçün, traceroute hər saytdan hər xidmət prefiksinə qədər və hoppaların diaqrama uyğun olduğunu təsdiqləyin. Nasazlıq yolu üçün bir tuneli bağlayın və təkrarlayın, çünki yalnız hər şey işləyəndə işləyən marşrut dizayn edilməyib, sadəcə konfiqurasiya edilib.

Hər iki rəsmi giriş matrisi ilə birlikdə saxlayın və sayt əlavə olunanda onlara yenidən baxın; idarə etdiyiniz xərc növbəti dəyişikliyin xərcidir, hazırkı mənzərənin zərifliyi deyil.