Cisco Secure Client Always-On: спершу розгорніть профіль

Налаштування на боці пристрою не можуть змусити незареєстрований ноутбук поводитися як керований кінцевий пристрій, і більшість впроваджень Always-On застрягають саме в цій прогалині. Cisco Secure Client застосовує політику через профіль, що лежить на машині, тому доставка цього профілю є частиною плану застосування, а не його деталлю. Пройдіть п'ять кроків нижче по черзі й зупиніться на першому, що не виконується, бо пізніший крок не може компенсувати попередню прогалину.

Перший крок: вирішіть, чи правило починається до входу

Always-On встановлює тунель після входу користувача, і документація постачальника прямо зазначає, що з'єднання не встановлюється, коли ніхто не входить. Якщо ваша вимога — тунель, що існує до екрана входу Windows, це неправильна функція, і жодне налаштування профілю цього не змінить. Попереднє розгортання профілю не перетворює поведінку після входу на поведінку до входу.

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

Якщо вимога — лише другий рядок, решта цієї сторінки все одно застосовна, але тест приймання дешевший.

Другий крок: підтвердьте, що профіль уже на кінцевому пристрої

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

Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn

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

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

Третій крок: свідомо виберіть поведінку при збої

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

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

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

Четвертий крок: визначте, що вважається довіреним

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

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

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

П'ятий крок: зробіть політику кінцевого пристрою важко скасовною

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

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

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