Перехід із VPN на основі PPP без копіювання його припущень

Міграція VPN завершена, коли користувачі, призначення, розв'язання імен і поведінка під час збою все ще правильні, а не коли новий клієнт показує зелений значок. Старі розгортання на основі PPP несуть припущення, які ніколи не записували: спільний секрет, що був також єдиною перевіркою особи, фіксований пул адрес, який міжмережевий екран тримає в списку дозволених, і DNS-суфікс, який надсилає сервер. Заміна протоколу без інвентаризації цих припущень дає тунель, що виконує рукостиск, і межу, якої не існує. Порядок нижче — той, який використовую я, а останній крок — той, який команди пропускають.

Крок 1: проінвентаризуйте, що дає старе з'єднання

Інвентаризація пишеться, а не запам'ятовується. Запишіть підтримувані клієнти, ролі автентифікації, пули адрес, захищені мережі, вимоги до DNS і дозволи на сервіси, потрібні кожній групі користувачів.

Для L2TP/IPsec явно розділіть два шари. Ідентичність партнера IPsec автентифікує машини; PPP автентифікує користувача, зазвичай через CHAP або MSCHAPv2.

Саме в цьому розділенні старі розгортання ховають свої припущення. Спільний попередньо розподілений ключ, який використовує кожен клієнт, автентифікує групу, а не пристрій, і часто це єдине, що колись змінювали. Якщо обліковий запис PPP — це справжній контроль на користувача, скажіть про це, бо заміна мусить відтворити цей контроль чимось, що не є спільним рядком. Запишіть також фіксовані адреси джерела й винятки для локальної мережі, бо це залежності, які ніхто не документує, доки вони не зламаються.

Крок 2: свідомо спроєктуйте заміну

Вибір заміни — це зіставлення вимога за вимогою: протокол і клієнт, який підтримується організацією, причому кожна вимога до ідентичності й доступу потрапляє в реальний механізм. Спільний секрет не дорівнює автоматично ключу чи сертифікату на пристрій, а обліковий запис PPP на користувача не дорівнює сертифікату пристрою.

Узгодьте діапазони адрес перед усім іншим, бо замінний пул, що перекривається з домашньою або офісною локальною мережею, створює збій, який не має нічого спільного зі стійкістю шифру. Перевірте пул за тим самим списком, який ви склали для старого сервісу, плюс те, що новий клієнт припускає за замовчуванням. Підтвердьте зворотну маршрутизацію для захищених мереж і підтвердьте, що новий клієнт може передавати або документувати DNS-суфікс, який передавав старий. Ці два пункти дають більше заявок на міграцію, ніж сама зміна протоколу.

Крок 3: впроваджуйте поетапно й перевірте і дозвіл, і заборону

Впроваджуйте з одним представницьким користувачем і одним представницьким застосунком. Включіть у тест розв'язання приватних імен через DNS, бо тунель, що досягає адреси, але не може розв'язати внутрішнє ім'я, мігровано лише наполовину. Включіть і очікуваний стан недоступності: що має статися, коли тунель падає, і чи клієнт це забезпечує.

Далі перевірте призначення, яке має лишитися забороненим. Широке тимчасове правило дозволу може зробити новий тунель зовні здоровим, водночас тихо прибираючи межу авторизації, яку забезпечував старий сервіс, і ніхто не помічає до аудиту. Порівняйте результати дозволу й заборони поруч, з одного клієнта, в одній сесії. Тримайте старий сервіс працюючим, доки обидва стовпці не збіжаться з проєктом.

Перш ніж переносити адміністративний доступ, підтвердьте, що у вас є дозволений шлях відновлення, який не залежить від тунелю, який ви змінюєте.

Крок 4: виведіть стару ідентичність з експлуатації

Правильне виведення старої ідентичності означає відкликання застарілих користувачів і облікових даних пристроїв через сервіс, якому вони належать, а потім видалення старих профілів і слухачів, коли залежностей не лишається. Видалення локального файлу не відкликає копію в іншому місці, а старий слухач, що досі приймає старий спільний секрет, — це двері без нагляду.

На цьому моменті варто сповільнитися. Виведений з експлуатації профіль клієнта на ноутбуці — не відкликані облікові дані; дані живуть на сервері й лишаються чинними, доки сервер не перестане їх приймати. Шукайте інші копії старої конфігурації — тестові пристрої, забутий телефон, інсталятор, який хтось зберіг, — і вважайте вимкнення слухача моментом, коли старий сервіс справді закінчується. До того часу в міграції двоє передніх дверей.

Запис приймання — це інвентаризація з першого кроку з доданим стовпцем: що новий проєкт робить для кожного рядка і як ви це перевірили. Це перетворює оновлення протоколу на вимогу до сервісу з доказами.

Тримайте результат прив'язаним до того, що потрібно сервісу, а не до назви протоколу, бо сучасний протокол зі скопійованими старими припущеннями — той самий ризик у кращій рамці. RFC 3193 описує, як L2TP передається через IPsec, що є корисною нагадкою: ці два шари завжди були окремими рішеннями. Якщо в інвентаризації є рядок, який ви не можете пояснити, зупиніться і з'ясуйте, що від нього залежить. Міграція завершена, коли список стає нудним.