Hat de Ubuntu-upgrade L2TP/IPsec brutsen? Fergelykje de IKEv1-foarstellen

De ferbining wurke tongersdei, de upgrade rûn freed, en moandei draait de klient by “connecting” en jout it op. Deselde laptop, deselde tsjinner, deselde account, deselde foarôf dielde kaai. Der is neat yn it profyl bewurke, en dêrom ferspiizje de fanselssprekkende fertochten, it wachtwurd en de firewall, jo tiid.

Wat feroare is, is de list fan transformaasjes dy't jo masine ree is oan te bieden. Beide IPsec-stacks dy't op Ubuntu brûkt wurde, strongSwan en Libreswan, snije algoritmen fuort dy't se net mear feilich fine, en de NetworkManager-plug-in dy't harren foaroan stiet hat syn eigen list, dy't op in oar skema beweecht. In tsjinner dy't fêstset is op 3DES, SHA1 en in Diffie-Hellman-groep fan 1024 bit kin úteinlik neat hearre dat er akseptearret.

Wat de upgrade eins feroare hat

Twa lagen fiede it IKEv1-foarstel. De daemon leveret in ynkompilearre standertfoarstellingsset, en de L2TP-plug-in fertrout dêrop of leveret syn eigen list. Foar NetworkManager-l2tp 1.2.16 fertrout de plug-in dêrop, dus jo foarstel wie wat de ynstalleare daemon ridlik fûn. Fan 1.2.16 ôf stjoert de plug-in in dokumintearre list, modelearre op Windows- en Apple-klanten, en dy list is breder as de âlde standert mar befettet net mear elke âlde kombinaasje foaroan yn 'e rige.

Dy splitsing ferklearret in mislearringsmodus dy't minsken betiizjend fine: twa masines op deselde Ubuntu-útjefte kinne har oars gedrage om't de iene it distribúsjepakket hat en de oare in backport, en de daemonferzje op beide liket identyk yn in flaterrapport. Kontrolearje de plug-inferzje, net allinnich de daemonferzje, foardat jo konkludearje dat de upgrade neat relevants feroare hat.

Der is in lytsere falstrik yn itselde gebiet. De beide daemons skriuwe de Diffie-Hellman-groepen fan 'e elliptyske kromme oars, de iene skriuwt ecp384 en de oare ecp_384. Plak de ferkearde stavering yn 'e Advanced-dialooch en de daemon wiist de ynstelling ôf as net-parseber, wat yn it logboek as in ûnderhannelingsprobleem ferskynt en net as in typflater yn 'e konfiguraasje.

Lês de mislearring foardat jo wat feroarje

Begjin mei hokker backend jo draaie, want it antwurd bepaalt sawol de syntaksis as it plak fan it logboek.

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

Lês dan de útwikseling sels. Op strongSwan skriuwt de daemon nei it journal op in aktuele útjefte en nei /var/log/syslog op in âldere, en it nijsgjirrige part is it foarstel dat er stjoert, net de lêste rigel. Jo sykje nei wurden oer gjin passend foarstel, wat in algoritmeprobleem is; in autentikaasjeflater, dy't nei de kaai of it account wiist; of in gewoane timeout, dy't nei berikberens wiist.

Dizze trije útkomsten wurde folle te faak as ien symptoom behannele. In timeout mei in leech daemonlogboek betsjut dat de pakketten net oankomme. In ôfwizing fan it foarstel betsjut dat se oankamen en wegere waarden. As jo logboek stil is, ferheegje dan it debugnivo fan 'e plug-in foar ien besykjen en ferleegje it dêrnei, want de wiidweidige útfier follet in journal fluch.

Faze 1 en faze 2 binne aparte weddenskippen

IKEv1 ûnderhannelet twa kear. De haadmodus bout de IKE-feiligensassosjaasje út in fersiferingalgoritme, in yntegriteitsalgoritme, in Diffie-Hellman-groep en in autentikaasjemetoade. De flugge modus bout dan de ESP-assosjaasje dy't L2TP drage sil. In tsjinner is frij om de earste te akseptearjen en de twadde ôf te wizen, dus in heal korrekt profyl mislearret letter as jo ferwachtsje en liket op in oare flater.

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

It útropteken is strongSwan-syntaksis foar in strikte ynfier: bied dizze iene kombinaasje en neat oars. Sûnder dat docht de ynfier mei oan in fallbacklist, wat goed is as de peer modern is en tsjinproduktyf as it in apparaat is mei ien hurd kodearre belied. Besjoch it pear hjirboppe as in yllustraasje fan 'e foarm, net as in oanbefelling foar wat jo hjoed bouwe.

Feroarje ien fjild, werhelje dan de test

Op in aktuele plug-in is de fluchste earste test beide foarstelfjilden hielendal leegje en opnij ferbine, want de levere standertlist befettet al de gewoane Windows- en Apple-kombinaasjes. Op in âldere plug-in jout it leegjen fan se de kontrôle werom oan in daemon dy't it algoritme dat jo tsjinner easket miskien fuortlitten hat, en de flater wurdt slimmer.

As leegje net helpt, stel dan it strikte pear yn dat jo tsjinner dokumintearret, ien faze tagelyk. Feroarje faze 1, ferbyn opnij, en lês it logboek foardat jo faze 2 oanreitsje. As in kombinaasje úteinlik wurket, skriuw it dan njonken it tsjinnermodel en de plug-inferzje, want de standerten sille wer bewege en dy notysje is wat de folgjende upgrade yn in fiifminutenkontrôle feroaret.