L2TP: signal angheuol 15, NO_PROPOSAL_CHOSEN a modp1024 ar goll

Mae eich cysylltiad yn hongian, mae'r cleient yn gadael, a'r llinell olaf ar y sgrin yw death_handler: Fatal signal 15 received. Mae'r llinell honno yn adrodd am ataliad, nid achos. Un llinell yn gynharach yn log IPsec mae bron bob amser NO_PROPOSAL_CHOSEN, ac mae'r pâr yn pwyntio at gyfnod 2 y cyfnewid, lle mae'r naill ochr yn cymharu dewisiadau amgryptio a hash ac yn stopio pan na fydd ganddynt ddim yn gyffredin. Nid yw'r manylion mewngofnodi wedi'u hanfon ar y cam hwnnw, felly ni all ail-deipio'r cyfrinair newid y canlyniad.

Mae dau beth fel arfer yn gwagio'r croestoriad hwnnw ar gleient Linux. Efallai nad yw'r daemon lleol yn gweithredu grŵp Diffie-Hellman y mae'r proffil yn gofyn amdano mwyach, neu efallai bod y proffil yn cario cynnig cyfnod 1 mewn maes cyfnod 2. Mae'r ddau yn gadael tystiolaeth yn y log, ac nid oes yr un ohonynt yn broblem cyfrif.

Beth mae'r ddau neges yn ei ddweud mewn gwirionedd

Mae IKE yn trafod mewn cyfnodau. Mae cyfnod 1 yn adeiladu sianel warchodedig ac yn dewis ei algorithmau ei hun; mae cyfnod 2, yr SA plentyn, yn cario traffig o dan set ar wahân. NO_PROPOSAL_CHOSEN yw'r hysbysiad y mae ymatebydd yn ei ddychwelyd pan nad oes unrhyw un o'r cyfuniadau a gynigir yn dderbyniol, ac mae'n ymddangos fel [ HASH N(NO_PROP) ] y tu mewn i gyfnewid INFORMATIONAL.

Mae signal 15 yn ddigwyddiad gwahanol: rhywbeth a ddywedodd wrth y broses leol i stopio a chofnododd y triniwr hynny. Pan fydd y ddwy linell yn ymddangos gyda'i gilydd mae'r drefn yn achosol, gwrthodiad yn gyntaf ac yna cau.

Darllenwch y trafodaethau cyn cyffwrdd â manylion mewngofnodi

Codwch lefel y log lle mae'r daemon yn ysgrifennu, yna ailgysylltu wrth wylio'r allbwn. Ar westeiwr NetworkManager mae'r ategyn L2TP yn trosglwyddo'r lefel honno i'r cefn, ac mae negeseuon yn glanio yn y journal neu yn y ffeil syslog glasurol yn dibynnu ar y dosbarthiad. Bydd y naill neu'r llall yn dangos y cyfnewid: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' neu tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Mae llinell sy'n enwi pluto yn dod o libreswan, charon o strongSwan, ac mae'r ddau yn disgrifio'r un cyflwr mewn geiriau gwahanol. Y ffurf sy'n werth chwilio amdani yw'r un sy'n enwi'r grŵp sydd ar goll, fel algorithm 'modp1024' is not supported, oherwydd mae'n troi methiant annelwig yn un penodol.

Ble aeth modp1024

Mae grŵp 2 Diffie-Hellman yn ddigon gwan fel bod sawl dosbarthiad wedi rhoi'r gorau i'w grynhoi i libreswan o 3.30 ymlaen. Wedyn mae proffil a ysgrifennwyd flynyddoedd yn ôl, neu a godwyd o ganllaw porth sy'n rhestru aes128-sha1-modp1024 yn unig, yn gofyn i'r daemon lleol am rywbeth na all ei gyflawni o gwbl. Mae adeiladau NetworkManager-l2tp mwy diweddar yn gwneud y canlyniad hwnnw'n fwy tebygol: o 1.2.16 maent yn disodli'r set â chynigion ar ddull Windows 10 ac iOS ac yn gollwng modp1024 unwaith y canfyddir libreswan. Mae'r pen arall yn aml yn ddiniwed ac yn dal i gynnig yn union y grŵp a ffurfweddwyd gennych.

Yr anghymesuredd hwnnw sy'n gwneud i'r methiant deimlo'n hap. Mae cleient hŷn yn cysylltu, nid yw'r un proffil ar liniadur wedi'i ddiweddaru, ac nid yw cyfluniad y gweinydd wedi symud erioed. Mae drifft fersiwn yn gwneud y difrod.

Dau atgyweiriad ag ystod wahanol

Yr atgyweiriad rhad yw rhoi'r gorau i galedgodio algorithmau. Cliriwch y ddau faes cynnig yn y golygydd a gadewch i'r ategyn ddewis set y mae'r pen pell yn ei derbyn; os yw'r porth yn cefnogi grwpiau modern, bydd'r trafodaethau'n cwblhau heb waith pellach.

Mae'r ail atgyweiriad yn cadw hen borth yn gyrraeddadwy drwy osod strongSwan, y mae ei becynnau'n dal i weithredu grŵp 2 ar y rhan fwyaf o ddosbarthiadau. Cyfnewid daemon yw hynny, felly mae'n costio rhywbeth: cadarnhewch a yw tuneli eraill ar y gwesteiwr yn dibynnu ar gyfluniad libreswan cyn ei dynnu, a disgwyliwch wadiadau SELinux rhwng NetworkManager a'r ategyn strongSwan ar Fedora. Mae'r gwaediadau hynny'n ymddangos yn y log archwilio yn hytrach nag yn y trywydd IKE, a dyna pam y gall twnnel edrych yn doredig yn syth ar ôl gosodiad llwyddiannus. Y drefn sy'n gweithio yw dnf install strongswan yn gyntaf, yna rpm -e libreswan.

Llinynnau cynnig sy'n cyfateb, a'r trapiau o'u cwmpas

Pan fydd yn rhaid llenwi'r meysydd â llaw, mae cyfnod 1 a chyfnod 2 yn cymryd gwerthoedd gwahanol. Mae pâr y gwyddys ei fod yn gweithio yn erbyn pen ar ddull Meraki yn cynnig aes128-sha1-modp1024 yng nghyfnod 1 gyda 3des-sha1-modp1024 y tu ôl iddo, y ddau wedi'u cau gan ebychnod sy'n gwneud y set yn llym, felly dim ond y cynigion hynny a anfonir byth.

Yna mae cyfnod 2 yn culhau i aes128-sha1 a 3des-sha1 gyda'r un marc llym a heb unrhyw ôl-ddodiad Diffie-Hellman o gwbl. Mae llinell cyfnod 2 sy'n cario -modp1024 yn werth cyfnod 1 yn y maes anghywir, ac mae'r ymatebydd yn ei gwrthod ar bob ailgynnig. Copïwch y llinell honno i ail broffil ac mae'r ail broffil yn methu yr un modd, a dyna sut mae un camgymeriad teipio yn dod yn ddigwyddiad ar draws y fflyd.

Mae ffyltiau eraill yn gwisgo'r un popup heb fod yn anghydweddiadau cynnig. Ar KDE gellir rhestru'r math L2TP gyda'r ategyn wedi'i osod tra bod pob cysylltiad yn marw ar unwaith, oherwydd bod y golygydd cysylltiadau a'r cynorthwywyr amser rhedeg yn cael eu cludo fel pecynnau ar wahân. Gall gwesteiwyr heb sgrin ailddefnyddio proffil o fwrdd gwaith sy'n gweithio: copïwch ef o /etc/NetworkManager/system-connections/, gosodwch y modd i 600, yna rhedegwch nmcli con reload. Codwch ef gyda nmcli con up id work-l2tp, gan fod y ffurf noeth eisiau UUID, a thynnwch unrhyw gofnod ifname sydd wedi darfod, neu mae'r rheolwr yn ateb Could not find source connection tra bod popeth arall yn gywir.

Gellir storio allwedd a rennir ymlaen llaw fel testun clir neu fel 0s ac yna base64; mae'r ddau ffurf yn gweithio, ond rhaid i'r gwerth gyd-fynd â'r porth fesul beit, gan gynnwys unrhyw ofodau terfynol a gopïwyd gydag ef.