Delad hemlighet eller användarinloggning: vilket L2TP/IPsec-fält misslyckades?
En i förväg delad nyckel bevisar motparten, medan PPP-användarnamnet och lösenordet bevisar personen. Felkoden säger vilket av de två lagren som brast.
Ett kontor kan ge samma IPsec-hemlighet till varje laptop medan varje person ändå loggar in med ett eget konto, och därför kan «nyckeln är rätt» och «lösenordet är rätt» båda vara sanna och inloggningen ändå misslyckas. L2TP och IPsec autentiserar olika parter i olika faser. En jämförelse av de två lagren, och felkoden som skiljer dem, stänger de flesta av dessa ärenden snabbare än att byta båda värdena igen. Faserna är inte utbytbara, och meddelandet framför dig säger redan vilken som är i spel.
Två lager, två olika identiteter
Först körs IPsec-motpartsautentiseringen. Klienten och gatewayen bevisar för varandra vilka de är, med en i förväg delad nyckel eller ett certifikat, innan någon tunnellast skyddas. PPP-utbytet inne i L2TP-sessionen kommer efteråt, och det är där ditt användarnamn och lösenord kontrolleras mot serverns kontolager.
Faserna är oberoende, så ett giltigt användarkonto kan inte rädda en felaktig IPsec-nyckel, och en korrekt nyckel räddar inte ett utgånget lösenord. Skriv de två åtskilda i ärendet och diagnosen faller oftast ut ur den första loggraden som namnger en fas.
| Observed failure | Stage that rejected it | Field to touch |
|---|---|---|
| Security layer error 789 during initial negotiation | IKE and IPsec peer authentication | The pre-shared key or the certificate |
| Error 691, credentials not recognised | PPP user authentication | User name, password, or account policy |
| Tunnel forms, then drops on the first packet | Neither, usually routing or MTU | Address pool and interface configuration |
| Prompt repeats with no error text | Often the client type selection | The connection profile, not the secret |
Den delade hemligheten bevisar motparten
En i förväg delad nyckel är en gruppuppgift som gatewayen och varje klient som ansluter till den har. Den fastställer att motparten känner till nyckeln, och ur den härleder IKE nycklarna som skyddar anslutningen. Ingenting i det utbytet identifierar människan vid tangentbordet. Det är hela anledningen till att en andra inloggning, på användarnivå, finns i samma tunnel.
Den designen har en praktisk konsekvens för återkallning. Att förlora en laptop innebär att rotera hemligheten för varje enhet som använder den, om inte utrullningen går över till certifikat, där en enskild enhet kan tas bort utan att röra resten. Handeln är administrativt arbete mot skadans omfattning.
En nyckel som skrivs in i en profil är också den uppgift som lättast läcker via skärmbilder och chatt. Behandla den som delat infrastrukturmaterial och inte som ett personligt lösenord, för det är precis vad den är.
Inloggningen tillhör PPP
Inne i L2TP-sessionen förhandlar PPP om autentisering och ber servern verifiera paret av värden som du skrev in. I Windows är det samma användarnamn och lösenord som profilen frågar efter, och på en router det som PPP-profilen refererar till. Det kontrolleras mot kontolagret, inte mot nyckeln. Två personer kan dela en laptop och en nyckel och ändå skiljas åt i den här fasen.
Eftersom det är användarautentisering gäller alla vanliga kontoprinciper: utgånget lösenord, låst konto, uppringningsbehörighet eller ett namn som måste bära en domän. Fel 691 rapporterar den kombinationen som avvisad, så läs serverns bokföringspost innan du skriver något igen.
Låt felet välja fältet
Fel 789 namnger säkerhetslagret och pekar på IPsec-fasen. Bekräfta att den i förväg delade nyckeln på båda sidor stämmer exakt, att motpartsidentiteten som gatewayen förväntar sig matchar det klienten skickar, och att klienten är konfigurerad för L2TP/IPsec och inte en annan typ.
Fel 691 namnger autentiseringsuppgifter och pekar på PPP. Kontrollera kontostatusen och det exakta namnformatet innan du ändrar hemligheten, för att ändra båda samtidigt förstör beviset du läste.
När tunneln kommer upp och trafiken ändå stannar, sluta helt att redigera autentiseringsfält. Titta på adresspoolen, vägen tillbaka till klientens subnät och MTU: en jämförelse av de två lagren hjälper bara så länge felet fortfarande finns inuti dem.