Je posodobitev Ubuntu pokvarila L2TP/IPsec? Primerjajte predloge IKEv1

Povezava je delovala v četrtek, posodobitev se je izvedla v petek, v ponedeljek pa se odjemalec vrti na “connecting” in obupa. Isti prenosnik, isti strežnik, isti račun, isti vnaprej deljeni ključ. V profilu ni bilo nič urejeno, zato očitni osumljenci, geslo in požarni zid, zapravljajo vaš čas.

Spremenil se je seznam transformacij, ki jih je vaš stroj pripravljen ponuditi. Oba sklada IPsec, ki se uporabljata v Ubuntu, strongSwan in Libreswan, odstranjujeta algoritme, ki se jima ne zdijo več varni, vtičnik NetworkManager pred njima pa ima svoj seznam, ki se premika po drugem urniku. Strežnik, pripet na 3DES, SHA1 in skupino Diffie-Hellman s 1024 biti, lahko na koncu ne sliši ničesar, kar sprejme.

Kaj je posodobitev dejansko spremenila

Predlog IKEv1 napajata dve plasti. Démon priloži vgrajen privzeti nabor predlogov, vtičnik L2TP pa se bodisi nanj zanese bodisi priloži svoj seznam. Pred NetworkManager-l2tp 1.2.16 se je vtičnik zanašal nanj, zato je bil vaš predlog tisto, kar je nameščeni démon štel za razumno. Od 1.2.16 naprej vtičnik pošilja dokumentiran seznam, oblikovan po odjemalcih Windows in Apple, in ta seznam je širši od stare privzete vrednosti, a ne vsebuje več vsake stare kombinacije na čelu vrste.

Ta delitev pojasnjuje način odpovedi, ki se ljudem zdi zmeden: dva stroja na isti izdaji Ubuntu se lahko obnašata različno, ker ima eden distribucijski paket, drugi pa backport, različica démona na obeh pa je v poročilu o napaki videti enaka. Preverite različico vtičnika, ne le različice démona, preden sklenete, da posodobitev ni spremenila ničesar pomembnega.

Na istem področju je manjša past. Dva démona pišeta skupine Diffie-Hellman eliptične krivulje različno, eden piše ecp384, drugi ecp_384. Prilepite napačen zapis v pogovorno okno Advanced in démon bo nastavitev zavrnil kot nerazčlenljivo, kar se v dnevniku pokaže kot težava s pogajanjem in ne kot tipkarska napaka v konfiguraciji.

Preberite odpoved, preden karkoli spremenite

Začnite s tem, kateri backend poganjate, ker odgovor odloči tako o sintaksi kot o mestu dnevnika.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Nato preberite samo izmenjavo. Na strongSwanu démon piše v journal na trenutni izdaji in v /var/log/syslog na starejši, zanimiv del pa je predlog, ki ga pošlje, ne zadnja vrstica. Iščete besedilo o tem, da ni ustreznega predloga, kar je težava algoritma; napako overjanja, ki kaže na ključ ali račun; ali preprost timeout, ki kaže na dosegljivost.

Ti trije izidi se veliko prepogosto obravnavajo kot en simptom. Timeout s praznim dnevnikom démona pomeni, da paketi ne prihajajo. Zavrnitev predloga pomeni, da so prišli in bili zavrnjeni. Če vaš dnevnik molči, za en poskus dvignite raven razhroščevanja vtičnika in jo nato znižajte, ker podroben izpis hitro napolni journal.

Faza 1 in faza 2 sta ločeni stavi

IKEv1 se pogaja dvakrat. Glavni način zgradi varnostno povezavo IKE iz algoritma za šifriranje, algoritma za celovitost, skupine Diffie-Hellman in metode overjanja. Hitri način nato zgradi povezavo ESP, ki bo prenašala L2TP. Strežnik lahko prvo sprejme in drugo zavrne, zato polpravilen profil odpove pozneje, kot pričakujete, in je videti kot druga napaka.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Klicaj je sintaksa strongSwan za strogi vnos: ponudi samo to eno kombinacijo in nič drugega. Brez njega se vnos pridruži rezervnemu seznamu, kar je dobro, ko je partner sodoben, in škodljivo, ko je naprava z eno trdo zakodirano politiko. Par zgoraj obravnavajte kot ponazoritev oblike, ne kot priporočilo za kar koli, kar danes gradite.

Spremenite eno polje in nato ponovite preizkus

Na trenutnem vtičniku je najhitrejši prvi preizkus popolnoma izprazniti obe polji predlogov in se znova povezati, ker priloženi privzeti seznam že vsebuje običajne kombinacije Windows in Apple. Na starejšem vtičniku njuno praznjenje vrne nadzor démonu, ki je morda že opustil algoritem, na katerem vztraja vaš strežnik, in odpoved se poslabša.

Če praznjenje ne pomaga, nastavite strogi par, ki ga dokumentira vaš strežnik, eno fazo naenkrat. Spremenite fazo 1, povežite se znova in preberite dnevnik, preden se dotaknete faze 2. Ko kombinacija končno deluje, jo zapišite ob model strežnika in različico vtičnika, ker se bodo privzete vrednosti spet premaknile in prav ta zapisek spremeni naslednjo posodobitev v petminutno preverjanje.