Ошибка неверного секрета приходит из контейнера, а не из правила пароля
Один и тот же пароль передаётся через графическое поле и файл учётных данных, и сбоит в разных местах. Сравните контейнеры, прежде чем упрощать пароль, который всё время был верным.
Сообщение «неверный секрет» обычно приводит к одному выводу: VPN не любит знаки препинания. Этот вывод обычно неверен, потому что сообщение часто приходит от локальной обработки ещё до того, как шлюз посмотрел на учётную запись. Две конструкции передают один и тот же пароль, графическое поле и файл учётных данных, и сбоят в разных местах. Сравните контейнеры, прежде чем упрощать пароль, который всё время был верным.
Ошибка возникает до шлюза
Локальная проверка, заблокированное хранилище секретов, отсутствующий агент и испорченный файл учётных данных дают сбои, которые пользователь воспринимает как один отказ. Ни один из них не связан с сервером аутентификации. Отказ самого шлюза — отдельное событие, и обычно он приходит с другим сообщением и в другое время. Он происходит после того, как туннель существует и учётные данные переданы.
Поэтому первый вопрос — не какие символы допустимы, а где остановилась попытка. Клиент, который так и не открыл соединение, никем не отвергнут. Запишите наблюдаемый этап, потому что каждый следующий шаг зависит от этой классификации.
Различие меняет и то, кто это исправляет. Проблема контейнера принадлежит устройству и его владельцу, а отказ учётной записи — тому, кто обслуживает серверную часть аутентификации.
Сравнивайте контейнеры, а не символы
Графическое поле пароля, запись в связке ключей, файл учётных данных из двух строк и секрет автоматизации несут одно и то же значение в разных оболочках. У оболочки свои правила, и ломаются обычно именно они. Значение редко бывает проблемой; проблема в передаче значения. Держите эти две идеи раздельно, и диагностика станет короче.
| Где останавливается значение | Что вы видите | Что вы проверяете | Кто отвечает за исправление |
|---|---|---|---|
| Поле графического интерфейса или управляемый профиль | Сообщение проверки до открытия любого соединения | Выбранный режим аутентификации и то, хранит ли поле секрет или имя пользователя | Владелец устройства или автор профиля |
| Связка ключей или агент секретов | Запрос, который появляется снова, или ошибка агента | Разблокирован ли агент и есть ли в нём запись для этого профиля | Пользователь, владеющий связкой ключей |
| Файл учётных данных из двух строк | Запрос пароля, который уже был передан | Число строк, порядок строк и наличие завершающего перевода строки | Тот, кто создал файл |
| Аргумент оболочки или окружение | Работает в интерактивном режиме, но сбоит в автоматизации | Развернула ли оболочка значение, обрезала или записала в журнал | Тот, кто написал автоматизацию |
Параметры клиента 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, полным расширений оболочки. Оба могут преобразовать символы до того, как они попадут в файл, и получившийся сбой выглядит как отказ VPN, потому что пароль на диске действительно отличается от известного вам. Если подозреваете это, сравните длину файла в байтах с ожидаемым значением, не выводя сам секрет. Расхождение в один-два байта — признак аварии с кавычками.
Прочитайте этап по первой ошибке
Сохраните первое конкретное сообщение одной попытки, затем классифицируйте его. Локальная ошибка проверки, отсутствующий закрытый ключ, недоступный агент секретов и сбой аутентификации шлюза — четыре разных результата с четырьмя разными владельцами. Только один из них про учётную запись.
Если шлюз действительно отвергает корректно доставленные учётные данные, проверьте учётную запись, серверную часть аутентификации и любое требуемое испытание с администратором. Общий сбой аутентификации не называет запрещённый символ.
Восстановите одобренное значение правильным механизмом, вместо того чтобы сводить его к буквам и цифрам. Политика паролей принадлежит оператору, и обход, который тихо её побеждает, не является исправлением. Он ещё и скрывает настоящий дефект от следующего человека, который встретит ту же ошибку с более слабым паролем и без лучшей идеи.