Одна ошибка, три секрета: какие учётные данные VPN подвели?
Клиент показывает одну ошибку на каждый этап. Прочитайте ассоциацию, обмен пользователя и метод, прежде чем сбрасывать пароль, который никто не проверял.
«Не удалось пройти аутентификацию» может указывать на сертификат сервера, предварительно разделённый ключ машины или пароль пользователя. Что именно имеется в виду, зависит от протокола, потому что каждый протокол определяет свой набор секретов. Сбросьте не тот — ошибка останется без изменений. Выход в том, чтобы установить, сколько доказательств требует протокол, прежде чем что-то менять.
Два доказательства, направленные в разные стороны
Туннель должен ответить, дошёл ли он до нужного шлюза, и отдельно — кто такой пользователь. Доказательство шлюза машинного уровня: сертификат сервера, предварительно разделённый ключ или статический открытый ключ. Доказательство пользователя — уровня человека: пароль, токен, сертификат клиента или ничего вовсе. Это противоположные направления доверия, и они расходуют разный материал.
IKEv2 выполняет доказательство шлюза внутри IKE_AUTH, а когда используется EAP, проводит доказательство пользователя в отдельном обмене после этого. спецификация IKEv2 держит их отдельными разделами, что служит сильной подсказкой, где искать, когда одно сообщение покрывает оба раунда.
Читайте этап, а не сообщение
Клиент показывает одну и ту же строку ошибки независимо от того, какой этап не удался, поэтому сама строка почти не несёт информации. Информацию несёт состояние, которое можно проверить на каждом этапе: существует ли ассоциация, начался ли обмен пользователя и предложил ли клиент метод, которого хотел шлюз. Таблица сортирует этапы именно так, а не по названию протокола.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Только вторая строка касается учётных данных, которые пользователь может ввести заново. Остальные три — факты конфигурации, и именно из-за этого несоответствия многие такие отчёты заканчиваются сбросом пароля, который ничего не меняет. Прочитайте строку, которая соответствует вашим доказательствам, прежде чем трогать поле.
Протокол с двумя секретами раскрывает свои карты
L2TP поверх IPsec делает количество видимым, потому что обе проверки происходят в разных процессах. Уровень IPsec должен подняться первым с предварительно разделённым ключом или сертификатом, и лишь затем PPP внутри него пытается выполнить вход пользователя.
Когда секрет машины неверен, ассоциация не образуется, и учётные данные пользователя никогда не проверяются. Когда секрет машины верен, а секрет пользователя нет, ассоциация существует, и PPP отклоняет вход после того, как туннель уже поднят. Оба случая дают одно и то же сообщение на экране из двух разных событий.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerПустой список ассоциаций сразу исключает пользовательский уровень, поэтому проверьте его раньше пароля. Установленная ассоциация с повторяющимися сбоями PPP указывает в другую сторону — на пользовательский уровень или на протокол аутентификации внутри него. Ни один из выводов недоступен из текста ошибки клиента.
От чего на самом деле зависит вход только по паролю
Вход только по паролю обычен для L2TP, PPTP, SSTP и IKEv2 с EAP. У WireGuard такой возможности нет вовсе, потому что его узлы — это ключи, а не пользователи. Для OpenVPN ответ следует из требования сервера к сертификату клиента: шлюз, который требует и сертификат, и пароль, будет отклонять клиента только с паролем, что бы ни было введено в поле.
Какой компонент нужен, следует из того же ответа. Вход по паролю в IKEv2 требует клиента, который говорит на EAP, тогда как вход по сертификату нуждается в закрытом ключе клиента и цепочке сервера. Установите не тот — и сбой читается как ошибка учётных данных, хотя отсутствует сам метод аутентификации.
Измените одно, затем проверьте снова
Сначала установите три факта: какой протокол работает, сколько секретов он определяет и какие из них принадлежат машине, а не пользователю. Машины сбоят на первом этапе, а люди на втором, и смешение этих двух и есть вся проблема.
Затем измените ровно одну вещь и проверьте снова из того же клиента. Эта дисциплина превращает запутанный сбой в исправление, которое можно описать следующему человеку, и это полезнее работающего соединения, которое никто не может объяснить.