OpenVPN tls-ciphersuites ընդդեմ tls-version-min-ի՝ ինչ է պարտադրում յուրաքանչյուրը

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

Ստուգեք հավաքումը նախքան որևէ ցանկ կարդալը

Կարգավորման հրահանգը չի կարող արձանագրության աջակցություն ավելացնել այն բինարին, որտեղ այն չկա։ Սկսեք տարբերակի բաններից, որը նշում է կոմպիլյացված գաղտնագրման գրադարանը՝

openvpn --version

OpenSSL-ի հետ կապված 2.6 հավաքումն ընդունում է և՛ tls-cipher, և՛ tls-ciphersuites։ mbed TLS-ով հավաքումն ընդհանրապես TLS 1.3 փաթեթների ընտրություն չունի, և 2.6 ձեռնարկը tls-ciphersuites-ը նշում է որպես OpenSSL տարբերակ։ Եթե սերվերը վերահավաքվի այլ backend-ով, նույն պրոֆիլը կարող է փոխել իր վարքը՝ առանց կարգավորման մեկ տողն անգամ փոխելու։

Քանի դեռ այստեղ եք, գործարկեք openvpn --show-tls-ը և պահպանեք ելքը։ Սա այն գույքագրումն է, որի հետ հետագայում կհամեմատեք, և էժան է այն գրառել նախքան ինչ-որ մեկը կսկսի խմբագրել պրոֆիլները։

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

Տարբերակի սահմանները գաղտնագրերի ցանկերից առանձին պահեք

2.6 ձեռնարկում սրանք երեք կառավարիչ են, ոչ մեկը՝

• tls-cipher-ը սահմանում է գաղտնագրման քաղաքականությունը TLS 1.2-ի և ավելի վաղ տարբերակների համար և փոխանցվում OpenSSL-ի գաղտնագրերի ցանկին՝
• tls-ciphersuites-ն ընտրում է TLS 1.3 փաթեթները՝
• tls-version-min-ը և tls-version-max-ը սահմանափակում են արձանագրության այն տարբերակները, որոնք կապը կարող է օգտագործել։

Այսպիսով՝ ուշադիր կտրված TLS 1.3 փաթեթների ցանկը ոչինչ չի ապացուցում այն մասին, որ հին տարբերակը դեռ թույլատրված է։ Եթե պահանջը «միայն TLS 1.3» է, ապա այն կրում է տարբերակի ստորին սահմանը, և փաթեթների ցանկը միայն նեղացնում է ընտրությունները այդ սահմանի ներսում՝

tls-version-min 1.3
tls-ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

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

Տվյալների ալիքը չորրորդ կառավարիչն է։ data-ciphers-ը բանակցում է թունելի ներսում սիմետրիկ գաղտնագիրը, և դրա արդյունքը ոչինչ չի ասում կառավարման ալիքի TLS տարբերակի մասին։ Նստաշրջանի ամփոփագրում AES-256-GCM տեսնելը որևէ ուղղությամբ TLS 1.3-ի ապացույց չէ։

show-tls-ը կարդացեք որպես տեղական գույքագրում

--show-tls-ը թվարկում է այն փաթեթները, որոնք աջակցում է այն գաղտնագրման գրադարանը, որի հետ կապված է այս բինարը՝ նախընտրության կարգով։ Սա դարպասից եկած հաշվետվություն չէ։ Ձեռնարկը հստակ ասում է, որ ցանկը գալիս է տեղական գրադարանից, ինչը նշանակում է, որ OpenSSL 3.x-ով նոութբուքը և ավելի հին հավաքումով երթուղիչը տարբեր ցանկեր կտպեն՝ խոսելով նույն սերվերի հետ։

Ենթադրենք հաճախորդը աջակցում է A, B և C փաթեթներին, և մեկ նստաշրջան ընտրում է B-ն։ Դա ոչինչ չի հաստատում այն մասին, թե արդյոք սերվերը թույլատրում է A-ն կամ C-ն, ոչ էլ այն մասին, թե արդյոք B-ն նրա միակ թույլատրված ընտրությունն է։ Երեք տողերն առանձին պահեք, և TLS-ի շփոթեցնող թեմաների մեծ մասը ինքնըստինքյան կլուծվի։

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

Դարպասին հարցրեք մի բան, որին նա կարող է պատասխանել

Եթե դուք եք կառավարում ծառայությունը, ստուգեք աշխատող օրինակի արդյունավետ կարգավորումը, այլ ոչ սկավառակի վրա գտնվող ֆայլը։ Հնարավոր է OpenVPN-ը գործարկվել է այլ --config ուղով, ներբեռնում է ներառումներ և չի վերագործարկվել խմբագրումից հետո։ Աշխատող դեմոնի քաղաքականությունն այն է, ինչին հանդիպում են հաճախորդները։

Եթե դուք չեք կառավարում այն, օպերատորից խնդրեք աջակցվող հաճախորդի պահանջներ կամ սահմանափակ ընդունման թեստ։ Մերժված փորձը ինքնաբերաբար մերժված փաթեթ չէ. տարբերակի ստորին սահմանը, վկայագրի ինքնության ստուգումները, ինչպիսին remote-cert-tls-ն է, կամ tls-auth-ի և tls-crypt-ի անհամապատասխանությունը կարող են ավարտել փոխանակումը նախքան փաթեթի ընտրությունը նշանակալի կդառնա։ Կարդացեք սերվերի սխալը նախքան հաճախորդի ցանկը փոխելը, որովհետև «handshake failed»-ը ծածկում է չորս տարբեր պատճառ, և դրանցից միայն մեկն է գաղտնագրի անհամապատասխանությունը։

Ուղղել openssl s_client-ը VPN պորտին նույնպես չի վերարտադրում հարցը։ Կառավարման ալիքը աշխատում է OpenVPN-ի սեփական շրջանակի ներսում, ուստի հում TLS ստուգիչը այլ արձանագրություն է փորձարկում այն պորտում, որը սպասում է այլ բանի։ Դրանից արված ցանկացած եզրակացություն վերաբերում է ստուգիչին, ոչ թե թունելին։

Գրանցեք երկու արդյունք և դրանք առանձին պահեք

Թարմ թույլատրված նստաշրջանը ստեղծում է կառավարման ալիքի տող, որը նշում է արձանագրության տարբերակը և ընտրված գաղտնագիրը, և առանձին տվյալների ալիքի տող, որը նշում է թունելի գաղտնագիրը։ Գրառեք երկուսն էլ հաճախորդի տարբերակի և պրոֆիլի անվան հետ, և նշեք, թե սերվերի որ օրինակն է պատասխանել՝

openvpn --config office.ovpn --verb 4 2>&1 | tee session.txt

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

Կատարեք ստուգումները այս հերթականությամբ։ Հաստատեք հավաքումն ու backend-ը --version-ով։ Գրառեք --show-tls-ը նախքան որևէ բան փոխելը։ Նշեք պահանջվող տարբերակի ստորին սահմանը փաթեթների ցանկից առանձին։ Հաստատեք աշխատող օրինակի արդյունավետ քաղաքականությունը դրա սեփականատիրոջ հետ։ Դիտարկեք մեկ թույլատրված նստաշրջան և, եթե պլանը թույլատրում է, հին տարբերակով մեկ մերժված փորձ։ Գրանցեք կառավարման ալիքի և տվյալների ալիքի արդյունքները որպես առանձին հայտնագործություններ։

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