L2TP/IPsec-PSK avvisades: gå igenom dialogen, sedan filerna

Du klistrar in den fördelade nyckeln från administratörens meddelande i NetworkManager-dialogen, kryssar i rutan för att visa den, och den stämmer tecken för tecken. Anslutningen slutar ändå i ett autentiseringsfel innan tunneln är uppe. Första gången jag såg det antog jag att nyckeln var fel; det var den inte. Två andra saker avgör vad daemonen faktiskt läser: hemlighetsfilen som insticksmodulen skriver för anslutningen, och om värdet kom igenom dialogen oförändrat.

Genomgången nedan följer nyckeln från fältet till filen, och den ordningen är det som säger var den gick förlorad. Gör det på maskinen som misslyckas, inte på den som fungerar, eftersom skillnaden mellan de två oftast är filuppsättningen och inte nyckeln.

Börja vid dialogen, men lita inte på fältet

Öppna anslutningens IPsec-flik och skriv nyckeln igen i stället för att klistra in den. En nyckel som kopierats från ett chattmeddelande, en PDF eller en lösenordshanterare kan komma med en radbrytning på slutet som fältet inte visar, och de synliga tecknen ser fortfarande korrekta ut.

Klicka på kontrollen som visar lösenordet och titta på slutet av strängen, inte mitten. Om markören lämnar en tom rad under texten, ta bort den och skriv det sista tecknet igen. Den enda rättelsen löser en förvånansvärd del av sådana här rapporter och kostar mindre än att läsa någon logg.

Om nyckeln kommer från ett biljettsystem som bryter långa rader, begär den via en kanal som inte bryter. Jämför längderna med administratören i stället för att titta på två strängar sida vid sida; ett tecken som tappas vid en brytpunkt är osynligt i ett proportionellt typsnitt.

Följ nyckeln in i /etc/ipsec.d

Insticksmodulen lämnar aldrig PSK:n till IPsec-daemonen som ett argument på kommandoraden. I stället lagrar den värdet i en hemlighetsfil och ser till att daemonen tar in filen, genom att lägga till en include-rad i /etc/ipsec.secrets om det inte finns någon. Det dialogen håller är indata för den genererade filen, inte värdet som används.

Lista vad som finns innan du ändrar något:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Äldre versioner av insticksmodulen skrev en fil per anslutning, uppkallad efter anslutningens UUID, till exempel /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Att ta bort en profil i appletten tar inte bort den filen pålitligt. Om en gammal fil från en tidigare server fortfarande ligger på disken och fortfarande ingår, kan daemonen välja en hemlighet som hör till en profil du inte längre använder, och anslutningen misslyckas medan det synliga fältet är korrekt.

Förstå vad ändringen i 1.2.12 gjorde med uppgraderingar

Insticksmodulens version 1.2.12 ersatte hemlighetsfilerna per anslutning med en enda delad fil, /etc/ipsec.d/ipsec.nm-l2tp.secrets. En uppgradering städar inte bort de äldre filerna per UUID, och en befintlig include /etc/ipsec.d/*.secrets-rad tar fortfarande in dem. Version 1.2.16 ändrade hanteringen av standardförslag, inte hemligheternas uppsättning.

Den historiken förklarar varför två maskiner med vad som ser ut som samma profil beter sig olika. Nyckeln är identisk; mängden filer som daemonen tar in är det inte. När du tar bort en övergiven fil, flytta den åt sidan i stället för att radera den, bekräfta anslutningen och radera den först när det fungerande tillståndet är dokumenterat. Att byta namn håller det gamla värdet återställningsbart om felet visar sig ligga någon annanstans.

Skilj ut tecknen som lagringsformatet inte kan rymma

strongSwan-dokumentationen för den delade hemlighetssträngen säger att värdet inte får innehålla en radbrytning eller ett dubbelt citattecken. En nyckel som klistrats in från ett dokument kan bära endera utan någon synlig skillnad i en normal dialog.

Sedan 1.2.12 är det lagrade värdet inte ren text. Insticksmodulen base64-kodar PSK:n innan den når filen, och versionsnoteringarna anger den kodningen som skälet till att ett dubbelt citattecken nu är godtagbart i en nyckel. Ett citattecken som skrivs i fältet går därför att representera; detsamma gäller inte varje styrtecken.

Längd är en annan begränsning. Det finns inget universellt minimum för L2TP/IPsec-programvara: vissa klienter accepterar nycklar kortare än tjugo tecken och vissa gateways kräver ett minimum. Om en kort nyckel avvisas tillhör regeln serverns policy eller valideringen i den klienten, och att höja något lokalt ändrar inte det.

Läs vilket autentiseringslager som misslyckades

Kör ipsec --version först, eftersom strongSwan och Libreswan använder olika filnamn och syntax, och råd för den ena kan skada den andra. Läs sedan felets steg från klientens meddelande eller daemonens logg: ett klagomål om den fördelade nyckeln är en annan händelse än ett avvisat användarnamn och lösenord.

PSK:n autentiserar tunnelns ändpunkter. Användarnamnet och lösenordet autentiserar personen inne i L2TP, och PPP hanterar dem efter att IPsec-associationen är uppe. En korrekt PSK med fel konto misslyckas ändå, och att byta konto reparerar inte en nyckel som daemonen aldrig läste rätt.

När du stänger biljetten, skriv ner alla fyra: insticksmodulens version, hemlighetsfilen som används, om nyckeln skrevs igen eller klistrades in, och lagret som nämns i felet. Då kan den som upprepar genomgången senare hoppa direkt till skillnaden mellan den fungerande och den misslyckade maskinen.