Прелазак са 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-а, што је користан подсетник да су та два слоја одувек била одвојене одлуке. Ако попис има ред који не можете да објасните, зауставите се и откријте шта о њему зависи. Миграција је готова када списак постане досадан.