Адна памылка, тры сакрэты: якія даныя доступу 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, а ўваход па сертыфікаце — прыватнага ключа кліента і ланцужка сервера. Пастаўце не той — і збой будзе чытацца як памылка даных доступу, хоць не хапае самога метаду аўтэнтыфікацыі.
Змяніце адну рэч, потым пераправерце
Спачатку ўсталюйце тры факты: які пратакол працуе, колькі сакрэтаў ён вызначае і якія з іх належаць машыне, а не карыстальніку. Машыны падводзяць на першым этапе, людзі — на другім, і блытаніна паміж імі — гэта ўся праблема.
Затым змяніце роўна адну рэч і пераправерце з таго ж кліента. Такая дысцыпліна ператварае заблытаны збой у выпраўленне, якое вы можаце апісаць наступнаму чалавеку, і гэта карыснейшае за працоўнае злучэнне, якое ніхто не можа растлумачыць.