L2TP/IPsec PSK atmesta: pirmiausia dialogas, paskui failai

Įklijuojate iš anksto bendrinamą raktą iš administratoriaus žinutės į NetworkManager dialogą, pažymite langelį jam parodyti, ir jis sutampa po ženklo. Ryšys vis tiek baigiasi autentifikacijos klaida, kol tunelis dar nepakeltas. Pirmą kartą tai pamatęs maniau, kad raktas neteisingas; tačiau nebuvo. Kitus du dalykus, kuriuos demonas iš tikrųjų skaito, lemia slaptųjų duomenų failas, kurį papildinys įrašo tam ryšiui, ir tai, ar reikšmė perėjo dialogą nepakitusi.

Žemiau pateiktas kelias seka raktą nuo lauko iki failo, ir būtent ši tvarka pasako, kur jis dingo. Atlikite tai mašinoje, kuri nepavyksta, o ne toje, kuri veikia, nes skirtumas tarp šių dviejų mašinų paprastai yra failų išdėstymas, o ne raktas.

Pradėkite nuo dialogo, bet nepasitikėkite lauku

Atidarykite ryšio IPsec skirtuką ir raktą įveskite iš naujo, o ne įklijuokite. Raktas, nukopijuotas iš pokalbio žinutės, PDF ar slaptažodžių tvarkyklės, gali atkeliauti su pabaigos eilutės lūžiu, kurio laukas nerodo, o matomi ženklai vis tiek atrodo teisingi.

Spustelėkite slaptažodžio rodymo valdiklį ir žiūrėkite į eilutės pabaigą, o ne į vidurį. Jei žymeklis palieka tuščią eilutę po tekstu, ištrinkite ją ir įveskite paskutinį ženklą iš naujo. Šis vienintelis pataisymas išsprendžia stebėtinai didelę dalį tokių pranešimų ir kainuoja mažiau nei bet kokio žurnalo skaitymas.

Jei raktas gaunamas iš bilietų sistemos, kuri laužo ilgas eilutes, paprašykite jo kanalu, kuris nelaužo. Lyginkite ilgius su administratoriumi, o ne žiūrėkite į dvi eilutes greta; lūžio vietoje prarastas ženklas yra nematomas proporcingame šrife.

Sekite raktą į /etc/ipsec.d

Papildinys niekada neperduoda PSK IPsec demonui kaip argumento komandinėje eilutėje. Vietoj to jis saugo reikšmę slaptųjų duomenų faile ir pasirūpina, kad demonas tą failą įtrauktų, pridėdamas include eilutę į /etc/ipsec.secrets, jei jos nėra. Tai, ką laiko dialogas, yra sugeneruoto failo įvestis, o ne naudojama reikšmė.

Prieš ką nors keisdami, išvardykite, kas yra:

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

Senesnės papildinio versijos rašė po vieną failą kiekvienam ryšiui, pavadintą pagal ryšio UUID, pavyzdžiui /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Ištrynus profilį programėlėje, tas failas nepatikimai ištrinamas. Jei senas ankstesnio serverio failas vis dar yra diske ir vis dar įtrauktas, demonas gali pasirinkti paslaptį, priklausančią profiliui, kurio nebenaudojate, ir ryšys nepavyksta, nors matomas laukas yra teisingas.

Supraskite, ką 1.2.12 pakeitimas padarė atnaujinimams

Papildinio versija 1.2.12 pakeitė kiekvieno ryšio slaptųjų duomenų failus vienu bendru failu, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Atnaujinimas neišvalo senesnių failų pagal UUID, o esama include /etc/ipsec.d/*.secrets eilutė juos vis dar įtraukia. Versija 1.2.16 pakeitė numatytųjų pasiūlymų tvarkymą, o ne paslapčių išdėstymą.

Ši istorija paaiškina, kodėl dvi mašinos, turinčios lyg ir tą patį profilį, elgiasi skirtingai. Raktas yra identiškas; failų, kuriuos demonas įtraukia, rinkinys nėra. Kai pašalinate našlaitį failą, perkelkite jį į šalį, o ne trinkite, patvirtinkite ryšį ir tada ištrinkite, kai veikianti būsena užfiksuota. Pervadinimas išsaugo seną reikšmę atkuriamą, jei paaiškėja, kad gedimas yra kitur.

Atskirkite ženklus, kurių saugojimo formatas negali sutalpinti

strongSwan dokumentacija apie bendrinamos paslapties eilutę teigia, kad reikšmė negali turėti eilutės lūžio ar dvigubos kabutės ženklo. Raktas, įklijuotas iš dokumento, gali turėti bet kurį iš jų be jokio vizualaus skirtumo įprastame dialoge.

Nuo 1.2.12 saugoma reikšmė nebėra paprastas tekstas. Papildinys užkoduoja PSK base64 formatu, kol jis pasiekia failą, o leidimo pastabos šį kodavimą nurodo kaip priežastį, kodėl dviguba kabutė dabar priimtina rakte. Taigi lauke įvesta kabutė yra pavaizduojama; tas pats negalioja kiekvienam valdymo ženklui.

Ilgis yra kita riba. L2TP/IPsec programinėje įrangoje nėra universalaus minimumo: kai kurie klientai priima trumpesnius nei dvidešimt ženklų raktus, o kai kurie tinklų sietai nustato minimumą. Jei trumpas raktas atmetamas, taisyklė priklauso serverio politikai arba to kliento validacijai, ir kažko padidinimas vietoje to nepakeis.

Perskaitykite, kuris autentifikacijos sluoksnis nepavyko

Pirmiausia paleiskite ipsec --version, nes strongSwan ir Libreswan naudoja skirtingus failų pavadinimus ir sintaksę, o patarimas vienam gali pakenkti kitam. Tada perskaitykite gedimo etapą iš kliento žinutės arba demono žurnalo: skundas dėl iš anksto bendrinamo rakto yra kitas įvykis nei atmestas vartotojo vardas ir slaptažodis.

PSK autentifikuoja tunelio galus. Vartotojo vardas ir slaptažodis autentifikuoja asmenį L2TP viduje, o PPP jais rūpinasi po to, kai IPsec asociacija pakelta. Teisingas PSK su neteisinga paskyra vis tiek nepavyksta, o paskyros pakeitimas nesutaisys rakto, kurio demonas niekada teisingai neperskaitė.

Uždarydami bilietą, užsirašykite visus keturis: papildinio versiją, naudojamą slaptųjų duomenų failą, ar raktas buvo įvestas iš naujo, ar įklijuotas, ir klaidą nurodytą sluoksnį. Tada bet kas, kas vėliau pakartos šį kelią, galės iš karto pereiti prie skirtumo tarp veikiančios ir nepavykstančios mašinos.