Ці --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 паказвае на абмен уліковага запісу. Кнопка, якая ніколі не запускае кліент, паказвае на інтэграцыю з працоўным сталом. Тры розныя няспраўнасці, адна з якіх — пароль, які вы збіраліся ўставіць не ў тое поле.