Viena klaida, trys paslaptys: kurie VPN prisijungimo duomenys nepavyko?
Klientas rodo vieną klaidą kiekvienam etapui. Perskaitykite asociaciją, naudotojo mainus ir metodą prieš iš naujo nustatydami slaptažodį, kurio niekas nepatikrino.
„Autentifikacija nepavyko“ gali nurodyti serverio sertifikatą, mašinos iš anksto bendrinamą raktą arba naudotojo slaptažodį. Kuris iš jų turimas omenyje, priklauso nuo protokolo, nes kiekvienas protokolas apibrėžia skirtingą paslapčių rinkinį. Iš naujo nustatykite netinkamą ir klaida išliks nepakitusi. Išeitis yra pirmiausia nustatyti, kiek įrodymų protokolas reikalauja, ir tik tada ką nors redaguoti.
Du įrodymai, nukreipti priešingomis kryptimis
Tunelis turi atsakyti, ar pasiekė tinkamą šliuzą, ir atskirai, kas yra naudotojas. Šliuzo įrodymas yra mašinos lygmens: serverio sertifikatas, iš anksto bendrinamas raktas arba statinis viešasis raktas. Naudotojo įrodymas yra asmens lygmens: slaptažodis, žetonas, kliento sertifikatas arba nieko. Tai priešingos pasitikėjimo kryptys ir jos sunaudoja skirtingą medžiagą.
IKEv2 atlieka šliuzo įrodymą IKE_AUTH viduje, o kai naudojamas EAP, po to atlieka naudotojo įrodymą atskiruose mainuose. IKEv2 specifikacija laiko juos atskirais skyriais, o tai yra stipri užuomina, kur ieškoti, kai viena žinutė apima abu ratus.
Skaitykite etapą, o ne žinutę
Klientas rodo vieną klaidos eilutę, nesvarbu, kuris etapas nepavyko, todėl pati eilutė beveik neteikia informacijos. Informacijos teikia būsena, kurią galite patikrinti kiekviename etape: ar yra asociacija, ar prasidėjo naudotojo mainai ir ar klientas pasiūlė metodą, kurio norėjo šliuzas. Lentelė išdėsto etapus būtent taip, o ne pagal protokolo pavadinimą.
| 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 |
Tik antroji eilutė susijusi su prisijungimo duomenimis, kuriuos naudotojas gali įvesti iš naujo. Kitos trys yra konfigūracijos faktai, ir būtent šis neatitikimas lemia, kad tiek daug tokių ataskaitų baigiasi slaptažodžio nustatymu iš naujo, kuris nieko nekeičia. Prieš liesdami bet kurį lauką, perskaitykite eilutę, atitinkančią jūsų įrodymą.
Dviejų paslapčių protokolas atskleidžia savo kortas
L2TP per IPsec padaro skaičių matomą, nes abu patikrinimai vyksta skirtinguose procesuose. IPsec sluoksnis pirmiausia turi kilti su iš anksto bendrinamu raktu arba sertifikatu, ir tik tada PPP jame bando naudotojo prisijungimą.
Kai mašinos paslaptis neteisinga, asociacija nesusidaro ir naudotojo duomenys niekada nebandomi. Kai mašinos paslaptis teisinga, o naudotojo paslaptis neteisinga, asociacija egzistuoja ir PPP atmeta prisijungimą po to, kai tunelis jau pakeltas. Abu atvejai ekrane duoda tą pačią žinutę iš dviejų skirtingų įvykių.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerTuščias asociacijų sąrašas iškart pašalina naudotojo sluoksnį, todėl patikrinkite jį prieš slaptažodį. Nusistovėjusi asociacija su pasikartojančiais PPP gedimais nukreipia į kitą pusę, į naudotojo sluoksnį arba į autentifikacijos protokolą jame. Nė viena iš šių išvadų nėra pasiekiama iš kliento klaidos teksto.
Nuo ko iš tikrųjų priklauso prisijungimas vien tik slaptažodžiu
Prieiga vien tik slaptažodžiu yra įprasta L2TP, PPTP, SSTP ir IKEv2 su EAP. WireGuard tokios galimybės visiškai neturi, nes jo partneriai yra raktai, o ne naudotojai. OpenVPN atveju atsakymas kyla iš serverio reikalavimo kliento sertifikatui: šliuzas, kuris reikalauja ir sertifikato, ir slaptažodžio, ir toliau atmes klientą, turintį tik slaptažodį, kad ir ką įvestumėte į lauką.
Kurio komponento jums reikia, išplaukia iš to paties atsakymo. Prisijungimas slaptažodžiu pagal IKEv2 reikalauja kliento, kuris kalba EAP, o prisijungimui sertifikatu reikia kliento privataus rakto ir serverio grandinės. Įdiekite netinkamą ir gedimas skaitomas kaip prisijungimo duomenų klaida, nors trūksta pačio autentifikacijos metodo.
Pakeiskite vieną dalyką, tada patikrinkite dar kartą
Pirmiausia nustatykite tris faktus: kuris protokolas veikia, kiek paslapčių jis apibrėžia ir kurios iš jų priklauso mašinai, o ne naudotojui. Mašinos nepavyksta pirmame etape, o žmonės antrame, ir šių dviejų painiojimas yra visa ši problema.
Tada pakeiskite tiksliai vieną dalyką ir patikrinkite dar kartą iš to paties kliento. Ši disciplina paverčia painų gedimą pataisa, kurią galite aprašyti kitam žmogui, ir tai naudingiau nei veikiantis ryšys, kurio niekas negali paaiškinti.