Filial internet provayderini dəyişir, fayl serveri isə öz ünvanını saxlayır. Bu nəticə marşrutlanmış sayt VPN-i üçün normaldır və tunelin son nöqtə ünvanını tətbiqin ünvanı hesab edən hər kəs üçün təəccüblüdür. İkisi dizaynın fərqli qatlarında yaşayır və yalnız biri yerini dəyişdi. Onları bir hesab etmək provayder miqrasiyasını yenidən nömrələmə layihəsinə çevirən şeydir.

Müstəqil hərəkət edən iki ünvan planı

Daxili plan tətbiqlərin istifadə etdiyi özəl ünvanları təsvir edir: filial serveri 10.55.8.20 ünvanında, ona marşrut verən baş qərargah prefiksi və geri dönüş marşrutu. Xarici plan isə iki şlüzün bir-birinə necə çatdığını təsvir edir: peer ünvanları, dinləmə portları və internet üzərindən yol.

Provayder dəyişikliyi xarici plana toxunur. Özlüyündə daxili planın dəyişməsini tələb etmir.

İki inventarı ayrı saxlamaq, tətbiq öz trafikini artıq şifrələdiyi halda belə overlay işə salmağın praktik səbəbidir. Overlay sizə xarici dəyişkənliyə tab gətirən sabit daxili topologiya verir. Tətbiq öz ünvanını, firewall qaydalarını və DNS qeydlərini saxlayır. Yalnız nəqliyyat qeydləri dəyişir və bu, daha kiçik bir baxışdır.

Xarici tunel daxili söhbəti daşıyır

Şlüz-şlüz tunelində xarici IP başlığı iki şlüzü ünvanlayır. Daxili başlıq isə hələ də faktiki tətbiq son nöqtələrini göstərir. RFC 7296-nın şlüz-şlüz təsviri bunu tunel son nöqtələri vasitəsilə trafik çatdıran adi marşrutlaşdırma kimi qəbul edir.

Bu səbəbdən filial serveri şlüzün ictimai ünvanı dəyişdiyi halda 10.55.8.20 ünvanını saxlaya bilir. Daxili paket provayderin ünvanını ümumiyyətlə ehtiva etmir.

Ayrılıq dizayn xassəsidir, avtomatik zəmanət deyil. Əvəzedici yuxarı bağlantı dəstəklənən tuneli qura bilmirsə və ya daxili marşrutlar yenidən quraşdırılmırsa, ünvanı dəyişməsə də tətbiq öz yolunu itirir.

Provayder keçidinin hələ də yoxlama siyahısı var

Xarici yoxlama siyahısında beş maddə var: peer ünvanı və ya saxlanılan ad, dinləyici və hər hansı yuxarı axın filtri, yolda tərcümə, gözlənilən peer kimliyi və digər şlüzün icazə verilən parametrləri. Hər biri təkbaşına uğursuz ola bilər. İnzibatçılığı daşıyan keçidi dəyişərkən ayrıca bərpa yolu saxlayın. Yuxarı bağlantı keçidi zamanı uzaqdan girişi kəsmək özünüzün yaratdığı kəsintidir.

Bundan sonra filial prefiksini, hər iki istiqamətdə marşrutu, qoruma siyasətini və bir real tətbiq axınını yoxlayın. Yeni autentifikasiya olunmuş tunel köhnə özəl alt şəbəkəyə yönələn marşrutu düzəltmir.

Başqa qoşulmuş saytla ünvan üst-üstə düşməsi ayrı planlaşdırma problemidir. Provayder dəyişikliyi onu yaratmır, lakin miqrasiya adətən onun üzə çıxdığı vaxtdır.

Nə sağ qalmır: ictimai mənbə və sessiyalar

Sabit özəl server ünvanı sabit ictimai mənbə deyil. Əgər gəzinti birbaşa yeni provayderdən çıxırsa, veb-saytlar yeni provayderə baxan ünvanı görür.

Həmin ünvanı sabit saxlamaq üçün öz mövcudluğu və siyasəti olan məqsədli çıxış dizaynı lazımdır. O, tunellə birlikdə pulsuz gəlmir.

Qurulmuş sessiyalar da yol dəyişikliyinə tab gətirmir. Tunel saniyələr içində yenidən qurula bilər və hələ də köhnə yola bərkidilmiş uzunmüddətli bağlantıları qırar. Keçidi yenidən qoşulmaların məqbul olduğu pəncərə üçün planlaşdırın. Konkret müştərilər və onların timeout-ları sınaqdan keçirilməyibsə, miqrasiyanın görünməz olacağını iddia etməyin.

Keçidi dörd yoxlama ilə təsdiqləyin

Dəyişiklikdən sonra dörd şeyi ardıcıl yoxlayın: tunel nəzərdə tutulan peer ilə qurulub, filial prefiksinə daxili marşrut mövcuddur, siyasət tətbiq axınına icazə verir və tətbiq cavab verir. Hər birinin öz əmri var.

Linux şlüzündə bu üçü həmin siyahının ortasını əhatə edir:

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Nəqliyyat ünvanlarını bir inventarda, tətbiq ünvanlarını digərində saxlayın. Yalnız həqiqətən yerini dəyişən qeydləri yeniləyin. Tunelin xarici ünvanı dəyişdiyi üçün daxili asılılıqları yenidən nömrələmək qaçıla bilən işdir.

Əlaqəli məqalələr