Дали --key-password в OpenConnect е паролата за вашия VPN акаунт?

Прочетете името на опцията буквално. То назовава ключ и объркването започва, когато файлът, който се отключва, се сбърка с акаунта, който се удостоверява. Поставете паролата за акаунта в тази опция и клиентът ще се опита да отвори с нея файл с ключ, което се проваля по причини, нямащи нищо общо с влизането във VPN.

Объркващото е, че една връзка може законно да се нуждае от двете тайни. Удостоверяването с клиентски сертификат може да изисква криптиран ключ и същият шлюз може да продължи с обмен на удостоверяване на потребителя, след като сертификатът бъде приет. Нито една тайна не удовлетворява другия етап и отказ в едната изглежда отвън много подобно на отказ в другата.

Две тайни, две различни задачи

Четете ролите като достъп до файл срещу допускане до мрежата. Паролата за ключа дешифрира частния ключ PEM, посочен в --sslkey, за да може да се представи клиентският сертификат TLS. Това дешифриране става локално, вътре в процеса на клиента, и самата парола никога не пътува до шлюза. Шлюзът вижда сертификата и подпис, направен с ключа. Ръководството на OpenConnect документацията държи --key-password до --certificate и --sslkey, а при сборки, които могат да използват ключ в TPM, същата опция носи вместо това паролата на коренния ключ за съхранение.

Паролата за акаунта е различна по вид. Тя влиза в обмена за удостоверяване: формуляр с потребителско име и парола, токен, обиколка SAML или някаква комбинация, която шлюзът обявява. Някои внедрявания изобщо не я искат, когато сертификатът е единственият фактор, а други я искат дори след сертификат, защото сертификатът доказва устройството, докато акаунтът доказва човека.

Смесването на двете създава подвеждащи грешки. Шлюз, който отхвърля влизане, обикновено съобщава за неуспешно удостоверяване, докато грешната парола за ключа обикновено се проваля по-рано, когато слоят TLS не може да прочете файла с ключа. Това са различни етапи с различни поправки и имената са достатъчно сходни, че хората ги разменят и после гонят грешния журнал. Отбележете кое подканяне се появи, преди да промените каквато и да е настройка, защото формулировката на подканянето е най-евтината диагностика, с която разполагате.

Кога паролата за ключа наистина е нужна

Опцията има смисъл само когато има криптиран ключ за отключване. Ако се свързвате с потребителско име и парола и без клиентски сертификат, --key-password няма върху какво да действа и включването ѝ не променя нищо. Ако се свързвате с --certificate и --sslkey, собственият формат на файла с ключа решава дали изобщо ще бъде поискана парола.

Двете тайни в една команда са чести в управлявани среди: сертификат на устройство в криптиран ключ плюс вход за всеки потребител. Правилната последователност е клиентът да поиска паролата за ключа локално, да завърши ръкостискането на сертификата и след това да се справи отделно с подканянето за акаунт от шлюза. Опитът да се попълнят предварително и двете чрез един преизползван скрипт е мястото, където обикновено започва объркването.

Полезна диагностика е да се види кога настъпва отказът. Ако клиентът спре преди да започне каквото и да е мрежово удостоверяване, подозирайте файла с ключа, формата му или паролата. Ако сесията TLS е установена и шлюзът после отхвърли потребителя, ключът е свършил работата си и проблемът е в обмена за акаунта.

Дръжте двете тайни извън историята на обвивката

Аргументите на командния ред могат да се четат от други локални потребители през таблицата на процесите и често се улавят в историята на обвивката, скриптове и стенограми от поддръжка. OpenConnect може да чете паролата за акаунта от стандартния вход с --passwd-on-stdin, а паролата за ключа може да идва от интерактивно подканяне или агент, вместо от аргумент. Нито един механизъм не прави тайната безопасна сама по себе си, но и двата я държат извън най-изложените места.

Файловете заслужават същото внимание. Скрипт, който записва парола във временен файл, трябва да го създаде с ограничителни права, да го изтрие при изход и да избягва директории, четени от всички. Парола, която преживява сесията във временна директория, е копие, което сте забравили да направите. Променливите на средата са видими за дъщерните процеси и често се отпечатват от инструменти за отстраняване на грешки, така че не са безплатно подобрение спрямо аргументите.

Диагностичният изход е тихият теч. Клиентските журнали при по-висока подробност могат да покажат тела на заявки или стойности на опции, а копирана стенограма от терминала лесно се поставя в билет, затова прочетете изхода, преди да го споделите.

Мъртъв бутон на работния плот е различен дефект

Запис за VPN на работния плот, който показва въртящ се индикатор и после нищо, обикновено изобщо не е проблем с удостоверяването. Бутонът принадлежи на мрежов мениджър, аплет на доставчик или плъгин, който стартира OpenConnect от ваше име, а липсващ компонент или нечетим профил могат да дадат точно този симптом. Открийте кой процес стартира бутонът и прочетете грешката му, преди да пипате идентификационни данни.

Изкушаващо е да се отпусне проверката на сертификата или да се изключи проверка, когато GUI отказва да се свърже. Това превръща дефект в интеграцията на клиента в понижаване на сигурността и рядко поправя проблема със стартирането. Пазете проверката на сървъра непокътната, потвърдете, че профилът сочи към предвидения шлюз, и проверете дали помощната програма, която GUI очаква, наистина е инсталирана.

Кратък контролен списък разделя случаите. Локален отказ, преди да излезе какъвто и да е пакет, сочи към ключа или инсталацията на клиента. Отхвърляне от шлюза след сесията TLS сочи към обмена за акаунта. Бутон, който никога не стартира клиента, сочи към интеграцията с работния плот. Три различни дефекта, един от които е парола, която сте щели да поставите в грешното поле.