PPP əsaslı VPN-dən onun fərziyyələrini köçürmədən miqrasiya

VPN miqrasiyası istifadəçilər, təyinatlar, ad həlli və nasazlıq davranışı hələ də düzgün olduqda tamamlanır, yeni müştəri yaşıl ikon göstərdikdə deyil. Köhnə PPP əsaslı yerləşdirmələr heç vaxt yazılmamış fərziyyələr daşıyır: yeganə kimlik yoxlaması kimi çıxış edən ortaq sirr, firewall-un icazə siyahısına saldığı sabit ünvan hovuzu, serverin ötürdüyü DNS şəkilçisi. Protokolu həmin fərziyyələri inventarlaşdırmadan dəyişmək əl sıxışmanı tamamlayan tunel və mövcud olmayan sərhəd yaradır. Aşağıdakı gedişat mənim istifadə etdiyim sıradır və son addım komandaların atladığı addımdır.

Addım 1: köhnə bağlantının nə təmin etdiyini inventarlaşdır

İnventar yadda saxlanılmır, yazılır. Dəstəklənən müştəriləri, autentifikasiya rollarını, ünvan hovuzlarını, qorunan şəbəkələri, DNS tələblərini və hər istifadəçi qrupunun ehtiyac duyduğu xidmət icazələrini qeyd edin.

L2TP/IPsec üçün iki təbəqəni açıq şəkildə ayırın. IPsec həmkarının kimliyi maşınları autentifikasiya edir; PPP isə istifadəçini, adətən CHAP və ya MSCHAPv2 ilə autentifikasiya edir.

Köhnə yerləşdirmələr fərziyyələrini məhz bu ayrımda gizlədir. Hər müştərinin paylaşdığı ilkin ortaq açar qurğunu deyil, qrupu autentifikasiya edir və çox vaxt heç vaxt rotasiya olunmayan yeganə şeydir. PPP hesabı real istifadəçi-başına nəzarətdirsə, bunu deyin, çünki əvəzləmə həmin nəzarəti ortaq sətir olmayan bir şeylə bərpa etməlidir. Sabit mənbə ünvanlarını və yerli şəbəkə istisnalarını da qeyd edin, çünki bunlar heç kimin qırılana qədər sənədləşdirmədiyi asılılıqlardır.

Addım 2: əvəzləməni qəsdən layihələndirin

Əvəzləməni seçmək tələb-tələb uyğunlaşdırmasıdır: təşkilatın dəstəklədiyi protokol və saxlanılan müştəri, hər kimlik və giriş tələbi isə real mexanizmə düşür. Ortaq sirr avtomatik olaraq qurğu-başına açara və ya sertifikata bərabər deyil, istifadəçi-başına PPP hesabı isə qurğu sertifikatına bərabər deyil.

Ünvan diapazonlarını hər şeydən əvvəl əlaqələndirin, çünki ev və ya ofis LAN-ı ilə üst-üstə düşən əvəz hovuzu şifrə gücü ilə heç bir əlaqəsi olmayan nasazlıq yaradır. Hovuzu köhnə xidmət üçün qurduğunuz eyni siyahıya, üstəlik yeni müştərinin standart olaraq fərz etdiklərinə qarşı yoxlayın. Qorunan şəbəkələr üçün geri marşrutu təsdiqləyin və yeni müştərinin köhnənin ötürdüyü DNS şəkilçisini ötürə və ya sənədləşdirə bildiyini təsdiqləyin. Bu iki maddə protokol dəyişikliyindən daha çox miqrasiya bileti yaradır.

Addım 3: mərhələli tətbiq edin və həm icazəni, həm qadağanı yoxlayın

Bir nümayəndə istifadəçi və bir nümayəndə tətbiqlə mərhələli keçin. Testə özəl DNS həllini daxil edin, çünki ünvana çatan, lakin daxili adı həll edə bilməyən tunel yalnız yarı miqrasiya olunmuşdur. Gözlənilən əlçatmaz vəziyyəti də daxil edin: tunel düşəndə nə baş verməlidir və müştəri bunu tətbiq edirmi.

Sonra qadağan olunmuş qalmalı bir təyinatı sınayın. Geniş müvəqqəti icazə qaydası yeni tuneli sağlam göstərə bilər, halbuki köhnə xidmətin tətbiq etdiyi avtorizasiya sərhədini səssizcə aradan qaldırır və bunu auditə qədər heç kim görmür. İcazə və qadağan nəticələrini yan-yana, eyni müştəridən, eyni sessiyada müqayisə edin. Hər iki sütun layihəyə uyğun gələnə qədər köhnə xidməti işlək saxlayın.

Administrator girişini köçürməzdən əvvəl dəyişdirdiyiniz tuneldən asılı olmayan icazəli bərpa yolu olduğunu təsdiqləyin.

Addım 4: köhnə kimliyi təqaüdə çıxarın

Köhnə kimliyi düzgün təqaüdə çıxarmaq köhnəlmiş istifadəçiləri və qurğu etimadnamələrini onlara sahib olan xidmət vasitəsilə ləğv etmək, sonra heç bir asılılıq qalmadıqda köhnə profilləri və dinləyiciləri silmək deməkdir. Lokal faylın silinməsi başqa yerdəki kopyanı ləğv etmir və köhnə ortaq sirri hələ də qəbul edən köhnə dinləyici nəzarətsiz qapıdır.

Bu məqam üçün yavaşlamağa dəyər. Noutbukdakı ləğv edilmiş müştəri profili ləğv olunmuş etimadnamə deyil; etimadnamə serverdə yaşayır və server onu qəbul etməyi dayandırana qədər etibarlı qalır. Köhnə konfiqurasiyanın başqa kopyalarını axtarın — test qurğuları, unudulmuş telefon, kimsənin saxladığı quraşdırıcı — və dinləyicinin söndürülməsini köhnə xidmətin həqiqətən bitdiyi an kimi qəbul edin. O vaxta qədər miqrasiyanın iki ön qapısı var.

Qəbul qeydi addım birdəki inventardır, üstünə bir sütun əlavə olunur: yeni layihə hər sətir üçün nə edir və siz bunu necə yoxlamısınız. Bu, protokol yüksəltməsini sübutlu xidmət tələbinə çevirir.

Nəticəni protokol adına deyil, xidmətin ehtiyacına bağlı saxlayın, çünki köhnə fərziyyələr köçürülmüş müasir protokol daha yaxşı çərçivəli eyni riskdir. RFC 3193 L2TP-nin IPsec üzərində necə daşındığını təsvir edir ki, bu da iki təbəqənin həmişə ayrı qərarlar olduğunu xatırladan faydalı bir qeyddir. İnventarda izah edə bilmədiyiniz sətir varsa, dayanın və nəyin ondan asılı olduğunu öyrənin. Miqrasiya siyahı darıxdırıcı olanda tamamlanır.