Ubuntu-opgradering het L2TP/IPsec gebreek? Vergelyk die IKEv1-voorstelle

Die verbinding het Donderdag gewerk, die opgradering het Vrydag geloop, en Maandag draai die kliënt by “connecting” en gee op. Dieselfde skootrekenaar, dieselfde bediener, dieselfde rekening, dieselfde vooraf gedeelde sleutel. Niks in die profiel is gewysig nie, en daarom mors die ooglopende verdagtes, die wagwoord en die vuurmuur, jou tyd.

Wat verander het, is die lys transformasies wat jou masjien bereid is om aan te bied. Albei IPsec-stapels wat op Ubuntu gebruik word, strongSwan en Libreswan, sny algoritmes weg wat hulle nie meer as veilig beskou nie, en die NetworkManager-inprop wat voor hulle sit, het sy eie lys wat volgens ’n ander skedule beweeg. ’n Bediener wat aan 3DES, SHA1 en ’n 1024-bis Diffie-Hellman-groep vasgepen is, kan uiteindelik niks hoor wat hy aanvaar nie.

Wat die opgradering werklik verander het

Twee lae voed die IKEv1-aanbod. Die daemon lewer ’n ingeboude verstek-voorstelstel, en die L2TP-inprop gee óf daaraan oor óf verskaf sy eie lys. Voor NetworkManager-l2tp 1.2.16 het die inprop oorgegee, so jou aanbod was wat die geïnstalleerde daemon redelik geag het. Vanaf 1.2.16 stuur die inprop ’n gedokumenteerde lys wat op Windows- en Apple-kliënte gemodelleer is, en daardie lys is breër as die ou verstek maar bevat nie meer elke legacy-kombinasie voor in die tou nie.

Daardie skeiding verduidelik ’n foutmodus wat mense verwarrend vind: twee masjiene op dieselfde Ubuntu-vrystelling kan verskillend optree omdat een die verspreidingspakket het en die ander ’n backport, en die daemon-weergawe op albei lyk identies in ’n foutrapport. Kontroleer die inprop-weergawe, nie net die daemon-weergawe nie, voordat jy aflei dat die opgradering niks relevants verander het nie.

Daar is ’n kleiner valstrik in dieselfde area. Die twee daemons spel die elliptiese-kromme Diffie-Hellman-groepe verskillend, die een skryf ecp384 en die ander ecp_384. Plak die verkeerde spelling in die Gevorderde-dialoog en die daemon verwerp die instelling as onparseerbaar, wat in die log na vore kom as ’n onderhandelingsprobleem eerder as ’n konfigurasietikfout.

Lees die fout voordat jy iets verander

Begin met watter backend jy gebruik, want die antwoord bepaal beide die sintaksis en die ligging van die log.

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

Lees dan die uitruiling self. Op strongSwan skryf die daemon na die joernaal op ’n huidige vrystelling en na /var/log/syslog op ’n ouer een, en die interessante deel is die voorstel wat dit stuur, nie die laaste reël nie. Jy soek bewoording oor geen passende voorstel nie, wat ’n algoritmeprobleem is; ’n verifikasiefout, wat na die sleutel of die rekening wys; of ’n gewone tydsverloop, wat na bereikbaarheid wys.

Daardie drie uitkomste word veel te dikwels as een simptoom behandel. ’n Tydsverloop met ’n leë daemon-log beteken die pakkette kom nie aan nie. ’n Voorstelverwerping beteken hulle het aangekom en is geweier. As jou log stil is, verhoog die inprop se ontfoutvlak vir een poging en verlaag dit daarna, want die uitvoerige uitset vul ’n joernaal vinnig.

Fase 1 en fase 2 is aparte weddenskappe

IKEv1 onderhandel twee keer. Hoofmodus bou die IKE-veiligheidsassosiasie uit ’n enkripsie-algoritme, ’n integriteitsalgoritme, ’n Diffie-Hellman-groep en ’n verifikasiemetode. Vinnige modus bou dan die ESP-assosiasie wat L2TP sal dra. ’n Bediener is vry om die eerste te aanvaar en die tweede te verwerp, so ’n halfkorrekte profiel misluk later as wat jy verwag en lyk soos ’n ander fout.

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

Die uitroepteken is strongSwan-sintaksis vir ’n streng inskrywing: bied hierdie een kombinasie en niks anders nie. Sonder dit sluit die inskrywing by ’n terugvallys aan, wat goed is wanneer die eweknie modern is en teenproduktief wanneer dit ’n toestel met ’n enkele hardgekodeerde beleid is. Besien die paar hierbo as ’n illustrasie van die vorm, nie as ’n aanbeveling vir enigiets wat jy vandag bou nie.

Verander een veld, herhaal dan die toets

Op ’n huidige inprop is die vinnigste eerste toets om albei voorstelvelde heeltemal skoon te maak en weer te koppel, want die meegeleverde versteklys sluit reeds die algemene Windows- en Apple-kombinasies in. Op ’n ouer inprop gee skoonmaak beheer terug aan ’n daemon wat dalk die algoritme laat vaar het waarop jou bediener aandring, en die fout word erger.

As skoonmaak nie help nie, stel die streng paar in wat jou bediener dokumenteer, een fase op ’n slag. Verander fase 1, koppel weer, en lees die log voordat jy aan fase 2 raak. Wanneer ’n kombinasie uiteindelik werk, skryf dit neer langs die bedienermodel en die inprop-weergawe, want die verstekke sal weer beweeg en daardie nota is wat die volgende opgradering in ’n vyfminuut-toets verander.