Vai Ubuntu atjauninājums salauza L2TP/IPsec? Salīdziniet IKEv1 piedāvājumus

Savienojums darbojās ceturtdien, atjauninājums tika palaists piektdien, bet pirmdien klients griežas pie “connecting” un padodas. Tas pats klēpjdators, tas pats serveris, tas pats konts, tā pati iepriekš koplietotā atslēga. Profila failā nekas netika labots, tāpēc acīmredzamie aizdomās turamie, parole un ugunsmūris, tērē jūsu laiku.

Mainījies ir to transformāciju saraksts, ko jūsu mašīna ir gatava piedāvāt. Abi Ubuntu izmantotie IPsec steiki, strongSwan un Libreswan, izgriež algoritmus, kurus vairs neuzskata par drošiem, un to priekšā esošajam NetworkManager spraudnim ir savs saraksts, kas kustas pēc cita grafika. Serveris, kas piesaistīts 3DES, SHA1 un 1024 bitu Diffie-Hellman grupai, var beigās nedzirdēt neko, ko tas pieņem.

Ko atjauninājums patiešām mainīja

IKEv1 piedāvājumu baro divi slāņi. Dēmons piegādā kompilācijā iekļautu noklusējuma piedāvājumu kopu, un L2TP spraudnis vai nu paļaujas uz to, vai sniedz savu sarakstu. Pirms NetworkManager-l2tp 1.2.16 spraudnis paļāvās uz to, tāpēc jūsu piedāvājums bija tas, ko instalētais dēmons uzskatīja par saprātīgu. No 1.2.16 spraudnis sūta dokumentētu sarakstu, kas modelēts pēc Windows un Apple klientiem, un šis saraksts ir plašāks par veco noklusējumu, taču tajā vairs nav katras vecās kombinācijas rindas priekšgalā.

Šī sadalīšana izskaidro kļūmes veidu, ko cilvēki uzskata par mulsinošu: divas mašīnas tajā pašā Ubuntu laidienā var uzvesties atšķirīgi, jo vienai ir izplatīšanas pakotne, bet otrai ir backport, un dēmona versija abās kļūdas ziņojumā izskatās vienāda. Pirms secināt, ka atjauninājums nav mainījis neko svarīgu, pārbaudiet spraudņa versiju, ne tikai dēmona versiju.

Tajā pašā jomā ir mazākas lamatas. Divi dēmoni eliptiskās līknes Diffie-Hellman grupas raksta atšķirīgi, viens raksta ecp384, otrs ecp_384. Ielīmējiet nepareizo rakstību Advanced dialoglodziņā, un dēmons noraidīs iestatījumu kā neanalizējamu, kas žurnālā parādās kā sarunu problēma, nevis kā drukas kļūda konfigurācijā.

Izlasi kļūmi, pirms kaut ko maini

Sāciet ar to, kuru backend jūs darbinat, jo atbilde nosaka gan sintaksi, gan žurnāla atrašanās vietu.

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

Pēc tam izlasiet pašu apmaiņu. strongSwan gadījumā dēmons raksta journal pašreizējā laidienā un /var/log/syslog vecākā, un interesantā daļa ir sūtītais piedāvājums, nevis pēdējā rinda. Jūs meklējat formulējumu par to, ka nav atbilstoša piedāvājuma, kas ir algoritma problēma; autentifikācijas kļūmi, kas norāda uz atslēgu vai kontu; vai vienkāršu timeout, kas norāda uz sasniedzamību.

Šie trīs rezultāti pārāk bieži tiek uzskatīti par vienu simptomu. Timeout ar tukšu dēmona žurnālu nozīmē, ka paketes nenāk. Piedāvājuma noraidīšana nozīmē, ka tās atnāca un tika noraidītas. Ja jūsu žurnāls ir kluss, uz vienu mēģinājumu paaugstiniet spraudņa atkļūdošanas līmeni un pēc tam to pazeminiet, jo detalizētā izvade ātri piepilda journal.

1. fāze un 2. fāze ir atsevišķas likmes

IKEv1 risina sarunas divreiz. Galvenais režīms veido IKE drošības asociāciju no šifrēšanas algoritma, integritātes algoritma, Diffie-Hellman grupas un autentifikācijas metodes. Ātrais režīms pēc tam veido ESP asociāciju, kas pārvadās L2TP. Serveris var brīvi pieņemt pirmo un noraidīt otro, tāpēc pa pusei pareizs profils neizdodas vēlāk, nekā gaidāt, un izskatās kā cita kļūda.

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

Izsaukuma zīme ir strongSwan sintakse stingram ierakstam: piedāvā tikai šo vienu kombināciju un neko citu. Bez tās ieraksts pievienojas rezerves sarakstam, kas ir labi, ja partneris ir moderns, un kaitīgi, ja tas ir ierīce ar vienu stingri kodētu politiku. Uzskatiet augstāk minēto pāri par formas ilustrāciju, nevis ieteikumu kaut kam, ko šodien būvējat.

Mainiet vienu lauku, tad atkārtojiet testu

Pašreizējā spraudnī ātrākais pirmais tests ir pilnībā notīrīt abus piedāvājuma laukus un atkārtoti izveidot savienojumu, jo piegādātais noklusējuma saraksts jau ietver parastās Windows un Apple kombinācijas. Vecākā spraudnī to notīrīšana nodod kontroli atpakaļ dēmonam, kas, iespējams, jau ir izmetis algoritmu, uz kura jūsu serveris uzstāj, un kļūme kļūst sliktāka.

Ja notīrīšana nepalīdz, iestatiet stingro pāri, ko dokumentē jūsu serveris, pa vienai fāzei. Mainiet 1. fāzi, atkārtoti izveidojiet savienojumu un izlasiet žurnālu, pirms aiztiekat 2. fāzi. Kad kombinācija beidzot darbojas, pierakstiet to blakus servera modelim un spraudņa versijai, jo noklusējumi atkal mainīsies, un tieši šis pieraksts pārvērš nākamo atjauninājumu piecu minūšu pārbaudē.