Недійсні секрети — це проблема контейнера, а не правило пароля
Відхилені облікові дані могли взагалі не дійти до шлюзу. Спершу порівняйте контейнер введення, етап автентифікації та сам обліковий запис.
Побачивши повідомлення про недійсні секрети, зазвичай роблять один висновок: 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 |
Параметри клієнта Community 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, бо пароль на диску справді відрізняється від того, який ви знаєте. Якщо ви це підозрюєте, порівняйте байтову довжину файлу з очікуваним значенням, не друкуючи сам секрет. Розбіжність в один-два байти — це підпис аварії з лапками.
Прочитайте етап із першої помилки
Збережіть перше конкретне повідомлення з однієї спроби, потім класифікуйте його. Помилка локальної перевірки, відсутній закритий ключ, недоступний агент секретів і збій автентифікації на шлюзі — це чотири різні результати з чотирма різними власниками. Лише один із них стосується облікового запису.
Якщо шлюз справді відхиляє правильно передані облікові дані, перевірте обліковий запис, серверну частину автентифікації та будь-який потрібний виклик разом з адміністратором. Загальний збій автентифікації не називає заборонений символ.
Відновіть затверджене значення через правильний механізм, а не зводьте його до літер і цифр. Політика паролів належить оператору, і обхідний шлях, який тихо її знецінює, не є виправленням. Він також приховує справжній дефект від наступної людини, яка зустріне ту саму помилку зі слабшим паролем і без кращої ідеї.