L2TP/IPsec werkt niet: isoleer IPsec, tunnelauthenticatie of PPP-login

Drie dingen authenticeren binnen één L2TP/IPsec-verbinding, en slechts één daarvan betrekt de persoon die inbelt. IPsec bewijst de tunneleindpunten, de L2TP-besturingsverbinding kan de peers opnieuw bewijzen met een eigen geheim, en PPP bewijst daarna het gebruikersaccount binnen de sessie. Een fout in welke fase dan ook ziet er in de clientdialoog uit als een algemene inlogfout en ziet er in een serverlog volstrekt anders uit. Doorloop de fasen op volgorde en stop bij de eerste die faalt, want elke fase onder een ongeteste fase is ook ongetest.

Drie authenticatiefasen, drie verschillende identiteiten

IPsec bewijst wie de eindpunten bezit, met een vooraf gedeelde sleutel of een certificaat. Die identiteit hoort bij machines of gateways, nooit bij de mens achter het toetsenbord. Als de peers het in deze fase niet eens worden, wordt er helemaal geen L2TP-pakket uitgewisseld.

De L2TP-besturingsverbinding kan een tweede, aparte challenge-response-uitwisseling toevoegen, aangestuurd door een gedeeld geheim dat beide uiteinden moeten hebben.

RFC 2661 maakt die authenticatie van de besturingsverbinding optioneel, wat verklaart waarom dezelfde fout op twee servers verschillende symptomen geeft. Een implementatie die nooit een tunnelgeheim heeft ingesteld, slaat de fase volledig over; een die het slechts aan één kant instelde, faalt voordat PPP ooit wordt aangeboden. PPP authenticeert de gebruiker vervolgens met PAP, CHAP of MSCHAPv2 en geeft de naam door aan een accountopslag die lokaal kan zijn, in chap-secrets of op RADIUS. Een verkeerd wachtwoord op dat punt laat je nog steeds achter met een werkende tunnel en een mislukte sessie.

Lees het stoppunt voordat je een configuratie aanpast

Begin met ipsec --version zodat je weet of de statusuitvoer bij strongSwan of bij Libreswan hoort. Lees daarna de serverlog, niet de clientdialoog, omdat de server vastlegt welke fase weigerde.

Eén regel beslist meestal het ticket: een klacht over IKE of voorstellen is fase één, een bericht over de besturingsverbinding is fase twee, en een weigering van PPP-methode of account is fase drie. Kopieer die regel met de tijdstempel in het ticket. Gissen vanaf de clientkant verspilt het enige bewijs dat je al hebt.

Houd sleutelmateriaal en wachtwoorden buiten die plakactie; de fasenaam stuurt het werk, en een uitgelekte vooraf gedeelde sleutel heropent het ticket met ergere gevolgen.

Fase één: heeft IPsec een associatie?

Voer ipsec statusall uit op strongSwan of ipsec whack --status op Libreswan en zoek een tot stand gebrachte kindassociatie met tellers die niet nul zijn. ip xfrm state toont bij beide de kernelweergave. Een geïnstalleerd paar SA's met oplopende tellers betekent dat fase één klaar is en je verder kunt.

Helemaal geen associatie wijst op het peeradres, de voorstellenset of de vooraf gedeelde sleutel, en soms op een apparaat dat UDP 500 herschrijft terwijl het UDP 4500 laat vallen. Een associatie die tot stand komt en na een paar seconden verdwijnt, is meestal een levensduurverschil tussen beide uiteinden en geen probleem met inloggegevens. Controleer of beide kanten dezelfde coderings- en hashvoorstellen vermelden voordat je iets opnieuw typt. Zo niet, dan werkt geen enkele sleutel ooit.

Stop zolang de associatie ontbreekt. PPP-opties aanpassen verandert op dat punt niets en verbergt de echte fout voor de volgende persoon.

Fase twee: heeft de L2TP-besturingsverbinding zich geauthenticeerd?

Zodra IPsec draait, let op de L2TP-daemon voor een besturingsverbinding die een gevestigde toestand bereikt, want PPP kan daarvoor niet beginnen. Een weigering op de besturingsverbinding betekent dat het tunnelgeheim tussen de uiteinden verschilt, of dat het ene uiteinde een geheim eist dat het andere nooit stuurt. Clients tonen vaak één veld met het label shared secret, en dat hoort meestal bij IPsec en niet bij L2TP. Het invullen configureert het tunnelgeheim niet, en het wissen schakelt het niet uit.

Als geen van beide kanten een tunnelgeheim heeft ingesteld, sla deze fase over en behandel een fout van de besturingsverbinding als een bereikbaarheidsprobleem. Controleer dat UDP 1701 de daemon bereikt en dat beide uiteinden het eens zijn over dezelfde inkapseling. Een firewallregel die voor één van die twee voorwaarden is geschreven, is een veelvoorkomende oorzaak van een verbinding die half opent.

Alleen een sessie die PPP begint te onderhandelen, is echt door de tunnelfase gekomen.

Fase drie: weigert PPP het account?

Een PPP-fout ziet er van buiten anders uit: de tunnel is gevestigd, de sessie begint en de daemon logt een fout in de authenticatiemethode of een accountweigering. Lees de methode die in dat bericht wordt genoemd. PAP en CHAP falen om verschillende redenen, en een server die er één weigert, weigert een client die alleen die ene aanbiedt.

Op een Linux-server, bekijk het optiebestand dat de daemon aan PPP geeft, meestal /etc/ppp/options.xl2tpd, en bevestig welke methoden worden geaccepteerd en waar accounts worden opgelost. Een naam die in RADIUS bestaat maar niet in het lokale geheimenbestand, faalt netjes en lijkt op een verkeerd wachtwoord. Controleer daarna of de client een methode aanbiedt die de server accepteert, in plaats van een sterkere die de server weigert te onderhandelen. De vooraf gedeelde sleutel wijzigen om deze fase te repareren kost een middag en verandert niets.

Wanneer de sessie eindelijk opkomt, adrestoewijzing, DNS en routes zijn nog niet gecontroleerd, en elk faalt stil op zijn eigen manier. Houd de drie lagen gescheiden in je notities: een juiste sleutel met een verkeerd account faalt altijd, en het repareren van één laag repareert nooit een andere.