Една грешка, три тайни: кои данни за достъп на 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, докато входът със сертификат се нуждае от частния ключ на клиента и веригата на сървъра. Инсталирайте грешния и отказът изглежда като грешка в данните за достъп, макар че липсва самият метод за автентикация.
Променете едно нещо, после тествайте отново
Първо установете три факта: кой протокол работи, колко тайни дефинира и кои от тях принадлежат на машината, а не на потребителя. Машините се провалят на първия етап, хората — на втория, и объркването между двете е цялата тази проблема.
След това променете точно едно нещо и тествайте отново от същия клиент. Тази дисциплина превръща объркващия отказ в поправка, която можете да опишете на следващия човек, а това е по-полезно от работеща връзка, която никой не може да обясни.