Én feil, tre hemmeligheter: hvilken VPN-legitimasjon sviktet?
Klienten viser én feil for hvert trinn. Les assosiasjonen, brukerutvekslingen og metoden før du tilbakestiller et passord ingen har kontrollert.
“Autentisering mislyktes” kan peke på et serversertifikat, en forhåndsdelt maskinnøkkel eller et brukerpassord. Hvilken det gjelder, avhenger av protokollen, fordi hver protokoll definerer sitt eget sett hemmeligheter. Tilbakestiller du den gale, består feilen uendret. Veien ut er å fastslå hvor mange bevis protokollen krever før du endrer noe.
To bevis som peker i motsatt retning
En tunnel må svare på om den nådde riktig gateway, og separat hvem brukeren er. Gateway-beviset er på maskinnivå: et serversertifikat, en forhåndsdelt nøkkel eller en statisk offentlig nøkkel. Brukerbeviset er på personnivå: et passord, et token, et klientsertifikat, eller ingenting i det hele tatt. Det er motsatte retninger av tillit, og de forbruker forskjellig materiale.
IKEv2 utfører gateway-beviset inne i IKE_AUTH og, når EAP brukes, kjører brukerbeviset i en egen utveksling etterpå. IKEv2-spesifikasjonen holder disse som atskilte avsnitt, noe som er et sterkt hint om hvor du skal lete når én melding dekker begge rundene.
Les trinnet, ikke meldingen
Klienten viser én feilmelding uansett hvilket trinn som sviktet, så selve strengen inneholder nesten ingen informasjon. Det som inneholder informasjon, er tilstanden du kan inspisere i hvert trinn: om en assosiasjon finnes, om en brukerutveksling startet, og om klienten tilbød metoden gatewayen ønsket. Tabellen sorterer trinnene på den måten i stedet for etter protokollnavn.
| 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 |
Bare den andre raden handler om en legitimasjon en bruker kan skrive inn på nytt. De tre andre er konfigurasjonsforhold, og det misforholdet er grunnen til at så mange av disse rapportene ender med en passordtilbakestilling som ikke endrer noe. Les raden som passer med bevisene dine, før du rører et felt.
En protokoll med to hemmeligheter viser kortene
L2TP over IPsec gjør antallet synlig, fordi de to kontrollene skjer i forskjellige prosesser. IPsec-laget må komme opp først med en forhåndsdelt nøkkel eller et sertifikat, og først da forsøker PPP inni det en brukerinnlogging.
Når maskinhemmeligheten er feil, dannes ingen assosiasjon, og brukerlegitimasjonen prøves aldri. Når maskinhemmeligheten er riktig og brukerhemmeligheten er feil, finnes assosiasjonen, og PPP avviser innloggingen etter at tunnelen allerede er oppe. Begge gir samme melding på skjermen fra to forskjellige hendelser.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerEn tom assosiasjonsliste utelukker brukerlaget umiddelbart, så sjekk den før passordet. En etablert assosiasjon med gjentatte PPP-feil peker den andre veien, mot brukerlaget eller mot autentiseringsprotokollen inni det. Ingen av konklusjonene er tilgjengelige fra klientens feiltekst.
Hva passord-bare faktisk avhenger av
Passord-bare tilgang er vanlig for L2TP, PPTP, SSTP og IKEv2 med EAP. WireGuard har ingen slik mulighet i det hele tatt, fordi peerne er nøkler og ikke brukere. For OpenVPN kommer svaret fra serverens krav om klientsertifikat: en gateway som krever både sertifikat og passord, vil fortsette å avvise en klient med bare passord, uansett hva som skrives i feltet.
Hvilken komponent du trenger, følger av samme svar. En passordinnlogging under IKEv2 krever en klient som snakker EAP, mens en sertifikatinnlogging trenger klientens private nøkkel og serverens kjede. Installerer du feil, leses feilen som en legitimasjonsfeil selv om det er selve autentiseringsmetoden som mangler.
Endre én ting, så test på nytt
Fastslå tre fakta først: hvilken protokoll som kjører, hvor mange hemmeligheter den definerer, og hvilke av dem som tilhører maskinen og ikke brukeren. Maskiner svikter i første trinn og mennesker i andre, og å blande de to er hele problemet.
Endre deretter nøyaktig én ting og test på nytt fra samme klient. Den disiplinen gjør en forvirrende feil om til en rettelse du kan beskrive for neste person, og det er mer nyttig enn en fungerende tilkobling ingen kan forklare.