tls-auth key-direction. 0-ը և 1-ը պետք է տարբերվեն, ոչ թե համընկնեն
tls-auth-ի դեպքում երկու ծայրերին պետք են հակառակ ուղղություններ՝ 0 և 1, կամ երկուսն էլ պետք է բաց թողնեն կարգավորումը։ Նույն թիվը ձախողվում է, և tls-crypt-ը երբեք այն չի օգտագործում։
Թունելի մի կողմը կառավարման ալիքը ստորագրում է բանալու այնպիսի բնիկով, որը մյուս կողմը երբեք չի ստուգում, և կապը մահանում է նույնականացման սխալով՝ նախքան թեկուզ մեկ վկայագիր փոխանակելը։ Ահա թե ինչպիսին է tls-auth-ի ուղղության անհամապատասխանությունը, և այն դետերմինիստական է. նույն երկու ֆայլերը ձախողվում են ամեն փորձի ժամանակ, ցանկացած ցանցից։ Մատյանում ոչինչ չի նշում այն ընտրանքը, որը դուք փնտրում եք, դրա համար մարդիկ նորից են կառուցում բանալիներ և նորից թողարկում վկայագրեր, որոնք երբեք չեն կոտրվել։ Լուծումը երկու ծայրերը լրացնող դարձնելն է, կամ երկուսն էլ երկկողմանի թողնելը, ոչ թե ստուգումը թուլացնելը։
Ձախողումը տեղի է ունենում վկայագրերից առաջ
tls-auth-ի դեպքում երկու կողմերն էլ պահում են նույն ընդհանուր բանալին, և յուրաքանչյուրը օգտագործում է դրանից ստացված երկու բնիկներից մեկը. մի բնիկը ստորագրում է ելքային կառավարման փաթեթները, մյուսը ստուգում է մուտքայինները։ 0 ուղղությունը և 1 ուղղությունը այդ դերերը հատկացնում են հակառակ հերթականությամբ, ուստի զույգը պետք է լրացնող լինի, որպեսզի HMAC ստուգումները համընկնեն։ Երբ մի կողմում հատկացումը շրջվում է, ստացողը ստորագրություն է փնտրում սխալ բնիկում և մերժում փաթեթը։ Նստաշրջանն այնտեղ ավարտվում է, դրա համար էլ սխալը վերաբերում է փաթեթների նույնականացմանը, այլ ոչ թե նրան, ինչ կստեղծեր վկայագրերի պահոցը։
Դետերմինիզմը կարևոր է ախտորոշման համար, որովհետև ժամանակի կամ ուղու խնդիրը այլ հետք է թողնում. ընդհատվող կտրվածքներ, մեկ ուղղության ձախողում կամ նստաշրջան, որը մահանում է միայն որոշակի ցանցում։ Ուղղության անհամապատասխանությունը ձախողվում է առաջին ձեռքսեղմման ժամանակ ամեն անգամ, և այն նույն կերպ ձախողվում է մեկ այլ մեքենայում՝ նույն երկու ֆայլերով։ Կարդացեք մատյանը --verb 4-ում և գտեք առաջին մերժված փաթեթը, ոչ թե վերջին տողը։ Եթե այդ մերժումը տեղի է ունենում ցանկացած վկայագրի փոխանակումից առաջ, ապա ընդհանուր բանալին և նրա ուղղությունը այն երկու բաներն են, որ արժե ստուգել։
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Որտեղ է ապրում թիվը
Ձեռնարկը՝ OpenVPN 2.6 փաստաթղթավորում է երկու տեղ ուղղության համար. tls-auth-ի երկրորդ արգումենտը, երբ բանալին առանձին ֆայլում է, և ինքնուրույն key-direction տողը, երբ բանալին ներկառուցված է պրոֆիլում։ Երկուսն էլ սահմանում են նույն արժեքը, ուստի պրոֆիլը պետք է օգտագործի ձևերից մեկը կամ մյուսը, երբեք երկուսը միասին։ Բաց թողնելը նույնպես ընտրություն է, և այն երկու կողմերին դնում է երկկողմանի դասավորության մեջ, որն աշխատում է, երբ ոչ մի կողմ ուղղություն չի նշում։ Նույն թվով երկու կողմերը այդ դասավորության մեջ չեն. յուրաքանչյուրը սպասում է ստորագրել մի բնիկում և ստուգել մյուսում, և երկուսն էլ դա անում են նույն կերպ։
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
Ներկառուցված ձևը առանձին տողի հրահանգ է, ոչ թե ատրիբուտ բանալու բլոկի բացման պիտակի վրա, և այդ պիտակին արգումենտ ավելացնելը սխալ է, ոչ թե ուղղության փոփոխություն։ Տեղը նույնպես կարևոր է. հրահանգը գտնվում է այն բլոկից դուրս, որին պատկանում է, ուստի բլոկի ներսում գրված արժեքը կարդացվում է որպես բանալու նյութ։ Պատճենեք այն դասավորությունը, որը նախատեսել է պրոֆիլի տարածողը, փոխարենը զույգ հորինելու, որովհետև մեկ սերվերի դեմ աշխատող պրոֆիլը գուցե արդեն արտացոլված է մյուս կողմում։
Ինչն է ընտրանքը թողնում անձեռնմխելի
Այն չի գաղտնագրում հավելվածների երթևեկությունը։ tls-auth-ը HMAC է դնում կառավարման ալիքի փաթեթների շուրջ, մինչդեռ տվյալների ալիքը պաշտպանված է ձեռքսեղմման ընթացքում համաձայնեցված նստաշրջանի բանալիներով, ուստի թողունակության կամ գաղտնագրման հարցը կապ չունի ուղղության թվի հետ։ Կարգավորումը նաև գաղտնագրման երկրորդ շերտ չի ավելացնում, և հենց այդ ենթադրությունն է մարդկանց ուղարկում ավելի երկար բանալի փնտրելու։
Այն չի տարածվում tls-crypt-ի վրա, կառավարման ալիքի մեկ այլ մեխանիզմ՝ իր ընտրանքներով և բանալիների մշակմամբ, և ոչինչ չի ասում որևէ կողմի վկայագրի ինքնության մասին։ Այսպիսով, աշխատող ուղղության համընկնումը միայն ապացուցում է, որ երկու ծայրերը համաձայն են, թե ինչպես նույնականացնել կառավարման ալիքը, ոչ թե այն, որ վստահության շղթան ստուգվել է։
Հավասարեցրեք զույգը, ապա նորից միացեք
Համեմատեք երկու կազմաձևերը, նախքան որևէ մեկը փոխելը, որովհետև արդեն ճիշտ կողմը խմբագրելը կրկնապատկում է աշխատանքը։ Ներքևի grep-ը ցույց է տալիս, թե յուրաքանչյուր ֆայլ որ մեխանիզմն է ընտրում. մանրամասն գործարկումը ցույց է տալիս, թե արդյոք կառավարման ալիքն ընդհանրապես նույնականացվել է։ Պահեք երկու ելքերը, որպեսզի հաջորդ փոփոխությունը համեմատվի հայտնի վիճակի հետ։
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Վերագործարկեք երկու կողմերին ցանկացած փոփոխությունից հետո, որովհետև այս ընտրանքները կարդացվում են մեկ անգամ մեկնարկի ժամանակ, և մի կողմի վերաբեռնումը զույգը թողնում է անհետևողական հին նստաշրջանի ողջ կյանքի ընթացքում։ Եթե տեղակայումը հիմա աշխատում է առանց ուղղության կարգավորման, ապա մի կողմում կարգավորումն ավելացնելը վերարտադրում է այն ձախողումը, որով սկսել եք. կա՛մ թողեք երկուսին էլ, կա՛մ կարգավորեք երկուսին էլ։ Փոխեք մեկ ծայր միաժամանակ և պահեք նախորդ ֆայլը, որպեսզի ռեգրեսիան լինի երկու րոպեի վերադարձ, ոչ թե վերակառուցում։
Գրանցեք մեխանիզմը, բանալու ֆայլը և ուղղությունը յուրաքանչյուր ծայրի համար տեղակայման նշումներում, որովհետև հակառակ դեպքում հաջորդ մարդը կկարդա երկու նմանատիպ ֆայլ և կենթադրի, որ թվերը պետք է համընկնեն միմյանց հետ։ Ուղղությունը համակարգման մանրամասնություն է, ոչ թե անվտանգության բարելավում. այն բաժանում է կառավարման ալիքի երկու ուղղությունները և ուրիշ ոչինչ չի անում։