Delt hemmelighed eller brugerlogin: hvilket L2TP/IPsec-felt fejlede?
En forudelt nøgle beviser modparten, mens PPP-brugernavnet og -adgangskoden beviser personen. Fejlkoden fortæller, hvilket af de to lag der brød sammen.
Et kontor kan give den samme IPsec-hemmelighed til hver bærbar, mens hver person stadig logger ind med en individuel konto, og derfor kan «nøglen er rigtig» og «adgangskoden er rigtig» begge være sande, mens login stadig mislykkes. L2TP og IPsec autentificerer forskellige parter i forskellige faser. En sammenligning af de to lag, og den fejlkode der skiller dem, lukker de fleste af disse sager hurtigere end endnu en udskiftning af begge værdier. Faserne kan ikke byttes om, og meddelelsen foran dig siger allerede, hvilken der er i spil.
To lag, to forskellige identiteter
IPsec-modpartsautentificering kører først. Klienten og gatewayen beviser over for hinanden, hvem de er, med en forudelt nøgle eller et certifikat, før nogen tunnelnyttelast beskyttes. PPP-udvekslingen inde i L2TP-sessionen kører bagefter, og det er der, dit brugernavn og din adgangskode kontrolleres mod serverens kontolager.
Faserne er uafhængige, så en gyldig brugerkonto kan ikke redde en forkert IPsec-nøgle, og en korrekt nøgle kan ikke redde en udløbet adgangskode. Skriv de to adskilt i sagen, og diagnosen falder som regel ud af den første loglinje, der nævner en fase.
| 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 delte hemmelighed beviser modparten
En forudelt nøgle er en gruppeoplysning, som gatewayen og hver klient, der forbinder til den, ligger inde med. Den fastslår, at modparten kender nøglen, og ud fra den udleder IKE de nøgler, der beskytter forbindelsen. Intet i den udveksling identificerer mennesket ved tastaturet. Det er hele grunden til, at et andet login på brugerniveau findes i samme tunnel.
Det design har en praktisk konsekvens for tilbagekaldelse. Tabet af én bærbar betyder, at hemmeligheden skal roteres for hver enhed, der bruger den, medmindre udrulningen skifter til certifikater, hvor en enkelt enhed kan fjernes uden at røre resten. Handlen er administrativt arbejde mod skadens omfang.
En nøgle, der tastes ind i en profil, er også den letteste oplysning at lække via skærmbilleder og chat. Behandl den som delt infrastrukturmateriale og ikke som en personlig adgangskode, for det er præcis, hvad den er.
Login hører til PPP
Inde i L2TP-sessionen forhandler PPP autentificering og beder serveren om at verificere det par af værdier, du tastede. På Windows er det samme brugernavn og adgangskode, som profilen spørger om, og på en router er det, hvad PPP-profilen refererer til. Det kontrolleres mod kontolageret, ikke mod nøglen. To personer kan dele en bærbar og en nøgle og stadig skelnes på dette trin.
Fordi det er brugerautentificering, gælder alle de sædvanlige kontopolitikker: udløbet adgangskode, låst konto, opkaldsadgang eller et navn, der skal bære et domæne. Fejl 691 rapporterer den kombination som afvist, så læs serverens regnskabsrecord, før du taster noget igen.
Lad fejlen vælge feltet
Fejl 789 nævner sikkerhedslaget og peger på IPsec-fasen. Bekræft, at den forudelte nøgle på begge sider stemmer nøjagtigt, at den modpartsidentitet, gatewayen forventer, svarer til det, klienten sender, og at klienten er konfigureret til L2TP/IPsec og ikke en anden type.
Fejl 691 nævner legitimationsoplysninger og peger på PPP. Kontrollér kontoens tilstand og det nøjagtige navnformat, før du ændrer hemmeligheden, for ændres begge på én gang, ødelægges det bevis, du læste.
Når tunnelen kommer op, og trafikken stadig stopper, skal du helt holde op med at redigere autentificeringsfelter. Se på adressepuljen, ruten tilbage til klientens undernet og MTU: en sammenligning af de to lag hjælper kun, så længe fejlen stadig er inde i dem.