A e prishi përditësimi i Ubuntu L2TP/IPsec? Krahasoni propozimet IKEv1

Lidhja funksiononte të enjten, përditësimi u ekzekutua të premten, dhe të hënën klienti rrotullohet te “connecting” dhe dorëzohet. I njëjti laptop, i njëjti server, i njëjti llogari, i njëjti çelës i ndarë paraprakisht. Asgjë në profil nuk u redaktua, prandaj të dyshuarit e dukshëm, fjalëkalimi dhe firewall-i, ju humbin kohën.

Ajo që ndryshoi është lista e transformimeve që makina juaj është e gatshme të ofrojë. Të dy stekat IPsec të përdorura në Ubuntu, strongSwan dhe Libreswan, heqin algoritmet që nuk i konsiderojnë më të sigurt, dhe shtojca e NetworkManager përpara tyre ka listën e vet, e cila lëviz sipas një orari tjetër. Një server i fiksuar te 3DES, SHA1 dhe një grup Diffie-Hellman prej 1024 bitësh mund të përfundojë duke mos dëgjuar asgjë që pranon.

Çfarë ndryshoi në të vërtetë përditësimi

Dy shtresa ushqejnë propozimin IKEv1. Daemoni sjell një grup propozimesh të paracaktuara të përpiluara, dhe shtojca L2TP ose mbështetet te ai ose jep listën e vet. Para NetworkManager-l2tp 1.2.16 shtojca mbështetej te ai, kështu që propozimi juaj ishte ajo që daemoni i instaluar e quante të arsyeshme. Nga 1.2.16 e tutje shtojca dërgon një listë të dokumentuar të modeluar sipas klientëve Windows dhe Apple, dhe kjo listë është më e gjerë se paracaktimi i vjetër por nuk përmban më çdo kombinim të trashëguar në krye të radhës.

Ky ndarje shpjegon një mënyrë dështimi që njerëzit e shohin konfuze: dy makina në të njëjtin version Ubuntu mund të sillen ndryshe sepse njëra ka paketën e shpërndarjes dhe tjetra ka një backport, dhe versioni i daemonit në të dyja duket identik në një raport gabimi. Kontrolloni versionin e shtojcës, jo vetëm versionin e daemonit, përpara se të konkludoni se përditësimi nuk ndryshoi asgjë të rëndësishme.

Ka një kurth më të vogël në të njëjtën zonë. Dy daemonët i shkruajnë ndryshe grupet Diffie-Hellman të kurbës eliptike, njëri shkruan ecp384 dhe tjetri ecp_384. Ngjitni drejtshkrimin e gabuar në dialogun Advanced dhe daemoni e refuzon cilësimin si të paanalizueshëm, gjë që në regjistër shfaqet si problem negociimi dhe jo si gabim shtypi në konfigurim.

Lexoni dështimin përpara se të ndryshoni çdo gjë

Filloni me atë se cilin backend po ekzekutoni, sepse përgjigja përcakton si sintaksën ashtu edhe vendndodhjen e regjistrit.

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

Pastaj lexoni vetë shkëmbimin. Në strongSwan daemoni shkruan në journal në një version aktual dhe në /var/log/syslog në një më të vjetër, dhe pjesa interesante është propozimi që dërgon, jo rreshti i fundit. Po kërkoni formulim për asnjë propozim që përputhet, që është problem algoritmi; një dështim autentikimi, që tregon çelësin ose llogarinë; ose një timeout të thjeshtë, që tregon arritshmërinë.

Këto tre rezultate trajtohen shumë shpesh si një simptom i vetëm. Një timeout me regjistër daemoni bosh do të thotë që paketat nuk po mbërrijnë. Një refuzim i propozimit do të thotë që ato mbërritën dhe u refuzuan. Nëse regjistri juaj është i qetë, rritni nivelin e korrigjimit të shtojcës për një provë dhe më pas uleni, sepse dalja e detajuar mbush shpejt një journal.

Faza 1 dhe faza 2 janë baste të ndara

IKEv1 negocion dy herë. Modaliteti kryesor ndërton shoqërimin e sigurisë IKE nga një algoritëm kriptimi, një algoritëm integriteti, një grup Diffie-Hellman dhe një metodë autentikimi. Modaliteti i shpejtë ndërton më pas shoqërimin ESP që do të transportojë L2TP. Një server është i lirë ta pranojë të parën dhe ta refuzojë të dytën, prandaj një profil gjysmë i saktë dështon më vonë sesa prisni dhe duket si një gabim tjetër.

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

Pikëçuditja është sintaksë e strongSwan për një zë të rreptë: ofro vetëm këtë kombinim dhe asgjë tjetër. Pa të zëri i bashkohet një liste rezervë, që është mirë kur pala tjetër është moderne dhe kundërproduktive kur është pajisje me një politikë të vetme të koduar fort. Trajtojeni çiftin më sipër si ilustrim të formës, jo si rekomandim për çdo gjë që ndërtoni sot.

Ndryshoni një fushë, më pas përsëritni testin

Në një shtojcë aktuale, testi i parë më i shpejtë është të pastroni plotësisht të dy fushat e propozimeve dhe të rilidheni, sepse lista e paracaktuar e dhënë tashmë përfshin kombinimet e zakonshme të Windows dhe Apple. Në një shtojcë më të vjetër, pastrimi i tyre ia kthen kontrollin një daemoni që mund ta ketë hedhur poshtë algoritmin që këmbëngul serveri juaj, dhe dështimi përkeqësohet.

Nëse pastrimi nuk ndihmon, vendosni çiftin e rreptë që dokumenton serveri juaj, një fazë në një herë. Ndryshoni fazën 1, rilidhuni dhe lexoni regjistrin përpara se të prekni fazën 2. Kur një kombinim më në fund funksionon, shkruajeni pranë modelit të serverit dhe versionit të shtojcës, sepse paracaktimet do të lëvizin përsëri dhe pikërisht ai shënim e kthen përditësimin tjetër në një kontroll pesëminutësh.