Saytlar arası VPN üzərində statik marşrutlar, yoxsa marşrutlaşdırma protokolu?

Hər iki variant saytlar arasında paket daşıyır, ona görə qərar hansı protokolun daha yeni olması ilə bağlı deyil və tunelin ölçüsü də bunu həll etmir. Üç şərt həll edir: nə qədər prefiks dəyişir və nə qədər tez-tez, dizayn yollar arasında avtomatik keçid tələb edirmi, və komanda gecə saat üçdə nə qədər idarəetmə səviyyəsi mexanizmini işlədə bilər. Bunlara səmimi cavab verin və seçim adətən öz-özünə yaranır. Bu məqalənin qalanı hər cavabın nəyə başa gəldiyidir.

Üç şərt qərarı verir

Birinci şərt dəyişkənlikdir. Aydın sahibliyi olan bir neçə sabit alt şəbəkə illərlə əl ilə saxlanıla bilər və hər marşrut kiminsə oxuyub yoxlaya biləcəyi bir sətir olaraq qalır. Layihələr gəlib getdikcə yer dəyişən onlarla prefiks başqa bir problemdir, çünki hər hərəkət köhnə yolu hələ də yadda saxlayan hər cihaza çatmalıdır.

İkincisi nasazlıq davranışıdır. Ehtiyat yol insan görmədən aktiv olmalı olduqda nəyinsə nasazlığı aşkar edib marşrutu geri çəkməsi lazımdır. Statik marşrutlaşdırma bunu yalnız izləmə və ya şərti quraşdırma ilə edə bilər və yalnız əvvəlcədən modelləşdirdiyiniz nasazlıqlar üçün.

Üçüncüsü ikinci idarəetmə səviyyəsinə iştahtır. Marşrutlaşdırma protokolu sessiyalar, autentifikasiya, filtrlər və seçim siyasəti əlavə edir və bunların hər biri monitorinq və dəyişiklik prosesi tələb edir. Bu birdəfəlik konfiqurasiya işi deyil, daimi əməliyyat xərcidir.

Üçüncü abzasın altındakı cədvəl qısa variantdır və ondan sonrakı üç bölmə hər sətrin niyə yerində olduğunu izah edir. Seçim etməzdən əvvəl sətirləri öz sayt sayınızla müqayisədə oxuyun, çünki əməliyyat xərcini nəzərə almayan qərar yalnız yarım qərardır.

Statik marşrutlaşdırma əslində nəyə başa gəlir

Statik marşrut tunelin hər iki tərəfində düzgün olmalıdır. Alt şəbəkə əlavə etmək uzaq şlüzü, yerli şlüzü və adətən geri dönüş yolunu redaktə etmək deməkdir və bunlardan hər hansı birini unutmaq tətbiq xətasına oxşayan birtərəfli nasazlıq yaradır. Tətbiq komandası gözləmə müddətləri görür, şəbəkə komandası isə mövcud və zahirən sağlam görünən marşrut görür. Heç bir komanda yanılmır və buna görə bu nasazlığın yerini tapmaq bu qədər uzun çəkir.

Statik qeyd altındakı yol yox olduqdan sonra da quraşdırılmış qalır. Platforma izləmə təqdim etmirsə, marşrut artıq ötürməyən növbəti hoppa işarə etməyə davam edir və trafik keçid etmək əvəzinə yox olur. O sükut sadə variantı seçəndə qəbul etdiyiniz xərcdir.

İzləmə üsulunu hər marşrutun yanında yazın, hansı nasazlıqları əhatə etdiyini qeyd edin və siyahını tunel konfiqurasiyası ilə birlikdə saxlayın. Əks halda növbəti kəsinti şəbəkə deyil, istifadəçi tərəfindən aşkar edilir və bu həmişə daha bahalı aşkardır.

Dinamik marşrutlaşdırma əslində nəyə başa gəlir

Protokol yeni prefiksləri elan edir, əlçatmaz olanları geri çəkir və yollar arasında üstünlük ifadə edir. Bu, bir neçə sayt və ya ehtiyat tunel hər dəyişiklikdə əlaqələndirilmiş redaktələrə ehtiyac duyanda həqiqətən faydalıdır. Bu, həm də protokolun sizi ən pis anda təəccübləndirməsinin səbəbidir. O hərəkətlərin hər biri şəxsən etmədiyiniz vəziyyət dəyişikliyidir.

Bir-biri ilə ziddiyyət təşkil edə bilən iki vəziyyət yaradır. Tunel yuxarıda, marşrutlaşdırma sessiyası aşağıda ola bilər və sessiya yuxarıda ola bilər, halbuki elanları tətbiqin ehtiyac duyduğu alt şəbəkəni buraxır. Hər ikisi yarım işləyən şəbəkə kimi görünür və heç biri tunel statusu səhifəsindən görünmür.

Buna görə filtrlər və siyasət sonradan düşünülən şey deyil, dizaynın hissəsinə çevrilir. Hər şeyi elan edən protokol nə vaxtsa səhv bir şey elan edəcək və səhv prefiks onu düzəldə bilən şəxsdən daha sürətli səyahət edir. Filtrləri ilk sessiya aktivləşməzdən əvvəl yazın ki, ilk elan artıq qəsdən olsun.

Marşrutlaşdırma sessiyasının nə deyə biləcəyini idarə edin

Hər peer üçün icazə verilən prefiks siyahısını müəyyən edin və girişdə tətbiq edin, çünki çıxış filtri peerin sizə standart marşrut göndərməsinin qarşısını ala bilməz. Standart marşrutlar və aqreqatlar burada bahalı səhvlərdir: qanuni görünən bir öyrənilmiş qeydlə əlaqəsiz yolları səssizcə əvəz edə bilərlər. Dizayn həqiqətən istəmirsə, onları açıq şəkildə rədd edin.

İlk sessiya qalxmazdan əvvəl hər şəbəkənin yanında sahib saytı yazın, çünki bu xəritələmə sənədləşmə bəzəyi deyil, filtr siyahısının mənbəyidir. Bu olmadan filtri redaktə edən şəxs prefiksi hansı saytın elan etməli olduğunu təxmin etməli olur.

İki protokol arasında yenidən bölüşdürmə döngələrin başladığı və eyni prefiksin təmiz müqayisə olunmayan atributlarla iki dəfə gəldiyi yerdir. Xüsusi tələb məcbur etməyincə yenidən bölüşdürməni dizayndan kənarda saxlayın və əgər olmalıdırsa, marşrutları sərhəddə işarələyin və filtrləyin.

Marşruta əsaslanan tunel interfeysləri dinamik marşrutlaşdırmanı təmsil etməyi asanlaşdırır, çünki tunel selektorlarla uyğunlaşan siyasət yerinə marşrutları olan interfeysə çevrilir. Bu, peer əhatəsi məsələsini aradan qaldırmır: IPsec selektorları hələ də yönləndirmək istədiyiniz trafikə icazə verməlidir.

Xoşbəxt yolu deyil, nasazlıq yolunu sınaqdan keçirin

Nə seçsəniz də, bir yuxarı kanalı söndürün və trafikin hərəkət etdiyini və ya qeyd etdiyiniz şəkildə uğursuz olduğunu təsdiqləyin. Yalnız hər iki yol sağlam ikən sınaqdan keçirilmiş dizayn ümumiyyətlə sınaqdan keçirilməmiş dizayndır. Aşkarlama vaxtını orada ölçün, çünki ölçdüyünüz rəqəm istifadəçilərin yaşayacağı rəqəmdir.

Sonra geri dönüş yolunu ayrıca təsdiqləyin, çünki VPN üzərində asimmetrik marşrutlaşdırma geniş yayılmışdır və vəziyyət saxlayan cihaz cavabları atana qədər görünməzdir. Bir istiqamətdə işləyən axın yolun yalnız yarısını sübut edir.

İş sırası: prefiksləri sayın, nasazlıqların necə aşkar edilməli olduğuna qərar verin, protokolu kimin işlədə biləcəyini yoxlayın, elan edilənləri idarə edin, sonra bir kəsişməni başdan sona sınaqdan keçirin. Hər addım növbəti addımın ehtiyac duyduğu bir fakt yaradır.