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