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

Четыре столбца, а не один контрольный список

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

Запись готова, когда все четыре столбца заполнил тот, кто имеет право их заполнять. Столбец, подписанный не тем владельцем, — это слух с датой.

Платформа и права

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

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

Руководства по заказу у поставщиков показывают, почему эти различия важны. Например, руководство по заказу Secure Client от Cisco разделяет уровни Advantage, Premier и VPN Only, у каждого своя мера и объём функций. Используйте текущее соглашение, а не переводите старую метку механически.

Функции и применяемая политика

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

Когда цель — ASA, столбец функций читается с самого устройства, а не из договора, поэтому зафиксируйте шлюз до дня переключения. show vpn-sessiondb summary даёт инвентарь активных сессий и числа, относительно которых измеряются ваши права, show vpn-sessiondb detail anyconnect показывает, какой тип клиента и профиль фактически использовала каждая отнесённая сессия, а show running-config webvpn фиксирует конфигурацию шлюза, от которой зависят эти сессии, и это единственная часть записи, которую не может содержать ни один лицензионный документ.

show vpn-sessiondb summary
show vpn-sessiondb detail anyconnect
show running-config webvpn

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

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

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

Принимайте по обе стороны решения

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

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

Попросите владельца подписать права и сопоставление политики вместе. Готовая запись отвечает сразу на два вопроса: что организация вправе развернуть и какие правила действительно допускают и ограничивают её пользователей.

Похожие статьи