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

Du limer inn den førehandsdelte nøkkelen frå meldinga til administratoren i NetworkManager-dialogen, hakar av for å vise han, og han stemmer teikn for teikn. Tilkoplinga endar likevel i ein autentiseringsfeil før tunnelen er oppe. Då eg såg dette første gongen, trudde eg at nøkkelen var feil; det var han ikkje. To andre ting avgjer kva dæmonen faktisk les: løyndomsfila som programtillegget skriv for tilkoplinga, og om verdien kom uendra gjennom dialogen.

Gjennomgangen nedanfor følgjer nøkkelen frå feltet til fila, og den rekkjefølgja er det som fortel deg kvar han gjekk tapt. Gjer det på maskinen som feilar, ikkje på den som verkar, for skilnaden mellom dei to maskinene er vanlegvis filoppsettet og ikkje nøkkelen.

Start ved dialogen, men ikkje stol på feltet

Opne IPsec-fana for tilkoplinga og skriv nøkkelen på nytt i staden for å lime han inn. Ein nøkkel som er kopiert frå ei chatmelding, ein PDF eller ein passordhandsamar, kan kome med eit linjeskift på slutten som feltet ikkje viser, og dei viste teikna ser framleis rette ut.

Klikk på kontrollen som viser passordet, og sjå på slutten av strengen, ikkje midten. Viss markøren lèt att ei tom line under teksten, slett ho og skriv det siste teiknet på nytt. Den eine rettinga løyser ein overraskande del av slike rapportar, og ho kostar mindre enn å lese nokon logg.

Kjem nøkkelen frå eit billettsystem som bryt lange liner, be om han gjennom ein kanal som ikkje bryt dei. Samanlikn lengdene med administratoren i staden for å sjå på to strengar side ved side; eit tapt teikn ved eit brotpunkt er usynleg i ein proporsjonal skrift.

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

Programtillegget gir aldri PSK-en til IPsec-dæmonen som eit argument på kommandolinja. I staden lagrar det verdien i ei løyndomsfil og sørgjer for at dæmonen tek ho inn, ved å leggje til ei include-line i /etc/ipsec.secrets viss det ikkje finst noka. Det dialogen held, er inndata til den genererte fila, ikkje verdien som blir brukt.

List opp kva som finst før du endrar noko:

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 utgåver av programtillegget skreiv éi fil per tilkopling, kalla opp etter UUID-en til tilkoplinga, til dømes /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Sletting av ein profil i appletten slettar ikkje den fila påliteleg. Viss ei gammal fil frå ein tidlegare server framleis ligg på disken og framleis er inkludert, kan dæmonen velje ein løyndom som høyrer til ein profil du ikkje brukar lenger, og tilkoplinga feilar medan det synlege feltet er rett.

Forstå kva endringa i 1.2.12 gjorde med oppgraderingar

Versjon 1.2.12 av programtillegget erstatta løyndomsfilene per tilkopling med éi delt fil, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Ei oppgradering ryddar ikkje opp i dei eldre filene per UUID, og ei eksisterande include /etc/ipsec.d/*.secrets-line tek dei framleis inn. Versjon 1.2.16 endra handsaminga av standardforslag, ikkje oppsettet av løyndomane.

Den historia forklarar kvifor to maskiner med det som ser ut som same profil oppfører seg ulikt. Nøkkelen er identisk; settet med filer som dæmonen inkluderer, er det ikkje. Når du fjernar ei foreldrelaus fil, flytt ho til side i staden for å slette ho, stadfest tilkoplinga og slett ho deretter når den verknadsfulle tilstanden er notert. Å gje ho nytt namn held den gamle verdien attopprettbar viss feilen viser seg å liggje ein annan stad.

Skil ut teikna som lagringsformatet ikkje kan romme

strongSwan-dokumentasjonen for den delte løyndomsstrengen seier at verdien ikkje kan innehalde eit linjeskift eller eit dobbelt anførselsteikn. Ein nøkkel som er limt inn frå eit dokument, kan bere begge utan nokon visuell skilnad i ein normal dialog.

Sidan 1.2.12 er den lagra verdien ikkje rein tekst. Programtillegget base64-kodar PSK-en før han når fila, og utgjevingsnotatane framhevar den kodinga som grunnen til at eit dobbelt anførselsteikn no er akseptabelt i ein nøkkel. Eit anførselsteikn som blir skrive i feltet, kan derfor representerast; det same gjeld ikkje for kvart kontrollteikn.

Lengd er ei anna avgrensing. Det gjeld inga universell minstegrense for L2TP/IPsec-programvare: nokre klientar godtek nøklar kortare enn tjue teikn, og nokre gatewayar handhevar eit minimum. Viss ein kort nøkkel blir avvist, høyrer regelen til serverpolitikken eller valideringa til den klienten, og å heve noko lokalt endrar ikkje det.

Les kva autentiseringslag som feila

Køyr ipsec --version først, fordi strongSwan og Libreswan brukar ulike filnamn og syntaks, og råd for den eine kan skade den andre. Les deretter feilsteget frå meldinga til klienten eller loggen til dæmonen: ei klage på den førehandsdelte nøkkelen er ei anna hending enn eit avvist brukarnamn og passord.

PSK-en autentiserer endepunkta i tunnelen. Brukarnamnet og passordet autentiserer personen inne i L2TP, og PPP handterer dei etter at IPsec-tilknytinga er oppe. Ein korrekt PSK med feil konto feilar likevel, og å byte konto reparerer ikkje ein nøkkel som dæmonen aldri las rett.

Når du lukkar billetten, skriv ned alle fire: versjonen av programtillegget, løyndomsfila som blir brukt, om nøkkelen vart skriven på nytt eller limt inn, og laget som blir nemnt i feilen. Då kan kven som helst som gjer denne gjennomgangen seinare, gå rett til skilnaden mellom den verknadsfulle og den feilande maskinen.