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

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

Шаг 1: проинвентаризируйте, что даёт старое подключение

Инвентаризация пишется, а не запоминается. Запишите поддерживаемые клиенты, роли аутентификации, пулы адресов, защищённые сети, требования к DNS и права на сервисы, которые нужны каждой группе пользователей.

Для L2TP/IPsec явно разделите два уровня. Идентичность партнёра IPsec аутентифицирует машины; PPP аутентифицирует пользователя, обычно через CHAP или MSCHAPv2.

Именно в этом разделении старые развёртывания прячут свои допущения. Общий предварительный ключ, который используют все клиенты, аутентифицирует группу, а не устройство, и часто это единственное, что когда-либо менялось. Если учётная запись PPP — это настоящий контроль на пользователя, скажите это, потому что замена должна воспроизвести такой контроль чем-то, что не является общей строкой. Запишите также фиксированные адреса источника и исключения для локальной сети, потому что это зависимости, которые никто не документирует, пока они не сломаются.

Шаг 2: осознанно спроектируйте замену

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

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

Шаг 3: внедряйте поэтапно и проверьте и разрешение, и запрет

Внедряйте с одним представительным пользователем и одним представительным приложением. Включите в тест разрешение частных имён через DNS, потому что туннель, который доходит до адреса, но не может разрешить внутреннее имя, мигрирован лишь наполовину. Включите и ожидаемое состояние недоступности: что должно произойти при падении туннеля и применяет ли это клиент.

Затем проверьте назначение, которое должно остаться запрещённым. Широкое временное правило разрешения может сделать новый туннель внешне здоровым, одновременно тихо убирая границу авторизации, которую обеспечивал старый сервис, и никто не замечает до аудита. Сравните результаты разрешения и запрета рядом, с одного клиента, в одной сессии. Держите старый сервис работающим, пока оба столбца не совпадут с проектом.

Прежде чем переносить административный доступ, подтвердите, что у вас есть разрешённый путь восстановления, не зависящий от туннеля, который вы меняете.

Шаг 4: выведите старую идентичность из эксплуатации

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

На этом моменте стоит замедлиться. Выведенный из эксплуатации профиль клиента на ноутбуке — не отозванные учётные данные; учётные данные живут на сервере и остаются действительными, пока сервер не перестанет их принимать. Ищите другие копии старой конфигурации — тестовые устройства, забытый телефон, установщик, который кто-то сохранил, — и считайте отключение слушателя моментом, когда старый сервис действительно заканчивается. До тех пор у миграции две входные двери.

Запись приёмки — это инвентаризация из первого шага с добавленным столбцом: что новый проект делает для каждой строки и как вы это проверили. Это превращает обновление протокола в требование к сервису с доказательствами.

Держите результат привязанным к тому, что нужно сервису, а не к названию протокола, потому что современный протокол со скопированными в него старыми допущениями — тот же риск с лучшей рамкой. RFC 3193 описывает, как L2TP передаётся поверх IPsec, что служит полезным напоминанием: эти два уровня всегда были отдельными решениями. Если в инвентаризации есть строка, которую вы не можете объяснить, остановитесь и выясните, что от неё зависит. Миграция завершена, когда список становится скучным.