Bir xəta, üç sirr: hansı VPN giriş məlumatı uğursuz oldu?
Müştəri hər mərhələ üçün bir xəta göstərir. Heç kimin yoxlamadığı bir şifrəni sıfırlamazdan əvvəl assosiasiyanı, istifadəçi mübadiləsini və metodu oxuyun.
“Kimlik doğrulama uğursuz oldu” mesajı server sertifikatına, maşının əvvəlcədən paylaşılmış açarına və ya istifadəçi şifrəsinə işarə edə bilər. Hansının nəzərdə tutulduğu protokoldan asılıdır, çünki hər protokol fərqli bir sirr dəsti müəyyən edir. Səhv olanı sıfırlasanız, xəta olduğu kimi qalır. Çıxış yolu hər hansı bir şeyi redaktə etməzdən əvvəl protokolun nə qədər sübut tələb etdiyini müəyyən etməkdir.
Əks istiqamətlərə baxan iki sübut
Tunel doğru şlüzə çatıb-çatmadığını, istifadəçinin kim olduğunu isə ayrıca cavablandırmalıdır. Şlüz sübutu maşın səviyyəsindədir: server sertifikatı, əvvəlcədən paylaşılmış açar və ya statik açıq açar. İstifadəçi sübutu şəxs səviyyəsindədir: şifrə, token, müştəri sertifikatı və ya heç nə. Bunlar etimadın əks istiqamətləridir və fərqli material sərf edirlər.
IKEv2 şlüz sübutunu IKE_AUTH daxilində yerinə yetirir və EAP istifadə edildikdə istifadəçi sübutunu sonra ayrı mübadilədə işlədir. IKEv2 spesifikasiyası bunları ayrı bölmələr kimi saxlayır, bu da bir mesajın hər iki raundu əhatə etdiyi halda hara baxmalı olduğunuza dair güclü bir işarədir.
Mesajı deyil, mərhələni oxuyun
Müştəri hansı mərhələnin uğursuz olduğundan asılı olmayaraq bir xəta sətri göstərir, buna görə sətrin özü demək olar ki, heç bir məlumat daşımır. Məlumat daşıyan şey hər mərhələdə yoxlaya biləcəyiniz vəziyyətdir: assosiasiyanın olub-olmadığı, istifadəçi mübadiləsinin başlayıb-başlamadığı və müştərinin şlüzün istədiyi metodu təklif edib-etmədiyi. Cədvəl mərhələləri protokol adına görə deyil, bu şəkildə sıralayır.
| 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 |
Yalnız ikinci sətir istifadəçinin yenidən yaza biləcəyi bir giriş məlumatından bəhs edir. Digər üçü konfiqurasiya faktıdır və bu uyğunsuzluq bu hesabatların çoxunun heç nəyi dəyişməyən bir şifrə sıfırlaması ilə bitməsinin səbəbidir. Hər hansı sahəyə toxunmazdan əvvəl sübutunuza uyğun gələn sətri oxuyun.
İki sirrli protokol əlini göstərir
L2TP IPsec üzərində sayı görünən edir, çünki iki yoxlama fərqli proseslərdə baş verir. IPsec qatı əvvəlcə əvvəlcədən paylaşılmış açar və ya sertifikatla qalxmalıdır və yalnız bundan sonra onun içindəki PPP istifadəçi girişinə cəhd edir.
Maşın sirri səhv olduqda heç bir assosiasiya yaranmır və istifadəçi giriş məlumatı heç vaxt sınanmır. Maşın sirri doğru, istifadəçi sirri səhv olduqda isə assosiasiya mövcuddur və PPP girişi tunel artıq qalxdıqdan sonra rədd edir. Hər ikisi ekranda iki fərqli hadisədən eyni mesajı çıxarır.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerBoş assosiasiya siyahısı istifadəçi qatını dərhal istisna edir, buna görə şifrədən əvvəl ona baxın. Təkrar PPP uğursuzluqları ilə mövcud assosiasiya əks istiqamətə, istifadəçi qatına və ya onun içindəki kimlik doğrulama protokoluna işarə edir. Heç bir nəticə müştərinin xəta mətnindən əldə edilə bilməz.
Yalnız şifrə ilə giriş əslində nədən asılıdır
Yalnız şifrə ilə giriş L2TP, PPTP, SSTP və EAP ilə IKEv2 üçün adi haldır. WireGuard-da belə bir seçim ümumiyyətlə yoxdur, çünki onun həmyaşıdları istifadəçilər deyil, açarlardır. OpenVPN üçün cavab serverin müştəri sertifikatı tələbindən gəlir: həm sertifikat, həm də şifrə tələb edən şlüz yalnız şifrə ilə gələn müştərini sahəyə nə yazılırsa da rədd etməyə davam edəcək.
Hansı komponentə ehtiyacınız olduğu eyni cavabdan irəli gəlir. IKEv2 altında şifrə ilə giriş EAP danışan müştəri tələb edir, sertifikatla giriş isə müştərinin şəxsi açarını və serverin zəncirini tələb edir. Səhv olanı quraşdırsanız, uğursuzluq giriş məlumatı xətası kimi oxunur, halbuki çatışmayan şey kimlik doğrulama metodunun özüdür.
Bir şeyi dəyişin, sonra yenidən sınayın
Əvvəlcə üç faktı müəyyənləşdirin: hansı protokol işləyir, neçə sirr müəyyən edir və hansıları istifadəçiyə deyil, maşına aiddir. Maşınlar birinci mərhələdə, insanlar ikincidə uğursuz olur və ikisini qarışdırmaq bu problemin tamamıdır.
Sonra tam olaraq bir şeyi dəyişin və eyni müştəridən yenidən sınayın. Bu intizam çaşdırıcı bir uğursuzluğu növbəti adama izah edə biləcəyiniz bir düzəlişə çevirir ki, bu da heç kimin izah edə bilmədiyi işlək bir bağlantıdan daha faydalıdır.