L2TP: mortiga signalo 15, NO_PROPOSAL_CHOSEN kaj mankanta modp1024

Via konekto haltas, la kliento eliras, kaj la lasta linio sur la ekrano estas death_handler: Fatal signal 15 received. Tiu linio raportas ĉesigon, ne kaŭzon. Unu linion pli frue en la IPsec-protokolo preskaŭ ĉiam estas NO_PROPOSAL_CHOSEN, kaj la paro montras al fazo 2 de la interŝanĝo, kie la flankoj komparas elektojn de ĉifrado kaj haketado kaj haltas kiam ili havas neniun komunan. Akreditiloj ankoraŭ ne estas senditaj en tiu stadio, do retajpado de la pasvorto ne povas ŝanĝi la rezulton.

Kutime du aferoj malplenigas tiun komunan parton en Linux-kliento. La loka demono eble ne plu realigas la grupon Diffie-Hellman, kiun la profilo postulas, aŭ la profilo portas proponon de fazo 1 en kampo de fazo 2. Ambaŭ lasas spurojn en la protokolo, kaj nek unu estas problemo pri konto.

Kion la du mesaĝoj efektive diras

IKE intertraktas laŭ etapoj. Fazo 1 konstruas protektitan kanalon kaj elektas proprajn algoritmojn; fazo 2, la ida SA, portas trafikon laŭ aparta aro. NO_PROPOSAL_CHOSEN estas la sciigo, kiun respondanto resendas kiam neniu el la proponitaj kombinoj estas akceptebla, kaj ĝi aperas kiel [ HASH N(NO_PROP) ] ene de INFORMATIONAL-interŝanĝo.

Signalo 15 estas alia evento: io ordonis al la loka procezo halti kaj la traktilo registris tion. Kiam ambaŭ linioj aperas kune, la ordo estas kaŭza, unue rifuzo kaj poste malŝalto.

Legu la intertraktadon antaŭ ol tuŝi akreditilojn

Altigu la protokolan nivelon tie, kie la demono skribas, kaj poste rekonektu dum vi observas la eligon. Sur NetworkManager-gastiganto la L2TP-kromaĵo transdonas tiun nivelon al la malantaŭa parto, kaj mesaĝoj alvenas en la ĵurnalon aŭ en la klasikan syslog-dosieron laŭ la distribuo. Iu ajn el ĉi tiuj montros la interŝanĝon: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' aŭ tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Linio kun pluto venas de libreswan, charon de strongSwan, kaj ambaŭ priskribas la saman staton per malsamaj vortoj. La formo inda serĉi estas tiu, kiu nomas la mankantan grupon, ekzemple algorithm 'modp1024' is not supported, ĉar ĝi transformas malprecizan fiaskon en precizan.

Kien iris modp1024

Grupo 2 de Diffie-Hellman estas sufiĉe malforta, ke pluraj distribuoj ĉesis kompili ĝin en libreswan ekde 3.30. Tiam profilo skribita antaŭ jaroj, aŭ prenita el gvidilo pri pordego, kiu listigas nur aes128-sha1-modp1024, postulas de la loka demono ion, kion ĝi tute ne povas plenumi. Pli novaj konstruaĵoj de NetworkManager-l2tp igas tiun rezulton pli verŝajna: ekde 1.2.16 ili anstataŭigas la aron per proponoj laŭ stilo Windows 10 kaj iOS kaj forlasas modp1024 tuj kiam libreswan estas detektita. La kontraŭa flanko ofte estas senkulpa kaj plu proponas ĝuste la grupon, kiun vi agordis.

Ĝuste tiu malsimetrio igas la fiaskon ŝajni hazarda. Pli malnova kliento konektiĝas, la sama profilo sur ĝisdatigita tekokomputilo ne, kaj la servila agordo neniam moviĝis. La damaĝon faras la versia drivo.

Du riparoj kun malsama amplekso

La malmultekosta riparo estas ĉesi malmoligi algoritmojn. Malplenigu ambaŭ proponajn kampojn en la redaktilo kaj lasu la kromaĵon elekti aron, kiun la fora flanko akceptas; se la pordego subtenas modernajn grupojn, la intertraktado finiĝas sen plia laboro.

La dua riparo tenas malnovan pordegon atingebla per instalado de strongSwan, kies pakaĵoj ankoraŭ realigas grupon 2 en plej multaj distribuoj. Tio estas anstataŭigo de demono, do ĝi kostas ion: kontrolu, ĉu aliaj tuneloj sur la gastiganto dependas de la agordo de libreswan antaŭ ol forigi ĝin, kaj atendu rifuzojn de SELinux inter NetworkManager kaj la strongSwan-kromaĵo en Fedora. Tiuj rifuzoj aperas en la revizia protokolo, ne en la IKE-spuro, kaj tial tunelo povas aspekti rompita tuj post sukcesa instalado. La ordo, kiu funkcias, estas unue dnf install strongswan, poste rpm -e libreswan.

Proponaj ĉenoj, kiuj kongruas, kaj la kaptiloj ĉirkaŭ ili

Kiam la kampojn oni devas plenigi permane, fazo 1 kaj fazo 2 prenas malsamajn valorojn. Paro konata kiel funkcianta kontraŭ kontraŭulo laŭ stilo Meraki proponas aes128-sha1-modp1024 en fazo 1 kun 3des-sha1-modp1024 malantaŭ ĝi, ambaŭ fermitaj per krisigno, kiu igas la aron strikta, do nur tiuj proponoj estas iam senditaj.

Poste fazo 2 mallarĝiĝas al aes128-sha1 kaj 3des-sha1 kun la sama strikta markilo kaj tute sen sufikso Diffie-Hellman. Linio de fazo 2 portanta -modp1024 estas valoro de fazo 1 en la malĝusta kampo, kaj la respondanto rifuzas ĝin ĉe ĉiu reprovo. Kopiu tiun linion en duan profilon kaj la dua profilo fiaskas same, kaj tiel unu tajperaro fariĝas tutflota incidento.

Aliaj fuŝoj portas la saman ŝprucfenestron sen esti malkongruoj de proponoj. En KDE la tipo L2TP povas esti listigita kun la kromaĵo instalita dum ĉiu konekto tuj mortas, ĉar la konekta redaktilo kaj la ruladtempaj helpiloj estas liverataj kiel apartaj pakaĵoj. Senkapaj gastigantoj povas reuzi profilon de funkcianta labortablo: kopiu ĝin el /etc/NetworkManager/system-connections/, agordu la reĝimon al 600, poste rulu nmcli con reload. Levu ĝin per nmcli con up id work-l2tp, ĉar la nuda formo postulas UUID, kaj forigu ĉiun malnoviĝintan ifname-eron, alie la administrilo respondas Could not find source connection dum ĉio alia estas ĝusta.

Antaŭe kunhavata ŝlosilo povas esti konservita kiel klara teksto aŭ kiel 0s sekvata de base64; ambaŭ formoj funkcias, sed la valoro devas kongrui kun la pordego bajte post bajto, inkluzive de finaj spacoj, kiujn vi kopiis kun ĝi.