L2TP/IPsec-PSK avvist: gå gjennom dialogen, deretter filene

Du limer inn den forhåndsdelte nøkkelen fra administratorens melding i NetworkManager-dialogen, haker av for å vise den, og den stemmer tegn for tegn. Tilkoblingen ender likevel i en godkjenningsfeil før tunnelen er oppe. Da jeg så dette første gang, antok jeg at nøkkelen var feil; det var den ikke. To andre ting avgjør hva demonen faktisk leser: hemmelighetsfilen som plugin-modulen skriver for tilkoblingen, og om verdien kom uendret gjennom dialogen.

Gjennomgangen nedenfor følger nøkkelen fra feltet til filen, og den rekkefølgen er det som forteller deg hvor den gikk tapt. Gjør det på maskinen som feiler, ikke på den som virker, for forskjellen mellom de to maskinene er vanligvis filoppsettet og ikke nøkkelen.

Start ved dialogen, men ikke stol på feltet

Åpne IPsec-fanen for tilkoblingen og skriv nøkkelen på nytt i stedet for å lime den inn. En nøkkel som er kopiert fra en chatmelding, en PDF eller en passordbehandler, kan komme med et linjeskift på slutten som feltet ikke viser, og de viste tegnene ser fortsatt riktige ut.

Klikk på kontrollen som viser passordet, og se på slutten av strengen, ikke midten. Hvis markøren etterlater en tom linje under teksten, sletter du den og skriver det siste tegnet på nytt. Den ene rettelsen løser en overraskende andel av slike rapporter, og den koster mindre enn å lese noen logg.

Hvis nøkkelen kommer fra et billettsystem som bryter lange linjer, ber du om den gjennom en kanal som ikke bryter dem. Sammenlign lengdene med administratoren i stedet for å se på to strenger side ved side; et tapt tegn ved et bruddpunkt er usynlig i en proporsjonal skrift.

Følg nøkkelen inn i /etc/ipsec.d

Plugin-modulen gir aldri PSK-en til IPsec-demonen som et argument på kommandolinjen. I stedet lagrer den verdien i en hemmelighetsfil og sørger for at demonen tar den filen inn, ved å legge til en include-linje i /etc/ipsec.secrets hvis det ikke finnes noen. Det dialogen holder, er et inndata til den genererte filen, ikke verdien som brukes.

List opp hva som finnes før du endrer noe:

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

Eldre utgivelser av plugin-modulen skrev én fil per tilkobling, oppkalt etter tilkoblingens UUID, for eksempel /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Sletting av en profil i appletten sletter ikke den filen pålitelig. Hvis en gammel fil fra en tidligere server fortsatt ligger på disken og fortsatt er inkludert, kan demonen velge en hemmelighet som tilhører en profil du ikke bruker lenger, og tilkoblingen feiler mens det synlige feltet er riktig.

Forstå hva endringen i 1.2.12 gjorde med oppgraderinger

Plugin-versjon 1.2.12 erstattet hemmelighetsfilene per tilkobling med én delt fil, /etc/ipsec.d/ipsec.nm-l2tp.secrets. En oppgradering rydder ikke opp i de eldre filene per UUID, og en eksisterende include /etc/ipsec.d/*.secrets-linje tar dem fortsatt inn. Versjon 1.2.16 endret håndteringen av standardforslag, ikke oppsettet av hemmelighetene.

Den historikken forklarer hvorfor to maskiner med det som ser ut som samme profil oppfører seg ulikt. Nøkkelen er identisk; settet med filer som demonen inkluderer, er det ikke. Når du fjerner en foreldreløs fil, flytt den til side i stedet for å slette den, bekreft tilkoblingen og slett den deretter når den fungerende tilstanden er notert. Å gi den nytt navn holder den gamle verdien gjenopprettbar hvis feilen viser seg å ligge et annet sted.

Skill ut tegnene som lagringsformatet ikke kan romme

strongSwan-dokumentasjonen for den delte hemmelighetsstrengen sier at verdien ikke kan inneholde et linjeskift eller et dobbelt anførselstegn. En nøkkel som er limt inn fra et dokument, kan bære begge uten noen visuell forskjell i en normal dialog.

Siden 1.2.12 er den lagrede verdien ikke ren tekst. Plugin-modulen base64-koder PSK-en før den når filen, og utgivelsesnotatene fremhever den kodingen som grunnen til at et dobbelt anførselstegn nå er akseptabelt i en nøkkel. Et anførselstegn som skrives i feltet, kan derfor representeres; det samme gjelder ikke for hvert kontrolltegn.

Lengde er en annen begrensning. Det gjelder ingen universell minimumsgrense for L2TP/IPsec-programvare: noen klienter godtar nøkler kortere enn tjue tegn, og noen gatewayer håndhever et minimum. Hvis en kort nøkkel avvises, tilhører regelen serverpolicyen eller valideringen til den klienten, og å heve noe lokalt endrer ikke det.

Les hvilket godkjenningslag som feilet

Kjør ipsec --version først, fordi strongSwan og Libreswan bruker forskjellige filnavn og syntaks, og råd for den ene kan skade den andre. Les deretter feilsteget fra klientens melding eller demonens logg: en klage på den forhåndsdelte nøkkelen er en annen hendelse enn et avvist brukernavn og passord.

PSK-en godkjenner endepunktene i tunnelen. Brukernavnet og passordet godkjenner personen inne i L2TP, og PPP håndterer dem etter at IPsec-tilknytningen er oppe. En korrekt PSK med feil konto feiler likevel, og å bytte konto reparerer ikke en nøkkel som demonen aldri leste riktig.

Når du lukker billetten, skriv ned alle fire: plugin-versjon, hemmelighetsfilen som brukes, om nøkkelen ble skrevet på nytt eller limt inn, og laget som nevnes i feilen. Da kan enhver som gjentar denne gjennomgangen senere, gå rett til forskjellen mellom den fungerende og den feilende maskinen.