L2TP: fataal sinjaal 15, NO_PROPOSAL_CHOSEN en ûntbrekkende modp1024

Dyn ferbining hinget, de klient slút ôf, en de lêste rigel op it skerm is death_handler: Fatal signal 15 received. Dy rigel meldt in ôfbrekking, net in oarsaak. Ien rigel earder yn it IPsec-log stiet hast altyd NO_PROPOSAL_CHOSEN, en it pear wiist nei faze 2 fan de útwikseling, dêr't de partijen fersifering- en hashkarren fergelykje en stopje as se neat mienskiplik hawwe. Oanmeldgegevens binne yn dy faze noch net ferstjoerd, dus it wachtwurd opnij typen kin it resultaat net feroarje.

Twa dingen meitsje dat krúspunt meastentiids leech op in Linux-klient. De lokale daemon ymplemintearret miskien net mear de Diffie-Hellman-groep dy't it profyl freget, of it profyl draacht in foarstel fan faze 1 yn in fjild fan faze 2. Beide litte spoaren yn it log, en gjinien is in akkountprobleem.

Wat de beide berjochten eins sizze

IKE ûnderhannelt yn rûnden. Faze 1 bout in beskerme kanaal en kiest syn eigen algoritmen; faze 2, de bern-SA, draacht ferkear ûnder in aparte set. NO_PROPOSAL_CHOSEN is de notifikaasje dy't in antwurder weromstjoert as gjin fan 'e oanbeane kombinaasjes akseptabel is, en hy ferskynt as [ HASH N(NO_PROP) ] binnen in INFORMATIONAL-útwikseling.

Sinjaal 15 is in oare barring: eat hat it lokale proses sein om te stopjen en de handler hat dat logd. As beide rigels tegearre ferskine is de folchoarder kausaal, earst ôfwizing en dan it útskeakeljen.

Lês de ûnderhanneling foardatst oanmeldgegevens oanrekest

Ferheegje it lognivo dêr't de daemon skriuwt, en ferbyn dan opnij wylstst de útfier besjochst. Op in NetworkManager-host jout de L2TP-ynstekker dat nivo troch oan de backend, en berjochten komme yn it journal of yn it klassike syslog-bestân ôfhinklik fan de distribúsje. Ien fan beide sil de útwikseling sjen litte: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' of tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

In rigel dy't pluto neamt komt fan libreswan, charon fan strongSwan, en beide beskriuwe deselde tastân mei oare wurden. De foarm dy't it sykjen wurdich is, is dy't de ûntbrekkende groep neamt, bygelyks algorithm 'modp1024' is not supported, want hy makket fan in ûndúdlike flater in konkrete.

Wêr't modp1024 bleaun is

Diffie-Hellman-groep 2 is swak genôch dat ferskate distribúsjes him fan 3.30 ôf net mear yn libreswan kompilearren. Dan freget in profyl dat jierren lyn skreaun is, of út in gateway-gids helle is dy't allinnich aes128-sha1-modp1024 neamt, de lokale daemon eat dat er hielendal net dwaan kin. Nijere NetworkManager-l2tp-builts meitsje dat resultaat wierskynliker: fan 1.2.16 ôf ferfange se de set troch foarstellen yn 'e styl fan Windows 10 en iOS en litte modp1024 falle sadree't libreswan detektearre wurdt. De oare kant is faaks ûnskuldich en biedt noch altyd krekt de groep oan dy'tsto konfigurearre hast.

Dy asymmetry is wat de flater tafallich lykje lit. In âldere klient ferbynt, itselde profyl op in bywurke laptop net, en de serverkonfiguraasje is nea ferhuze. Skaai troch ferzjes docht de skea.

Twa reparaasjes mei ferskillende ynfloed

De goedkeape reparaasje is ophâlde mei algoritmen hurd te kodearjen. Meitsje beide foarstelfjilden yn 'e bewurker leech en lit de ynstekker in set kieze dy't de fiere kant akseptearret; as de gateway moderne groepen stipet, einiget de ûnderhanneling sûnder fierder wurk.

De twadde reparaasje hâldt in âlde gateway berikber troch strongSwan te ynstallearjen, waans pakketten op de measte distribúsjes noch groep 2 ymplemintearje. Dat is in daemonwiksel, dus it kostet wat: kontrolearje oft oare tunnels op 'e host fan libreswan-konfiguraasje ôfhinklik binne foardatst dy fuorthelst, en ferwachtsje SELinux-ôfwizings tusken NetworkManager en de strongSwan-ynstekker op Fedora. Dy ôfwizings ferskine yn it auditlog, net yn it IKE-spoar, en dêrom kin in tunnel krekt nei in slagge ynstallaasje stikken lykje. De folchoarder dy't wurket is earst dnf install strongswan, dan rpm -e libreswan.

Foarstelstrengen dy't passe, en de fallen deromhinne

As de fjilden mei de hân folle wurde moatte, nimme faze 1 en faze 2 ferskillende wearden. In pear dat bekend stiet as wurkjend tsjin in tsjinpartij yn Meraki-styl biedt aes128-sha1-modp1024 yn faze 1 mei 3des-sha1-modp1024 dêrefter, beide sletten troch in útropteken dat de set strang makket, sadat allinnich dy foarstellen ea ferstjoerd wurde.

Dêrnei ferlingt faze 2 nei aes128-sha1 en 3des-sha1 mei deselde strange marker en hielendal gjin Diffie-Hellman-efterheaksel. In rigel fan faze 2 dy't -modp1024 draacht is in wearde fan faze 1 yn it ferkearde fjild, en de antwurder wiist him by elke poging ôf. Kopiearje dy rigel nei in twadde profyl en it twadde profyl mislearret itselde, en sa wurdt ien typflater in ynsidint foar de hiele float.

Oare flaters drage deselde popup sûnder foarstel-mismatches te wêzen. Op KDE kin it L2TP-type neamd wurde mei de ynstekker ynstallearre wylst elke ferbining daliks dea giet, om't de ferbiningsbewurker en de runtime-helpers as aparte pakketten levere wurde. Hosts sûnder skerm kinne in profyl fan in wurkjend buroblêd werbrûke: kopiearje it út /etc/NetworkManager/system-connections/, set de modus op 600, en fier dan nmcli con reload út. Bring it omheech mei nmcli con up id work-l2tp, om't de neakene foarm in UUID wol, en ferwiderje elk ferâldere ifname-ynfier, oars antwurdet de behearder Could not find source connection wylst al it oare kloppet.

In foarôf dielde kaai kin as iepen tekst bewarre wurde of as 0s folge troch base64; beide foarmen wurkje, mar de wearde moat byte foar byte by de gateway passe, ynklusyf de efterste romtes dy'tst der mei kopiearre hast.