DH ֆայլ, թե tls-auth բանալի. Ինչպես տարբերել OpenVPN-ի երկու ֆայլերը

Երկու ֆայլ, երկու հրահանգ և սովորություն երկուսին էլ անվանել այն բանի անունով, ինչ նրանք կարգավորում են։ Այդպես է dh.pem հայտնվում tls-auth տողում, և հաճախորդը ձախողվում է անսպասելի բանալու ձևաչափի մասին հաղորդագրությամբ։ Ձեր առջև դրված որոշումը այն չէ, թե որ ֆայլն է ավելի ուժեղ։ Այն է, թե տեղաբաշխմանն իրականում որ դերն է պետք, և երեք պայման որոշում է դա՝ ինչ բանալիների փոխանակում կբանակցի ձեր TLS կույտը, ուզո՞ւմ եք արդյոք կառավարման ալիքի նույնականացում, և պե՞տք է նյութը գաղտնի մնա։

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

Կարդացեք պիտակը ֆայլի անունից առաջ

Ֆայլի առաջին տողն ավելի տեղեկատվական է, քան նրա անունը, որովհետև անունը մարդկային պայմանականություն է, իսկ պիտակը ստեղծում է գործիքը։ Diffie-Hellman պարամետրերը կրում են BEGIN DH PARAMETERS PEM պիտակը։ OpenVPN-ի ստատիկ բանալին բոլորովին այլ կառուցվածք է՝ իր գլխիկով և տասնվեցական բեռով։

Վերանվանումը ոչինչ չի փոխարկում։ ta.key անունով պարամետրային ֆայլը դեռ պարամետրեր է, իսկ dh.pem անունով ստատիկ բանալին դեռ ստատիկ բանալի է․ վերլուծիչը կարդում է բովանդակությունը և մերժում անհամապատասխանությունը։ Ստուգեք պրոֆիլը խմբագրելուց առաջ․

head -n 1 dh.pem
head -n 1 ta.key

Երեք պայման, որոնք որոշում են՝ որ ֆայլն է ձեզ պետք

Առաջին պայմանը փոխանակումն է։ Վերջավոր դաշտի Diffie-Hellman ձեռքսեղմումը խումբ է պահանջում, և dh հրահանգն այն տեղն է, որտեղ սերվերը նշում է դրա պարամետրերը։ Էլիպտիկ կորի ձեռքսեղմումն ընդհանրապես այդ ֆայլի կարիքը չունի, որովհետև կորը հենց պարամետրերի բազմությունն է։ Եթե ձեր սերվերը բանակցում է միայն ECDHE հավաքածուներով, DH ֆայլը մեռած բեռ է, ոչ թե լրացուցիչ ուժ։

Երկրորդ պայմանը կառավարման ալիքի նույնականացումն է՝ առանձին հատկություն սեփական նյութով։ tls-auth ֆայլը ընդհանուր ստատիկ բանալի է, որը պահում են երկու կողմերը, և որով ստորագրվում են կառավարման ալիքի փաթեթները, որպեսզի չնույնականացված կողմը չկարողանա նույնիսկ ավարտել ձեռքսեղմումը։ Այն գոյություն ունի անկախ նրանից՝ օգտագործում եք վերջավոր դաշտի DH, թե ոչ, և կապ չունի խմբի պարամետրերի հետ։

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

Արտադրեք ճիշտ նյութը յուրաքանչյուր դերի համար

Օգտագործեք այն գործիքը, որն արտադրում է հրահանգի սպասած ձևաչափը, փոխարենը նրանց միջև փոխարկելու։ OpenVPN 2.6-ի ընդհանուր բանալու համար գեներատորի տիպավորված ձևը հստակ նշում է նպատակը։

openvpn --genkey tls-auth ta.key

Այդ հրամանը ստեղծում է նոր գաղտնի նյութ․ այն չի վերանորոգում և չի զննում գոյություն ունեցող բանալին, և նորից գործարկելը ձեզ տալիս է այլ բանալի, որը մյուս կողմերը չունեն։ Պատճենեք ստացված ֆայլը այն կողմերին, որոնց պետք է, այնպիսի ալիքով, որը կօգտագործեիք ցանկացած ընդհանուր գաղտնիքի համար, և պահեք ուղղության պայմանականությունը հետևողական․ tls-auth-ի դեպքում մի կողմը օգտագործում է key-direction 0, մյուսը՝ key-direction 1։

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

Ինչ է անում dh none-ը և ինչ՝ ոչ

dh none իրական հրահանգ է նեղ իմաստով․ վերջավոր դաշտի պարամետրային ֆայլ չի բեռնվի, որովհետև ձեռքսեղմումը օգտագործում է էլիպտիկ կորի Diffie-Hellman։ Այն «բաց թողնել DH քայլը» համառոտագրությունը չէ այն իմաստով, թե ինչ-որ բան թուլացնում է, և իհարկե չի ասում OpenVPN-ին ընդունել այլ ֆայլ որպես փոխարինող։

Սխալ կարդալուց բխում են երկու սխալ։ Առաջինը ենթադրելն է, թե dh none-ը վերացնում է tls-auth-ի կարիքը, մինչդեռ երկուսը կառավարում են տարբեր բաներ։ Երկրորդը՝ միայն կորով կոնֆիգուրացիայի կողքին հնացած dh տող պահելը և ապա զարմանալը, թե սերվերն իրականում որ ֆայլն է օգտագործում․ եթե հրահանգը կա, ֆայլը կարդացվում է, և այնտեղ կոտրված ուղին ձախողում է մեկնարկը մի պատճառով, որը կապ չունի բանակցվելիք փոխանակման հետ։

Եթե սխալ ֆայլն արդեն տեղակայված է

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

Ապա առանձնացրեք այն երկու դեպքերը, որոնք մարդիկ հակված են միավորելու։ DH պարամետրային ֆայլի հրապարակումը գրեթե անվնաս է, որովհետև պարամետրերը նախագծմամբ հանրային էին։ tls-auth բանալու բացահայտումն այլ դեպք է․ բանալին նույնականացնում է կառավարման ալիքի փաթեթները յուրաքանչյուր կողմի համար, որը պահում է այն, ուստի փոխարինումը պետք է համաձայնեցվի ամբողջ տեղաբաշխման մեջ, այլ ոչ թե կիրառվի մեկ հոսթի վրա։

Հինգ րոպեի ստուգումը որոշում է, թե որ դեպքում եք՝ կարդացեք յուրաքանչյուր ֆայլի առաջին տողը, հաստատեք դրան հղվող հրահանգը և հաստատեք, որ ֆայլի բաշխումը համապատասխանում է նյութի պահանջին։ Սա ավելի փոքր աշխատանք է, քան աշխատող PKI-ն նորից ստեղծելը, և հենց դրան էին ուղղված երեք պայմանները ողջ ընթացքում։