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. Затова копирането на стар форумен скрипт на съвременна машина дава команда, която се изпълнява, не прави нищо видимо и за нея се обвинява шлюзът.

Преди да редактирате какъвто и да е аргумент, проверете кой клиент е инсталиран и кой всъщност вика скриптът. Разликата в името е достатъчно малка, за да се пропусне в планирана задача, и е първото, което трябва да се провери, когато наследен скрипт спре да работи след надграждане.

Подобни статии