L2TP NO_PROPOSAL_CHOSEN: ո՞ր փուլն իրականում ձախողվեց։
Ծանուցումն ասում է, որ առաջարկը մերժվել է, բայց ոչ թե որը։ Փուլը պարզելու համար կարդացեք backend-ի մատյանը, ապա համեմատեք հավաքածուները նրա հետ, ով կառավարում է դարպասը։
NO_PROPOSAL_CHOSEN-ը գալիս է նախքան PPP-ի որևէ օգտանուն ստուգելը, ինչը օգտակար փաստ է և միևնույն ժամանակ պատճառը, թե ինչու հաղորդագրությունը մոլորեցնում է։ Այն հայտնում է, որ մի կողմը մերժել է առաջարկը. այն չի հայտնում, թե որ պարամետրն է տարբերվել, և ոչինչ չի ասում այն մասին, թե մերժումը տեղի է ունեցել IKE միավորման կառուցման ընթացքում, թե ավելի ուշ՝ երթևեկության պաշտպանության շուրջ բանակցելիս։ Այս երկու հնարավորությունների հետևում երկու տարբեր ուղղումներ են, և դրանցից միայն մեկն է առնչվում PFS-ի նշիչին, որին մարդիկ առաջինն են դիմում։
Մեկ հաղորդագրություն, երկու առաջարկների հավաքածու
IKEv1 L2TP/IPsec դասավորությունն ունի երկու հաջորդական բանակցություն։ Փուլ 1-ը կառուցում է IKE անվտանգության միավորումը գաղտնագրման ալգորիթմից, ամբողջականության ալգորիթմից և Diffie-Hellman խմբից։ Այնուհետև փուլ 2-ը բանակցում է, թե ինչպես է պաշտպանվելու երթևեկությունը, և PFS-ի պահանջը պատկանում է հենց այդ երկրորդ զրույցին։
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Քանի որ փուլերը հաջորդական են, ձախողման տեղը ձեզ ասում է, թե որ ցանկը համեմատել։ Հաղորդագրության ամբողջ ախտորոշիչ արժեքը հենց դրանում է, և արժե այն հանել նախքան որևէ կարգավորում ձեռք տալը։
Ինչու PFS-ի նշիչը չի կարող վերանորոգել փուլ 1-ը
PFS-ի անջատումը փոխում է փուլ 2-ի հատկությունը։ Եթե կողմերը երբեք չեն համաձայնել փուլ 1-ի շուրջ, ESP զրույցը ընդհանրապես տեղի չի ունենում, ուստի նշիչը որևէ ազդեցություն չունի մերժման վրա, և հենց դրա համար էլ այն փոխելը տալիս է նույն սխալը այլ ժամանակադրոշմով։
Հակառակ սխալը նույնքան տարածված է։ Հաջող IKE միավորումը չի ապացուցում, որ ESP առաջարկն ընդունելի է, և բացարձակապես չի ապացուցում, որ փուլ 2-ի խումբը համընկնում է։ Հաստատված կառավարման թունելը դիտարկեք որպես ապացույց միայն փուլ 1-ի մասին։ Մարդիկ կանաչ տողը կարդում են որպես «թունելը աշխատում է», ապա մեկ ժամ վատնում են սխալ փուլի վրա, որովհետև ոչինչ չի ասել նրանց, որ երկրորդ բանակցությունը չէր սկսվել։
Կարդացեք մատյանը նախքան ալգորիթմներ ընտրելը
Հավաքեք մերժմանն անմիջապես նախորդող հաղորդագրությունները այն backend-ից, որը իրականում սպասարկում է կապը, և կապեք դրանք նույն փորձի հետ։ Այդ կապակցումից առանց դուք կարդում եք այլ կապի պատմություն և դրանից եզրակացություններ անում։
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanԱյդ տողերից պատասխանեք երկու հարցի՝ արդյոք հաստատվեց փուլ 1-ի միավորում, և որ փոխանակումը ձախողվեց։ Այս երկու պատասխանները որոնումը նեղացնում են մեկ հատկանիշների ցանկի։ Մերկ ծանուցումը՝ առանց շրջապատող համատեքստի, չի կարող դա անել, որքան էլ գայթակղիչ լինի փորձել առաջարկ ֆորումի թեմայից։ Աշխատող տողը այլ backend ունեցող մեքենայից պատճենելը սովորաբար մեկ մերժումը փոխարինում է մեկ այլով՝ մի փոքր ավելի ուշ։
Backend-ի շարահյուսությունը չի ճամփորդում
Գրանցեք NetworkManager-l2tp-ի տարբերակը և IPsec backend-ի տարբերակը նախքան որևէ բան համեմատելը։ Libreswan-ը և strongSwan-ը չեն կիսում առաջարկների շարահյուսությունը կամ նույնական ալգորիթմների հավաքածուները, ուստի միում աշխատող տողը մյուսում շարահյուսական սխալ է։ Տեղադրված backend-ը կարող է նաև քաղաքականությամբ մերժել IKEv1-ը, և այդ դեպքում ոչ մի առաջարկ երբեք չի ընդունվի։
Ծրագրի README-ն փաստագրում է backend-ների այդ տարբերությունները և փուլ 1-ի ու փուլ 2-ի դաշտերը պահում է առանձին։ Կարդացեք այն որպես կառուցվածքի փաստաթուղթ, ոչ թե որպես հրավեր միացնելու յուրաքանչյուր պատմական գաղտնագրիչ և թույլ խումբ, որովհետև կապը, որը հաջողվում է միայն այդպես, այն կապը չէ, ինչ ձեզ խնդրել են կառուցել։
Համաձայնեցեք հավաքածուի շուրջ, ապա ստուգեք փուլերը
Հարցրեք դարպասի օպերատորին, թե որ IKE և ESP հավաքածուներն են աջակցվում և հաստատված, ապա համեմատեք այդ պատասխանը հաճախորդի փաստացի առաջարկների հետ, ոչ թե նրա կարգավորման ֆայլի։ Եթե տարաձայնությունը վերաբերում է հատկապես փուլ 2-ի PFS-ին, համաձայնեցեք աջակցվող խմբի կամ բացահայտ հաստատված PFS-ազատ քաղաքականության շուրջ։ Քաղաքականությունը մի՛ ենթադրեք սխալի անունից։
Երբ միակ համընկնումը պահանջում է գաղտնագրություն, որը կազմակերպությունն այլևս չի ընդունում, որոշումը դարպասինն է կամ արձանագրության միգրացիայինը։ Հաճախորդի տողի լայնացումը այնքան, մինչև ինչ-որ բան բանակցի, հայտնի թուլությունը կողքին կանաչ նշանով առաքելու եղանակ է։
Իրական անհամապատասխանությունը ուղղելուց հետո հաստատեք IPsec-ի կայացումը նախքան L2TP-ն ու PPP-ն ուսումնասիրելը, և ցանկացած հետագա նույնականացման մերժում համարեք հաջորդ փուլին պատկանող։ Ապա փորձարկեք նորացումը հաստատված փորձարկման գործընթացում, որովհետև առաջին միավորման կայացումը ոչինչ չի ասում դրա կյանքի մնացած մասի մասին։