Міграція VPN: ліцензії, функції та політика в одному записі

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

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

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

Запис готовий, коли всі чотири стовпці заповнив той, хто має право їх заповнювати. Стовпець, підписаний не тим власником, — це чутка з датою.

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

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

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

Посібники із замовлення від постачальників показують, чому ці відмінності важливі. Наприклад, посібник із замовлення 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, що з’явився з одного боку й відсутній з іншого, — це знахідка, і її місце в записі з поясненням, а не в коментарі до тікета. Зберігайте і необроблені знімки, і відмінності, бо наступному перевіряльнику треба побачити, що саме порівнювали. У іншого постачальника еквівалент — власна таблиця сесій і експорт профілів цієї платформи, у форматі, який не збіжиться, тож порівнюйте запитання, поставлені їй, а не текст.

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

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

Приймайте з обох боків рішення

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

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

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