Éin feil, tre løyndomar: kva VPN-legitimasjon svikta?
Klienten viser éin feil for kvart steg. Les assosiasjonen, brukarutvekslinga og metoden før du nullstiller eit passord ingen har kontrollert.
«Autentisering mislukkast» kan peike på eit serversertifikat, ein førehandsdel maskinnøkkel eller eit brukarpassord. Kva det gjeld, kjem an på protokollen, fordi kvar protokoll definerer sitt eige sett av løyndomar. Nullstiller du den gale, står feilen uendra. Vegen ut er å fastslå kor mange prov protokollen krev før du endrar noko.
To prov som peikar i motsett retning
Ein tunnel må svare på om han nådde rett gateway, og separat kven brukaren er. Gateway-provet er på maskinnivå: eit serversertifikat, ein førehandsdel nøkkel eller ein statisk offentleg nøkkel. Brukarprovet er på personnivå: eit passord, eit token, eit klientsertifikat, eller ingenting i det heile. Det er motsette retningar av tillit, og dei brukar ulikt materiale.
IKEv2 utfører gateway-provet inne i IKE_AUTH og, når EAP vert brukt, køyrer brukarprovet i ei eiga utveksling etterpå. IKEv2-spesifikasjonen held desse som skilde avsnitt, noko som er eit sterkt hint om kvar du skal leite når éi melding dekkjer begge rundane.
Les steget, ikkje meldinga
Klienten viser éin feilmelding uansett kva steg som svikta, så sjølve strengen inneheld nesten ingen informasjon. Det som inneheld informasjon, er tilstanden du kan granske i kvart steg: om ein assosiasjon finst, om ei brukarutveksling starta, og om klienten baud metoden gatewayen ville ha. Tabellen sorterer stega slik i staden for etter protokollnamn.
| 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 |
Berre den andre rada handlar om ein legitimasjon ein brukar kan skrive inn på nytt. Dei tre andre er konfigurasjonsfakta, og det misforholdet er grunnen til at så mange av desse rapportane endar med ein passordnullstilling som ikkje endrar noko. Les rada som passar med prova dine, før du rører eit felt.
Ein protokoll med to løyndomar viser korta
L2TP over IPsec gjer talet synleg, fordi dei to kontrollane skjer i ulike prosessar. IPsec-laget må kome opp først med ein førehandsdel nøkkel eller eit sertifikat, og først då prøver PPP inni det ei brukarinnlogging.
Når maskinløyndomen er feil, vert ingen assosiasjon danna, og brukarlegitimasjonen vert aldri prøvd. Når maskinløyndomen er rett og brukarløyndomen er feil, finst assosiasjonen, og PPP avviser innlogginga etter at tunnelen alt er oppe. Begge gir same melding på skjermen frå to ulike hendingar.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerEi tom assosiasjonsliste utelukkar brukarlaget med ein gong, så sjekk ho før passordet. Ein etablert assosiasjon med gjentekne PPP-feil peikar den andre vegen, mot brukarlaget eller mot autentiseringsprotokollen inni det. Ingen av konklusjonane er tilgjengelege frå feilteksten til klienten.
Kva passord-berre faktisk er avhengig av
Passord-berre tilgang er vanleg for L2TP, PPTP, SSTP og IKEv2 med EAP. WireGuard har ikkje noko slikt val i det heile, fordi peerane er nøklar og ikkje brukarar. For OpenVPN kjem svaret frå kravet til serveren om klientsertifikat: ein gateway som krev både sertifikat og passord, vil halde fram med å avvise ein klient med berre passord, kva som helst som vert skrive i feltet.
Kva komponent du treng, følgjer av det same svaret. Ei passordinnlogging under IKEv2 krev ein klient som snakkar EAP, medan ei sertifikatinnlogging treng den private nøkkelen til klienten og kjeda til serveren. Installerer du feil, vert feilen lesen som ein legitimasjonsfeil sjølv om det er sjølve autentiseringsmetoden som manglar.
Endre éin ting, test så på nytt
Fastslå tre fakta først: kva protokoll som køyrer, kor mange løyndomar han definerer, og kva av dei som høyrer til maskinen og ikkje brukaren. Maskinar sviktar i første steg og menneske i andre, og å blande dei to er heile dette problemet.
Endre så nøyaktig éin ting og test på nytt frå same klient. Den disiplinen gjer ein forvirrande feil om til ei retting du kan skildre for neste person, og det er nyttigare enn ei fungerande tilkopling ingen kan forklare.