L2TP-ում մահացու ազդանշան 15՝ NO_PROPOSAL_CHOSEN և բացակայող modp1024

Ձեր կապը կախվում է, հաճախորդը դուրս է գալիս, և էկրանի վերջին տողը death_handler: Fatal signal 15 received է։ Այդ տողը հաղորդում է ընդհատման մասին, ոչ պատճառի։ Մեկ տող վերևում IPsec մատյանում գրեթե միշտ կա NO_PROPOSAL_CHOSEN, և զույգը մատնանշում է փոխանակության 2-րդ փուլը, որտեղ կողմերը համեմատում են գաղտնագրման և հեշի ընտրանքները և կանգ են առնում, երբ ընդհանուր ոչինչ չունեն։ Այդ փուլում մուտքի տվյալները դեռ ուղարկված չեն, ուստի գաղտնաբառի կրկնակի մուտքը չի կարող փոխել արդյունքը։

Linux հաճախորդում սովորաբար երկու բան է դատարկում այդ հատումը։ Տեղական դեմոնը կարող է այլևս չիրականացնել պրոֆիլի պահանջած Diffie-Hellman խումբը, կամ պրոֆիլը 1-ին փուլի առաջարկ է կրում 2-րդ փուլի դաշտում։ Երկուսն էլ հետք են թողնում մատյանում, և ոչ մեկը հաշվի խնդիր չէ։

Ինչ են իրականում ասում երկու հաղորդագրությունները

IKE-ն բանակցում է փուլերով։ 1-ին փուլը կառուցում է պաշտպանված ուղի և ընտրում իր ալգորիթմները. 2-րդ փուլը՝ դուստր SA-ն, տեղափոխում է երթևեկությունը առանձին հավաքածուով։ NO_PROPOSAL_CHOSEN-ը ծանուցումն է, որը պատասխանողը վերադարձնում է, երբ առաջարկված համակցություններից ոչ մեկն ընդունելի չէ, և այն հայտնվում է [ HASH N(NO_PROP) ] տեսքով INFORMATIONAL փոխանակության ներսում։

15-րդ ազդանշանը այլ դեպք է. ինչ-որ բան տեղական գործընթացին ասաց կանգ առնել, և մշակիչը գրանցեց դա։ Երբ երկու տողերը հայտնվում են միասին, հերթականությունը պատճառական է՝ նախ մերժում, ապա անջատում։

Կարդացեք բանակցությունը, նախքան մուտքի տվյալներին դիպչելը

Բարձրացրեք մատյանի մակարդակը այնտեղ, որտեղ գրում է դեմոնը, ապա նորից միացեք՝ հետևելով ելքին։ NetworkManager հոսթում L2TP հավելվածը փոխանցում է այդ մակարդակը backend-ին, և հաղորդագրությունները հայտնվում են journal-ում կամ դասական syslog ֆայլում՝ կախված տարածումից։ Այս երկուսից որևէ մեկը ցույց կտա փոխանակությունը՝ journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' կամ tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'։

pluto-ն անվանող տողը գալիս է libreswan-ից, charon-ը՝ strongSwan-ից, և երկուսն էլ նույն վիճակը նկարագրում են տարբեր բառերով։ Որոնելու արժանի ձևն այն է, որը անվանում է բացակայող խումբը, օրինակ՝ algorithm 'modp1024' is not supported, որովհետև այն անորոշ ձախողումը դարձնում է կոնկրետ։

Ուր գնաց modp1024-ը

Diffie-Hellman 2-րդ խումբն այնքան թույլ է, որ մի քանի տարածումներ դադարեցրին այն libreswan-ում կոմպիլյացնելը 3.30-ից սկսած։ Այն ժամանակ տարիներ առաջ գրված պրոֆիլը կամ միայն aes128-sha1-modp1024 թվարկող դարպասի ուղեցույցից վերցվածը տեղական դեմոնից պահանջում է մի բան, որն այն ընդհանրապես չի կարող կատարել։ NetworkManager-l2tp-ի նոր կառուցումները այդ ելքը դարձնում են ավելի հավանական. 1.2.16-ից նրանք հավաքածուն փոխարինում են Windows 10-ի և iOS-ի ոճի առաջարկներով և դեն են նետում modp1024-ը, հենց որ հայտնաբերվում է libreswan-ը։ Հակառակ կողմը հաճախ անմեղ է և դեռ առաջարկում է հենց այն խումբը, որը դուք կարգավորել եք։

Այդ անհամաչափությունն է, որ ձախողումը պատահական է թվում։ Ավելի հին հաճախորդը միանում է, նույն պրոֆիլը թարմացված նոթբուքի վրա՝ ոչ, և սերվերի կարգավորումը երբեք չի շարժվել։ Վնասը հասցնում է տարբերակների շեղումը։

Երկու վերանորոգում՝ տարբեր ազդեցության շառավղով

Էժան վերանորոգումը ալգորիթմները ձեռքով ամրագրելը դադարեցնելն է։ Դատարկեք առաջարկների երկու դաշտերը խմբագրիչում և թողեք հավելվածը ընտրի հավաքածու, որն ընդունում է հեռավոր կողմը. եթե դարպասը սատարում է ժամանակակից խմբերին, բանակցությունը ավարտվում է առանց լրացուցիչ աշխատանքի։

Երկրորդ վերանորոգումը հին դարպասը հասանելի է պահում strongSwan-ի տեղադրմամբ, որի փաթեթները դեռ իրականացնում են 2-րդ խումբը տարածումների մեծ մասում։ Դա դեմոնի փոխարինում է, ուստի գին ունի. ստուգեք՝ արդյոք հոսթի այլ թունելները կախված են libreswan-ի կարգավորումից նախքան այն հեռացնելը, և Fedora-ում սպասեք SELinux մերժումների NetworkManager-ի և strongSwan հավելվածի միջև։ Այդ մերժումները հայտնվում են աուդիտի մատյանում, ոչ թե IKE հետքի մեջ, դրա համար թունելը կարող է կոտրված թվալ հաջող տեղադրումից անմիջապես հետո։ Աշխատող հերթականությունը սա է՝ նախ dnf install strongswan, ապա rpm -e libreswan։

Համապատասխան առաջարկների շարքեր և դրանց շուրջ թակարդները

Երբ դաշտերը պետք է ձեռքով լրացնել, 1-ին և 2-րդ փուլերը տարբեր արժեքներ են վերցնում։ Meraki ոճի հակառակորդի դեմ աշխատող հայտնի զույգը 1-ին փուլում առաջարկում է aes128-sha1-modp1024, դրա հետևում՝ 3des-sha1-modp1024, երկուսն էլ փակված բացականչական նշանով, որը հավաքածուն դարձնում է խիստ, ուստի ուղարկվում են միայն այդ առաջարկները։

Այնուհետև 2-րդ փուլը նեղանում է մինչև aes128-sha1 և 3des-sha1՝ նույն խիստ նշանով և առանց Diffie-Hellman վերջածանցի։ -modp1024 կրող 2-րդ փուլի տողը 1-ին փուլի արժեք է սխալ դաշտում, և պատասխանողը մերժում է այն յուրաքանչյուր կրկնության ժամանակ։ Պատճենեք այդ տողը երկրորդ պրոֆիլի մեջ, և երկրորդ պրոֆիլը նույն կերպ ձախողվում է, և այդպես մեկ տպագրական սխալը դառնում է ամբողջ նավատորմի միջադեպ։

Այլ խափանումներ կրում են նույն ելնող պատուհանը՝ չլինելով առաջարկների անհամապատասխանություն։ KDE-ում L2TP տեսակը կարող է ցուցակված լինել հավելվածի տեղադրմամբ, մինչդեռ յուրաքանչյուր միացում անմիջապես մահանում է, որովհետև միացումների խմբագրիչը և գործարկման ժամանակի օգնականները մատակարարվում են առանձին փաթեթներով։ Էկրան չունեցող հոսթերը կարող են կրկին օգտագործել պրոֆիլ աշխատող աշխատասեղանից. պատճենեք այն /etc/NetworkManager/system-connections/-ից, դրեք ռեժիմը 600-ի, ապա գործարկեք nmcli con reload։ Բարձրացրեք այն nmcli con up id work-l2tp-ով, քանի որ մերկ ձևը UUID է պահանջում, և հեռացրեք ցանկացած հնացած ifname գրառում, այլապես կառավարիչը պատասխանում է Could not find source connection-ով, մինչդեռ մնացած ամեն ինչ ճիշտ է։

Նախապես կիսված բանալին կարող է պահվել որպես բաց տեքստ կամ որպես 0s և դրանից հետո base64. երկու ձևն էլ աշխատում է, բայց արժեքը պետք է համընկնի դարպասի հետ բայթ առ բայթ, ներառյալ վերջի բացատները, որոնք դուք պատճենել եք դրա հետ միասին։