L2TP: nakamamatay na signal 15, NO_PROPOSAL_CHOSEN at nawawalang modp1024

Nag-hang ang koneksyon mo, lumalabas ang client, at ang huling linya sa screen ay death_handler: Fatal signal 15 received. Ang linyang iyon ay nag-uulat ng pagkaputol, hindi ng dahilan. Isang linya pataas sa log ng IPsec ay halos palaging may NO_PROPOSAL_CHOSEN, at ang pares ay tumuturo sa phase 2 ng palitan, kung saan inihahambing ng dalawang panig ang mga pagpipilian sa encryption at hash at humihinto kapag wala silang anumang pareho. Hindi pa naipapadala ang mga kredensyal sa yugtong iyon, kaya ang muling pag-type ng password ay hindi makapagbabago ng resulta.

Karaniwang may dalawang bagay na nagpapaubos sa intersection na iyon sa isang Linux client. Maaaring hindi na ipatupad ng lokal na daemon ang group na Diffie-Hellman na hinihiling ng profile, o maaaring may dalang proposal ng phase 1 ang profile sa field ng phase 2. Pareho silang nag-iiwan ng bakas sa log, at wala sa kanila ang problema sa account.

Ano ang aktuwal na sinasabi ng dalawang mensahe

Nag-uusap ang IKE sa mga yugto. Ang phase 1 ay gumagawa ng protektadong channel at pumipili ng sarili nitong algorithm; ang phase 2, ang child SA, ay nagdadala ng traffic sa ilalim ng hiwalay na set. Ang NO_PROPOSAL_CHOSEN ay ang notification na ibinabalik ng responder kapag wala sa mga inalok na kombinasyon ang katanggap-tanggap, at lumalabas ito bilang [ HASH N(NO_PROP) ] sa loob ng palitan ng INFORMATIONAL.

Ang signal 15 ay ibang pangyayari: may nagsabi sa lokal na proseso na huminto at naitala ito ng handler. Kapag lumitaw ang dalawang linya nang magkasama, ang pagkakasunod-sunod ay sanhi, una ang pagtanggi at pagkatapos ang pagpatay.

Basahin ang negosasyon bago hawakan ang mga kredensyal

Itaas ang antas ng log sa lugar kung saan nagsusulat ang daemon, pagkatapos ay kumonekta muli habang pinanonood ang output. Sa host na may NetworkManager, ipinapasa ng L2TP plugin ang antas na iyon sa backend, at ang mga mensahe ay napupunta sa journal o sa klasikong file ng syslog depende sa distribution. Alinman sa mga ito ay magpapakita ng palitan: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' o tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Ang linyang nagbabanggit ng pluto ay galing sa libreswan, ang charon ay mula sa strongSwan, at pareho nilang inilalarawan ang parehong kalagayan sa magkaibang salita. Ang anyong nagkakahalaga ng hanapin ay ang nagbabanggit ng nawawalang group, halimbawa algorithm 'modp1024' is not supported, dahil ginagawa nitong tiyak ang malabong pagkabigo.

Saan napunta ang modp1024

Ang group 2 ng Diffie-Hellman ay sapat na mahina kaya ilang distribution ang tumigil sa pag-compile nito sa libreswan mula 3.30 pataas. Kung gayon ang isang profile na isinulat mga taon na ang nakalipas, o kinuha mula sa gabay ng gateway na naglilista lamang ng aes128-sha1-modp1024, ay humihiling sa lokal na daemon ng isang bagay na hindi nito kayang gawin. Ginagawa ng mas bagong build ng NetworkManager-l2tp na mas malamang ang resulta: mula 1.2.16 pinapalitan nila ang set ng mga proposal na istilong Windows 10 at iOS at iniiwan ang modp1024 sa sandaling matukoy ang libreswan. Kadalasang inosente ang kabilang dulo at nag-aalok pa rin ng eksaktong group na inayos mo.

Ang asimetriyang iyon ang dahilan kung bakit parang random ang pagkabigo. Kumokonekta ang lumang client, hindi kumokonekta ang parehong profile sa updated na laptop, at hindi kailanman gumalaw ang configuration ng server. Ang pinsala ay dulot ng paghihiwalay ng mga bersyon.

Dalawang pag-aayos na may magkaibang saklaw

Ang murang pag-aayos ay ang tigilan ang pag-hard-code ng mga algorithm. I-clear ang dalawang field ng proposal sa editor at hayaang pumili ang plugin ng set na tinatanggap ng malayong dulo; kung sinusuportahan ng gateway ang mga modernong group, natatapos ang negosasyon nang walang karagdagang gawain.

Ang ikalawang pag-aayos ay pinapanatiling maabot ang lumang gateway sa pamamagitan ng pag-install ng strongSwan, na ang mga package ay nagpapatupad pa rin ng group 2 sa karamihan ng distribution. Iyon ay pagpapalit ng daemon, kaya may halaga ito: tiyakin kung ang iba pang tunnel sa host ay umaasa sa configuration ng libreswan bago ito alisin, at asahan ang mga pagtanggi ng SELinux sa pagitan ng NetworkManager at ng strongSwan plugin sa Fedora. Lumalabas ang mga pagtanggi na iyon sa audit log at hindi sa trace ng IKE, kaya maaaring magmukhang sira ang tunnel kaagad pagkatapos ng matagumpay na pag-install. Ang gumaganang pagkakasunod-sunod ay dnf install strongswan muna, pagkatapos ang rpm -e libreswan.

Mga string ng proposal na tugma, at ang mga bitag sa paligid

Kapag kailangang punan ang mga field nang manu-mano, magkaibang value ang kinukuha ng phase 1 at phase 2. Ang pares na kilalang gumagana laban sa dulong istilong Meraki ay nag-aalok ng aes128-sha1-modp1024 sa phase 1 na may 3des-sha1-modp1024 sa likod, parehong isinara ng tandang padamdam na nagpapatingkad sa set, kaya ang mga proposal na iyon lamang ang ipinapadala.

Pagkatapos ay pumayat ang phase 2 sa aes128-sha1 at 3des-sha1 na may parehong mahigpit na marker at walang anumang suffix ng Diffie-Hellman. Ang linya ng phase 2 na may -modp1024 ay value ng phase 1 sa maling field, at tinatanggihan ito ng responder sa bawat pagtatangka. Kopyahin ang linyang iyon sa ikalawang profile at nabibigo rin ang ikalawang profile sa parehong paraan, at ganoon nagiging insidente sa buong fleet ang isang typo.

Ang ibang depekto ay nagsusuot ng parehong popup nang hindi mismatch ng proposal. Sa KDE maaaring nakalista ang uri ng L2TP na naka-install ang plugin habang namamatay agad ang bawat koneksyon, dahil hiwalay na package ang editor ng koneksyon at ang mga runtime helper. Maaaring gumamit muli ang mga host na walang screen ng profile mula sa gumaganang desktop: kopyahin ito mula sa /etc/NetworkManager/system-connections/, itakda ang mode sa 600, pagkatapos ay patakbuhin ang nmcli con reload. Itaas ito gamit ang nmcli con up id work-l2tp, dahil kailangan ng hubad na anyo ang UUID, at alisin ang anumang lumang entry ng ifname, kung hindi ay sumasagot ang manager ng Could not find source connection habang tama ang lahat ng iba.

Ang paunang ibinahaging key ay maaaring itago bilang plain text o bilang 0s na sinusundan ng base64; gumagana ang dalawang anyo, ngunit dapat tumugma ang value sa gateway byte sa byte, kasama ang mga puwang sa dulo na kinopya mo kasama nito.