Gedeeld geheim of gebruikersaanmelding: welk L2TP/IPsec-veld faalde?
Een vooraf gedeelde sleutel bewijst de peer, terwijl de PPP-gebruikersnaam en -wachtwoord de persoon bewijzen. De foutcode zegt welke van de twee lagen is gebroken.
Eén kantoor kan hetzelfde IPsec-geheim aan elke laptop geven terwijl iedereen zich nog met een eigen account aanmeldt, en daarom kunnen „de sleutel klopt” en „het wachtwoord klopt” allebei waar zijn en de aanmelding alsnog mislukken. L2TP en IPsec authenticeren verschillende partijen in verschillende fasen. Een vergelijking van de twee lagen, en de foutcode die ze scheidt, sluit de meeste van deze tickets sneller dan nog een keer beide waarden omwisselen. De fasen zijn niet uitwisselbaar, en het bericht voor je zegt al welke in het spel is.
Twee lagen, twee verschillende identiteiten
Eerst loopt de IPsec-peerauthenticatie. De client en de gateway bewijzen elkaar wie ze zijn, met een vooraf gedeelde sleutel of een certificaat, voordat enige tunnelpayload wordt beschermd. De PPP-uitwisseling binnen de L2TP-sessie komt daarna, en daar worden je gebruikersnaam en wachtwoord tegen de accountopslag van de server gecontroleerd.
De fasen zijn onafhankelijk, dus een geldige gebruikersaccount kan een verkeerde IPsec-sleutel niet redden, en een juiste sleutel redt geen verlopen wachtwoord. Schrijf de twee apart in het ticket en de diagnose valt meestal uit de eerste logregel die een fase noemt.
| 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 |
Het gedeelde geheim bewijst de peer
Een vooraf gedeelde sleutel is een groepsreferentie die de gateway en elke client die ermee verbindt bezitten. Hij stelt vast dat de peer de sleutel kent, en daaruit leidt IKE de sleutels af die de verbinding beschermen. Niets aan die uitwisseling identificeert de mens achter het toetsenbord. Dat is precies de reden dat er een tweede aanmelding op gebruikersniveau in dezelfde tunnel bestaat.
Dat ontwerp heeft een praktisch gevolg voor intrekking. Eén laptop verliezen betekent het geheim roteren voor elk apparaat dat het gebruikt, tenzij de uitrol overstapt op certificaten, waar één apparaat kan worden verwijderd zonder de rest aan te raken. De ruil is administratieve inspanning tegen de omvang van de schade.
Een sleutel die in een profiel wordt getypt is ook de gemakkelijkst via schermafbeeldingen en chat weglekkende referentie. Behandel hem als gedeeld infrastructuurmateriaal en niet als een persoonlijk wachtwoord, want dat is precies wat hij is.
De aanmelding hoort bij PPP
Binnen de L2TP-sessie onderhandelt PPP over authenticatie en vraagt de server het paar waarden te verifiëren dat je hebt getypt. Op Windows zijn dat dezelfde gebruikersnaam en hetzelfde wachtwoord als het profiel vraagt, en op een router is het wat het PPP-profiel verwijst. Het wordt tegen de accountopslag gecontroleerd, niet tegen de sleutel. Twee mensen kunnen een laptop en een sleutel delen en worden in deze fase alsnog uit elkaar gehouden.
Omdat het gebruikersauthenticatie is, gelden alle gebruikelijke accountregels: verlopen wachtwoord, vergrendeld account, inbelmachtiging of een naam die een domein moet dragen. Fout 691 meldt die combinatie als geweigerd, dus lees het boekhoudrecord van de server voordat je iets opnieuw typt.
Laat de fout het veld kiezen
Fout 789 noemt de beveiligingslaag en wijst naar de IPsec-fase. Bevestig dat de vooraf gedeelde sleutel aan beide kanten exact overeenkomt, dat de peer-identiteit die de gateway verwacht overeenkomt met wat de client stuurt, en dat de client voor L2TP/IPsec is geconfigureerd en niet voor een ander type.
Fout 691 noemt de inloggegevens en wijst naar PPP. Controleer de accountstatus en het exacte naamformaat voordat je het geheim wijzigt, want beide tegelijk wijzigen vernietigt het bewijs dat je las.
Als de tunnel opkomt en het verkeer alsnog stopt, stop dan helemaal met het bewerken van authenticatievelden. Kijk naar de adrespool, de route terug naar het clientsubnet en de MTU: een vergelijking van de twee lagen helpt alleen zolang de storing nog binnenin zit.