L2TP/IPsec misslyckas: isolera IPsec, tunnelautentisering eller PPP-inloggning

Tre saker autentiseras inuti en enda L2TP/IPsec-anslutning, och bara en av dem involverar personen som ringer upp. IPsec bevisar tunnelns ändpunkter, L2TP-kontrollanslutningen kan bevisa motparterna igen med sin egen hemlighet, och PPP bevisar sedan användarkontot inuti sessionen. Ett fel i vilket steg som helst ser ut som ett allmänt inloggningsfel i klientdialogen och ser helt annorlunda ut i en serverlogg. Gå igenom stegen i ordning och stanna vid det första som misslyckas, eftersom varje steg under ett otestat steg också är otestat.

Tre autentiseringssteg, tre olika identiteter

IPsec bevisar vem som äger ändpunkterna, med en i förväg delad nyckel eller ett certifikat. Den identiteten tillhör maskiner eller gateways, aldrig människan vid tangentbordet. När motparterna inte kan komma överens i detta steg utbyts ingen L2TP-paket alls.

L2TP-kontrollanslutningen kan lägga till ett andra, separat utmaning-svar-utbyte som styrs av en gemensam hemlighet som båda ändarna måste ha.

RFC 2661 gör den autentiseringen av kontrollanslutningen valfri, vilket förklarar varför samma misstag ger olika symtom på två servrar. En driftsättning som aldrig konfigurerade en tunnelhemlighet hoppar över steget helt; en som konfigurerade den bara på ena sidan misslyckas innan PPP ens erbjuds. PPP autentiserar sedan användaren med PAP, CHAP eller MSCHAPv2 och lämnar namnet till ett kontolager som kan vara lokalt, i chap-secrets eller på RADIUS. Ett fel lösenord vid den punkten lämnar dig fortfarande med en fungerande tunnel och en misslyckad session.

Läs stoppunkten innan du redigerar en konfiguration

Börja med ipsec --version så att du vet om statusutskriften tillhör strongSwan eller Libreswan. Läs sedan serverloggen, inte klientdialogen, eftersom servern registrerar vilket steg som nekade.

En rad avgör oftast ärendet: ett klagomål på IKE eller förslag är första steget, ett meddelande om kontrollanslutningen är andra steget och ett avslag på PPP-metod eller konto är tredje steget. Kopiera den raden till ärendet med tidsstämpeln. Gissningar från klientsidan slösar bort det enda bevis du redan har.

Håll nyckelmaterial och lösenord utanför den inklistringen; stegnamnet styr arbetet, och en läckt i förväg delad nyckel öppnar ärendet igen med värre konsekvenser.

Första steget: har IPsec en association?

Kör ipsec statusall på strongSwan eller ipsec whack --status på Libreswan och leta efter en etablerad barnassociation med räknare som inte är noll. ip xfrm state visar kärnans vy på båda. Ett installerat SA-par med stigande räknare betyder att första steget är klart och du kan gå vidare.

Helt avsaknad av association pekar på motpartens adress, förslagssatsen eller den i förväg delade nyckeln, och ibland på en enhet som skriver om UDP 500 men släpper UDP 4500. En association som etableras och sedan försvinner efter några sekunder är oftast en livstidsdiskrepans mellan ändarna och inte ett problem med inloggningsuppgifter. Kontrollera om båda sidor listar samma krypterings- och hashförslag innan du skriver något igen. Om inte kommer ingen nyckel någonsin att fungera.

Stanna medan associationen saknas. Att redigera PPP-alternativ vid den punkten ändrar ingenting och döljer det verkliga felet för nästa person.

Andra steget: autentiserade L2TP-kontrollanslutningen sig?

När IPsec är uppe, håll ett öga på L2TP-demonen efter en kontrollanslutning som når etablerat tillstånd, eftersom PPP inte kan börja före det. En nekad anslutning på kontrollanslutningen betyder att tunnelhemligheten skiljer sig mellan ändarna, eller att ena änden kräver en hemlighet som den andra aldrig skickar. Klienter visar ofta ett enda fält märkt shared secret, och det tillhör oftast IPsec och inte L2TP. Att fylla i det konfigurerar inte tunnelhemligheten, och att tömma det inaktiverar den inte.

Om ingen av sidorna har konfigurerat en tunnelhemlighet, hoppa över detta steg och behandla felet på kontrollanslutningen som ett tillgänglighetsproblem i stället. Bekräfta att UDP 1701 når demonen och att båda ändarna är överens om samma inkapsling. En brandväggsregel skriven för ett av dessa två villkor är en vanlig orsak till en anslutning som öppnas halvvägs.

Bara en session som börjar förhandla PPP har verkligen passerat tunnelsteget.

Tredje steget: avvisar PPP kontot?

Ett PPP-fel ser annorlunda ut utifrån: tunneln är etablerad, sessionen startar och demonen loggar ett fel i autentiseringsmetoden eller ett kontoavslag. Läs metoden som namnges i det meddelandet. PAP och CHAP misslyckas av olika skäl, och en server som avvisar den ena kommer att avvisa en klient som bara erbjuder den.

På en Linux-server, granska alternativfilen som demonen ger till PPP, vanligtvis /etc/ppp/options.xl2tpd, och bekräfta vilka metoder som accepteras och var konton löses upp. Ett namn som finns i RADIUS men inte i den lokala hemlighetsfilen misslyckas rent och ser ut som ett dåligt lösenord. Kontrollera sedan att klienten erbjuder en metod som servern accepterar, och inte en starkare som servern vägrar förhandla om. Att ändra den i förväg delade nyckeln för att reparera detta steg slösar bort en eftermiddag och ändrar ingenting.

När sessionen äntligen kommer upp, adresstilldelning, DNS och rutter är ännu inte kontrollerade, och var och en misslyckas tyst på sitt eget sätt. Håll de tre lagren åtskilda i dina anteckningar: en korrekt nyckel med fel konto misslyckas alltid, och att reparera ett lager reparerar aldrig ett annat.