Ett fel, tre hemligheter: vilken VPN-uppgift misslyckades?
Klienten visar ett fel för varje steg. Läs associationen, användarutbytet och metoden innan du återställer ett lösenord som ingen kontrollerat.
”Autentiseringen misslyckades” kan peka på ett servercertifikat, en fördelad maskinnyckel eller ett användarlösenord. Vilken av dem det gäller beror på protokollet, eftersom varje protokoll definierar en egen uppsättning hemligheter. Återställer du den felaktiga står felet kvar oförändrat. Vägen ut är att fastställa hur många bevis protokollet kräver innan du ändrar något.
Två bevis som pekar i motsatta riktningar
En tunnel måste svara på om den nådde rätt gateway, och separat vem användaren är. Gateway-beviset är på maskinnivå: ett servercertifikat, en fördelad nyckel eller en statisk publik nyckel. Användarbeviset är på personnivå: ett lösenord, en token, ett klientcertifikat, eller ingenting alls. Det är motsatta riktningar av tillit och de förbrukar olika material.
IKEv2 utför gateway-beviset inne i IKE_AUTH och, när EAP används, kör användarbeviset i ett separat utbyte efteråt. IKEv2-specifikationen håller dem som skilda avsnitt, vilket är en stark ledtråd om var du ska leta när ett meddelande täcker båda omgångarna.
Läs steget, inte meddelandet
Klienten visar samma felsträng oavsett vilket steg som misslyckades, så själva strängen innehåller nästan ingen information. Det som innehåller information är tillståndet du kan granska i varje steg: om en association finns, om ett användarutbyte startade och om klienten erbjöd den metod som gatewayen ville ha. Tabellen sorterar stegen så, i stället för efter 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 |
Bara den andra raden handlar om en uppgift som användaren kan skriva in igen. De övriga tre är konfigurationsfakta, och den missanpassningen är skälet till att så många av dessa rapporter slutar med en lösenordsåterställning som inte ändrar något. Läs raden som stämmer med dina bevis innan du rör ett fält.
Ett protokoll med två hemligheter visar korten
L2TP över IPsec gör antalet synligt, eftersom de två kontrollerna sker i olika processer. IPsec-lagret måste komma upp först med en fördelad nyckel eller ett certifikat, och först då försöker PPP inuti det med en användarinloggning.
När maskinhemligheten är fel bildas ingen association och användaruppgiften prövas aldrig. När maskinhemligheten är rätt och användarhemligheten fel finns associationen och PPP avvisar inloggningen efter att tunneln redan är uppe. Båda ger samma meddelande på skärmen från två olika händelser.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerEn tom associationslista utesluter användarlagret direkt, så kontrollera den före lösenordet. En etablerad association med upprepade PPP-fel pekar åt andra hållet, mot användarlagret eller mot autentiseringsprotokollet inuti det. Ingen av slutsatserna går att få från klientens feltext.
Vad lösenord-enbart faktiskt beror på
Åtkomst med enbart lösenord är vanligt för L2TP, PPTP, SSTP och IKEv2 med EAP. WireGuard har ingen sådan möjlighet alls, eftersom dess peers är nycklar och inte användare. För OpenVPN kommer svaret från serverns krav på klientcertifikat: en gateway som kräver både certifikat och lösenord fortsätter att avvisa en klient med enbart lösenord, vad som än skrivs i fältet.
Vilken komponent du behöver följer av samma svar. En lösenordsinloggning under IKEv2 kräver en klient som talar EAP, medan en certifikatinloggning behöver klientens privata nyckel och serverns kedja. Installerar du fel läses felet som ett uppgiftsfel, fastän det är själva autentiseringsmetoden som saknas.
Ändra en sak, testa sedan igen
Fastställ tre fakta först: vilket protokoll som körs, hur många hemligheter det definierar och vilka av dem som tillhör maskinen och inte användaren. Maskiner misslyckas i det första steget och människor i det andra, och att blanda ihop dem är hela detta problem.
Ändra sedan exakt en sak och testa igen från samma klient. Den disciplinen gör ett förvirrande fel till en rättelse du kan beskriva för nästa person, vilket är mer användbart än en fungerande anslutning som ingen kan förklara.