L2TP/IPsec-PSK afvist: gå gennem dialogen, derefter filerne

Du indsætter den fordelte nøgle fra administratorens besked i NetworkManager-dialogen, sætter hak i feltet for at vise den, og den stemmer tegn for tegn. Forbindelsen ender stadig i en godkendelsesfejl, før tunnelen er oppe. Da jeg så det første gang, antog jeg, at nøglen var forkert; det var den ikke. To andre ting afgør, hvad dæmonen faktisk læser: den hemmelighedsfil, plugin'et skriver for forbindelsen, og om værdien kom uændret gennem dialogen.

Gennemgangen nedenfor følger nøglen fra feltet til filen, og den rækkefølge er det, der fortæller, hvor den gik tabt. Gør det på den maskine, der fejler, ikke på den, der virker, for forskellen mellem de to maskiner er normalt filopbygningen og ikke nøglen.

Start ved dialogen, men stol ikke på feltet

Åbn forbindelsens IPsec-fane, og skriv nøglen igen i stedet for at indsætte den. En nøgle, der er kopieret fra en chatbesked, en PDF eller en adgangskodeadministration, kan ankomme med et linjeskift til sidst, som feltet ikke viser, og de viste tegn ser stadig korrekte ud.

Klik på knappen, der viser adgangskoden, og se på slutningen af strengen, ikke midten. Hvis markøren efterlader en tom linje under teksten, skal du slette den og skrive det sidste tegn igen. Den ene rettelse løser en overraskende del af disse rapporter og koster mindre end at læse nogen log.

Hvis nøglen kommer fra et billetteringssystem, der ombryder lange linjer, så bed om den gennem en kanal, der ikke ombryder. Sammenlign længder med administratoren i stedet for at kigge på to strenge side om side; et tabt tegn ved et ombrydningspunkt er usynligt i en proportional skrift.

Følg nøglen ind i /etc/ipsec.d

Plugin'et giver aldrig PSK'en til IPsec-dæmonen som et argument på en kommandolinje. I stedet gemmer det værdien i en hemmelighedsfil og sørger for, at dæmonen trækker den fil ind ved at tilføje en include-linje til /etc/ipsec.secrets, hvis der ikke er nogen. Det, dialogen holder, er et input til den genererede fil, ikke den anvendte værdi.

List, hvad der findes, før du ændrer noget:

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 plugin-udgivelser skrev én fil per forbindelse, opkaldt efter forbindelsens UUID, for eksempel /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Sletning af en profil i appletten sletter ikke pålideligt den fil. Hvis en gammel fil fra en tidligere server stadig ligger på disken og stadig er inkluderet, kan dæmonen vælge en hemmelighed, der hører til en profil, du ikke bruger længere, og forbindelsen fejler, mens det synlige felt er korrekt.

Forstå, hvad ændringen i 1.2.12 gjorde ved opgraderinger

Plugin-version 1.2.12 erstattede hemmelighedsfilene per forbindelse med en enkelt delt fil, /etc/ipsec.d/ipsec.nm-l2tp.secrets. En opgradering rydder ikke op i de ældre filer per UUID, og en eksisterende include /etc/ipsec.d/*.secrets-linje trækker dem stadig ind. Version 1.2.16 ændrede standardhåndteringen af forslag, ikke hemmelighedernes opbygning.

Den historie forklarer, hvorfor to maskiner med, hvad der ser ud som den samme profil, opfører sig forskelligt. Nøglen er identisk; det sæt filer, dæmonen inkluderer, er ikke. Når du fjerner en forældreløs fil, skal du flytte den til side i stedet for at slette den, bekræfte forbindelsen og derefter slette den, når den fungerende tilstand er noteret. En omdøbning holder den gamle værdi gendanbar, hvis fejlen viser sig at ligge et andet sted.

Skil de tegn ud, som lagerformatet ikke kan rumme

strongSwan-dokumentationen for den delte hemmelighedsstreng angiver, at værdien ikke kan indeholde et linjeskift eller et dobbelt anførselstegn. En nøgle indsat fra et dokument kan bære begge uden nogen visuel forskel i en normal dialog.

Siden 1.2.12 er den gemte værdi ikke almindelig tekst. Plugin'et base64-koder PSK'en, før den når filen, og udgivelsesnoterne fremhæver den kodning som grunden til, at et dobbelt anførselstegn nu er acceptabelt i en nøgle. Et anførselstegn, der tastes i feltet, kan derfor repræsenteres; det samme gælder ikke for hvert kontroltegn.

Længde er en anden begrænsning. Der gælder intet universelt minimum for L2TP/IPsec-software: nogle klienter accepterer nøgler kortere end tyve tegn, og nogle gateways håndhæver et minimum. Afvises en kort nøgle, hører reglen til serverpolitikken eller til den klients validering, og at hæve noget lokalt ændrer det ikke.

Læs, hvilket godkendelseslag der fejlede

Kør ipsec --version først, fordi strongSwan og Libreswan bruger forskellige filnavne og syntaks, og råd til den ene kan skade den anden. Læs derefter fejlstadiet fra klientens besked eller dæmonens log: en klage over den fordelte nøgle er en anden hændelse end et afvist brugernavn og en afvist adgangskode.

PSK'en godkender tunnelens endepunkter. Brugernavnet og adgangskoden godkender personen inde i L2TP, og PPP håndterer dem, efter at IPsec-associationen er oppe. En korrekt PSK med en forkert konto fejler stadig, og at skifte konto reparerer ikke en nøgle, som dæmonen aldrig læste korrekt.

Når du lukker billetten, så skriv alle fire ned: plugin-version, den anvendte hemmelighedsfil, om nøglen blev skrevet igen eller indsat, og det lag, der nævnes i fejlen. Så kan enhver, der gentager denne gennemgang senere, springe direkte til forskellen mellem den fungerende og den fejlende maskine.