vpncli -s проти GUI: вхід у Cisco Secure Client
vpncli -s читає підготовлений файл відповідей, а GUI читає людину. Порівняйте, коли скрипт виправданий, що потрібно файлу і як це довести.
Cisco Secure Client дає два способи відповісти на ті самі запити входу: людина вводить текст у vpnui.exe або скрипт подає відповіді в vpncli.exe через стандартний ввід із -s. Другий уможливлює підключення за розкладом без зчитування екрана GUI і перетворює вхід на файл, який треба захищати як облікові дані. Що вибрати, залежить від того, чи є біля машини людина і як часто змінюється пароль. Жоден варіант не змінює того, що запитує шлюз, — лише те, хто відповідає.
Обидва шляхи закінчуються в одному тунелі, тому порівняння стосується експлуатації, а не протоколу.
Два способи відповісти на ті самі запити
Шлях через GUI інтерактивний за задумом: клієнт питає, хтось відповідає, і сеанс живе, доки ця людина його не чіпає. Це правильний вибір на ноутбуці, яким користується людина, бо запити підлаштовуються під метод автентифікації шлюзу і нікому не треба тримати пароль відкритим текстом на диску.
Шлях через скрипт підходить для кіоску, лабораторної машини або завдання за розкладом, де нема кому вводити. Обмін явний: ви приймаєте файл облікових даних на диску в обмін на підключення без нагляду. Якщо шлюз пропонує автентифікацію сертифікатом або SAML, такий обмін зазвичай не вартий, бо файл існує лише для відповідей на запити, яких уникнув би сильніший метод.
Не змішуйте обидва на одній машині одночасно. Командний рядок і графічний клієнт змагаються за один і той самий стан сеансу, і це проблема наступного розділу.
Що має містити файл відповідей
Клієнт питає по черзі — шлюз, іноді вибір групи, ім'я користувача, пароль і будь-яке підтвердження банера. Файл, що відповідає на все це, виглядає так, із підставленими справжніми значеннями:
connect vpn.example.com
MyGroup
alice
correct-horse-battery
yНадійний спосіб зібрати такий файл — один раз підключитися вручну, записати кожен введений рядок і кожне натискання Enter, а потім точно відтворити цю послідовність. Розгортання, які зберігають групу та ім'я користувача в профілі, можуть потребувати порожніх рядків там, де ці запити більше не з'являються, а останній рядок усе ще потребує власного переведення рядка. Файл, у якому бракує одного рядка, зазвичай зависає на останньому запиті замість відмови з чіткою помилкою, і саме тому винять мережу. Порівняйте файл зі своїм записом двічі: один раз щодо порядку і один раз щодо порожніх рядків.
Тримайте файл поза будь-якою синхронізованою текою і доступним лише тому обліковому запису, який виконує завдання. Цей пароль — відкритий текст, тому файл є обліковими даними: жодного репозиторію, жодного спільного диска, жодного вкладення в заявці. Клієнт ні про що з цього не попередить.
Чому GUI має піти першим
Почніть скрипт із завершення процесу GUI, потім запустіть CLI з його власного каталогу встановлення, бо важливі і робочий каталог, і збірка клієнта. Ілюстративна обгортка:
@echo off
taskkill /IM vpnui.exe /F >nul 2>&1
cd /d "%PROGRAMFILES(x86)%\Cisco\Cisco Secure Client"
vpncli.exe -s < C:\secure\login.txtКоди виходу тут не є надійною ознакою успіху. Клієнт друкує свій поступ і тримає тунель в окремому процесі, тому знайдіть у виводі рядок стану підключення і лише потім починайте роботу, що залежить від VPN.
Якщо пропустити завершення GUI, скрипт може виглядати працюючим, тоді як наявний сеанс лишається в тому стані, у якому його залишив користувач. Ця несправність виглядає плаваючою, і саме така помилка переживає тиждень здогадів.
Підтвердьте сеанс, не припускайте його
Після повернення скрипта перевірте те, що існує лише всередині тунелю — внутрішній хост або суфікс DNS, на який відповідає лише корпоративний резолвер. Прочитайте також рядок стану підключення у виводі клієнта і все інше вважайте відмовою, а не повільним успіхом. Повторний запуск файлу, коли сеанс уже піднято, може залишити клієнт наполовину налаштованим, тому або спершу відключіться, або пропустіть вхід, коли сеанс є.
Далі вирішіть, хто відповідає за повторне підключення. Цикл, який пінгує внутрішню адресу і знову запускає вхід, може тримати кіоск онлайн місяцями, а також може заблокувати обліковий запис за першої зміни пароля. Обмежте кількість спроб, подайте сигнал у разі перевищення і дозвольте команді ідентифікації змінити файл замість того, щоб застарілий пароль повторював спроби до блокування.
Старий vpnclient.exe — не той самий інструмент
Та сама автоматизація трапляється під старішим ім'ям, і ці два не взаємозамінні. Виведений з експлуатації клієнт Cisco IPsec використовував vpnclient.exe з аргументами в рядку, як-от дієслово connect, ім'я профілю, користувач і пароль в одному командному рядку; а vpncli.exe очікує послідовність запитів на стандартному вводі з -s. Тому копіювання старого скрипта з форуму на сучасну машину дає команду, яка запускається, нічого видимого не робить, і винним залишається шлюз.
Перш ніж редагувати будь-які аргументи, перевірте, який клієнт встановлено і який скрипт насправді викликає. Різниця в імені достатньо мала, щоб її пропустити в завданні за розкладом, і це перше, що треба перевірити, коли успадкований скрипт перестав працювати після оновлення.