Няправільныя сакрэты — гэта праблема кантэйнера, а не правіла пароля
Адхіленыя ўліковыя дадзеныя маглі ніколі не дайсці да шлюза. Спачатку параўнайце кантэйнер уводу, этап аўтэнтыфікацыі і сам уліковы запіс.
Паведамленне «няправільныя сакрэты» звычайна вядзе да адной высновы: VPN не любіць знакі прыпынку. Гэтая выснова часцей за ўсё памылковая, бо паведамленне часта прыходзіць з лакальнай апрацоўкі яшчэ да таго, як які-небудзь шлюз паглядзеў на ўліковы запіс. Дзве канструкцыі перадаюць той жа пароль — графічнае поле і файл уліковых дадзеных — і яны збаўляюць у розных месцах. Параўнайце кантэйнеры, перш чым спрошчваць пароль, які ўвесь час быў правільным.
Памылка ўзнікае раней за шлюз
Лакальная праверка, зачыненае сховішча сакрэтаў, адсутны агент і пашкоджаны файл уліковых дадзеных — усе яны даюць збоі, якія карыстальнік адчувае як адну адмову. Ніводзін з іх не тычыцца сервера аўтэнтыфікацыі. Уласная адмова шлюза — асобная падзея, і яна звычайна прыходзіць з іншым паведамленнем і ў іншы момант. Яна адбываецца пасля таго, як існуе тунель і ўліковыя дадзеныя перададзены.
Такім чынам, першае пытанне не ў тым, якія сімвалы дапушчальныя, а ў тым, дзе спынілася спроба. Кліент, які так і не адкрыў злучэнне, нікім не быў адхілены. Запішыце этап, які вы назіралі, бо кожны наступны крок залежыць ад гэтай класіфікацыі.
Гэтае размежаванне таксама мяняе таго, хто выпраўляе. Праблема кантэйнера належыць прыладзе і яе ўласніку, а адмова ўліковага запісу — таму, хто кіруе сістэмай аўтэнтыфікацыі.
Параўноўвайце кантэйнеры, а не сімвалы
Поле пароля ў графічным інтэрфейсе, запіс у звязцы ключоў, файл уліковых дадзеных з двух радкоў і сакрэт аўтаматызацыі — кожны нясе тое ж значэнне ў іншай абгортцы. У абгорткі свае правілы, і звычайна ламаюцца менавіта яны. Значэнне рэдка бывае праблемай; праблемай з'яўляецца перадача значэння. Раздзяляйце гэтыя дзве думкі, і дыягназ стане карацейшым.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Параметры кліента супольнасці OpenVPN 2.6 апісвае той файл з двух радкоў для auth-user-pass, уключаючы паводзіны, калі радок пароля адсутнічае: кліент замест гэтага запытвае яго. Гэтая адна дэталь тлумачыць цэлы клас паведамленняў «ён просіць пароль, які я ўжо даў». Яна таксама кажа вам, што пусты другі радок — гэта значнае стан, а не бясшкодны выбар фарматавання.
Цытаванне — зноў асобны ўзровень: двукоссі ў звычайным файле ўліковых дадзеных захоўваюцца як даныя, а абалонка выдаляе іх перш, чым праграма што-небудзь убачыць. Той жа сімвал бясшкодны ў адным месцы і структурны ў іншым. Табліца не можа сказаць вам, які кантэйнер выкарыстаў ваш кліент, таму прачытайце ўласную канфігурацыю кліента, перш чым выбіраць радок.
Пераносы радкоў таксама структурныя. Файл з палямі, падзеленымі радкамі, не можа несці значэнне, якое змяшчае новы радок, і гэта абмежаванне фармату, а не меркаванне пра надзейнасць пароля. Выкарыстоўвайце падтрыманы механізм дастаўкі разгортвання замест таго, каб абрэзваць сакрэт, каб ён змясціўся ў імправізаваны файл.
Стварыце файл уліковых дадзеных без шкоды ад абалонкі
Самы бяспечны лакальны шлях трымае сакрэт па-за гісторыяй абалонкі і па-за спісам аргументаў працэсу. Прачытайце абодва палі інтэрактыўна, потым запішыце два радкі, якія чакае кліент. Усё астатняе можа застацца ў файле канфігурацыі, які лёгка прагледзець.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsПершыя дзве каманды чытаюць імя карыстальніка, а потым пароль без яго адлюстравання, трэцяя запісвае абодва радкі, чацвёртая абмяжоўвае файл, а апошняя запускае кліент з гэтым файлам. Звярніце ўвагу, што read -r захоўвае зваротныя скосы, і гэта менавіта тая дэталь, якая ператварае працоўны пароль у збойны, калі яе прапусціць.
Пазбягайце стварэння файла з дапамогай зменнай без двукоссяў або here-document, поўнага раскрыццяў абалонкі. Абодва могуць змяніць сімвалы да таго, як яны дасягнуць файла, і выніковы збой выглядае як адмова VPN, бо пароль на дыску сапраўды адрозніваецца ад пароля, які вы ведаеце. Калі вы падазраяце гэта, параўнайце байтавую даўжыню файла з чаканым значэннем, не друкуючы сам сакрэт. Розніца ў адзін-два байты — подпіс памылкі цытавання.
Вызначце этап па першай памылцы
Захавайце першае канкрэтнае паведамленне адной спробы, а затым класіфікуйце яго. Лакальная памылка праверкі, адсутны прыватны ключ, недаступны агент сакрэтаў і збой аўтэнтыфікацыі на шлюзе — гэта чатыры розныя вынікі з чатырма рознымі ўласнікамі. Толькі адзін з іх тычыцца ўліковага запісу.
Калі шлюз сапраўды адхіляе правільна перададзеныя ўліковыя дадзеныя, праверце ўліковы запіс, сістэму аўтэнтыфікацыі і любы патрабаваны выклік разам з адміністратарам. Агульны збой аўтэнтыфікацыі не называе забаронены сімвал.
Аднавіце зацверджанае значэнне праз правільны механізм, а не зводзьце яго да літар і лічбаў. Палітыка пароляў належыць аператару, і абыход, які ціха яе парушае, не з'яўляецца выпраўленнем. Ён таксама хавае сапраўдны дэфект ад наступнага чалавека, які сустрэне тую ж памылку з больш слабым паролем і без лепшай ідэі.