Премин од VPN заснован на PPP без копирање на неговите претпоставки

Миграцијата на VPN е завршена кога корисниците, дестинациите, резолуцијата на имиња и однесувањето при дефект сѐ уште се точни, а не кога новиот клиент покажува зелена икона. Старите поставености засновани на PPP носат претпоставки што никогаш не биле запишани: заедничка тајна што воедно беше единствената проверка на идентитет, фиксен базен на адреси што ѕидот за заштита го држи на списокот дозволени, и DNS суфикс што го испраќа серверот. Замената на протоколот без попис на тие претпоставки дава тунел што го завршува ракувањето и граница што не постои. Редоследот подолу е тој што го користам јас, а последниот чекор е тој што тимовите го прескокнуваат.

Чекор 1: попишете што обезбедува старата врска

Пописот се пишува, а не се памти. Запишете ги поддржаните клиенти, улогите за автентикација, базените на адреси, заштитените мрежи, барањата за DNS и дозволите за услуги што ги бара секоја корисничка група.

За L2TP/IPsec, експлицитно одвојте ги двата слоја. Идентитетот на IPsec партнерот ги автентицира машините; PPP го автентицира корисникот, обично со CHAP или MSCHAPv2.

Токму во ова одвојување старите поставености ги кријат своите претпоставки. Заеднички претходно споделен клуч што го дели секој клиент автентицира група, а не уред, и често тоа е единственото нешто што некогаш било ротирано. Ако PPP сметката е вистинската контрола по корисник, кажете го тоа, бидејќи замената мора да ја репродуцира таа контрола со нешто што не е заедничка низа. Забележете ги и фиксните изворни адреси и исклучоците за локалната мрежа, бидејќи тоа се зависностите што никој не ги документира додека не се скршат.

Чекор 2: намерно проектирајте ја замената

Изборот на замена е мапирање барање по барање: протокол и одржуван клиент што организацијата ги поддржува, при што секое барање за идентитет и пристап завршува во вистински механизам. Заедничката тајна не е автоматски еднаква на клуч или сертификат по уред, а PPP сметката по корисник не е еднаква на сертификат за уред.

Усогласете ги адресните опсези пред сѐ друго, бидејќи заменски базен што се преклопува со домашна или канцелариска LAN создава дефект што нема врска со јачината на шифрата. Проверете го базенот спрема истиот список што го изградивте за старата услуга, плус тоа што новиот клиент го претпоставува по стандард. Потврдете го повратното рутирање за заштитените мрежи и потврдете дека новиот клиент може да го испрати или документира DNS суфиксот што го испраќаше стариот. Овие две ставки создаваат повеќе билети за миграција од самата промена на протоколот.

Чекор 3: воведувајте етапно и проверете и дозвола и забрана

Воведете со еден претставнички корисник и една претставничка апликација. Вклучете приватно DNS разрешување во тестот, бидејќи тунел што стигнува до адреса, но не може да го разреши внатрешното име, е само половина мигриран. Вклучете и очекуваната состојба на недостапност: што треба да се случи кога тунелот паѓа и дали клиентот тоа го спроведува.

Потоа тестирајте дестинација што треба да остане забранета. Широко привремено правило за дозвола може да го направи новиот тунел здрав, додека тивко ја отстранува границата за авторизација што ја спроведуваше старата услуга, и никој не забележува до ревизија. Споредете ги резултатите за дозвола и забрана еден до друг, од истиот клиент, во истата сесија. Држете ја старата услуга во работа додека двете колони не се поклопат со проектот.

Пред да го преместите администраторскиот пристап, потврдете дека имате овластен пат за враќање што не зависи од тунелот што го менувате.

Чекор 4: повлечете го стариот идентитет

Правилно повлекување на стариот идентитет значи отповикување на застарените корисници и акредитиви за уреди преку услугата што ги поседува, потоа отстранување на старите профили и слушатели кога не останува зависност. Бришењето локална датотека не отповикува копија на друго место, а стариот слушател што сѐ уште ја прифаќа старата заедничка тајна е врата без надзор.

Оваа точка заслужува да забавиме. Деактивиран клиентски профил на лаптоп не е отповикан акредитив; акредитивот живее на серверот и останува валиден додека серверот не престане да го прифаќа. Побарајте други копии од старата конфигурација — тест-уреди, заборавен телефон, инсталер што некој го чувал — и третирајте го гасењето на слушателот како момент кога старата услуга навистина завршува. Дотогаш миграцијата има две предни врати.

Записот за прифаќање е пописот од првиот чекор со додадена колона: што прави новиот проект за секој ред и како сте го провериле тоа. Тоа го претвора надградувањето на протокол во барање за услуга со докази.

Држете го исходот врзан за она што ѝ е потребно на услугата, а не за името на протоколот, бидејќи современ протокол со копирани стари претпоставки е истиот ризик со подобра рамка. RFC 3193 опишува како L2TP се пренесува преку IPsec, што е корисно потсетување дека двата слоја отсекогаш биле одделни одлуки. Ако пописот има ред што не можете да го објасните, запрете и откријте што зависи од него. Миграцијата е готова кога списокот е здодевен.