Одна помилка, три секрети: які облікові дані 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, тоді як вхід із сертифікатом потребує закритого ключа клієнта й ланцюжка сервера. Встановіть не той — і збій читається як помилка облікових даних, хоча бракує самого методу автентифікації.
Змініть одне, потім перевірте знову
Спершу встановіть три факти: який протокол працює, скільки секретів він визначає і які з них належать машині, а не користувачеві. Машини збоять на першому етапі, а люди — на другому, і плутанина між цими двома і є вся ця проблема.
Далі змініть рівно одну річ і перевірте знову з того самого клієнта. Ця дисципліна перетворює заплутаний збій на виправлення, яке можна описати наступній людині, і це корисніше за робоче з'єднання, яке ніхто не може пояснити.