tls-auth և tls-crypt՝ ինչ է պաշտպանում յուրաքանչյուրը OpenVPN-ում

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

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

Ինչից է իրականում պաշտպանում ընդհանուր բանալին

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

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

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

Ոչ մի մեխանիզմ ինքնություններ չի տրամադրում։ Ընդհանուր բանալին խմբային գաղտնիք է, և յուրաքանչյուրը, ով ունի այն, կարող է բավարարել ստուգման այդ շերտը։

Որտեղ են տարբերվում երկու տարբերակները

Դիտելի տարբերությունն այն է, ինչ տեսնում է դիտորդը։ tls-auth-ի դեպքում ձեռքսեղմումը տեսանելի է, բայց առանց բանալու ստուգելի չէ։ tls-crypt-ի դեպքում ձեռքսեղմումը անթափանց է բոլոր նրանց համար, ովքեր բանալին չունեն։

Կարգավորումը նույնպես տարբերվում է։ tls-auth-ն օգտագործվում է ուղղության արժեքով, այնպես որ մի կողմն օգտագործում է բանալու նյութի մի կեսը, իսկ մյուս կողմը՝ մյուս կեսը։ tls-crypt-ը օգտագործում է մեկ բանալի երկու ուղղություններով, ուստի ուղղության հրահանգը նրա կառուցվածքի մասը չէ։

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

Ավելի նոր տարբերակ՝ tls-crypt-v2, յուրաքանչյուր հաճախորդի կապում է իր սեփական փաթաթված բանալու հետ, որպեսզի մեկ հաճախորդի չեղարկումը չպահանջի խմբային բանալու վերաթողարկում։ Արժե իմանալ դրա մասին, բայց դա այլ տարբերակ է և այստեղի երկուսից ոչ մեկի հոմանիշը չէ։

Ինչու անհամապատասխանությունը կարծես թե ոչինչ չի կատարվում

Երբ ընդհանուր նյութը չի համընկնում, մյուս կողմը դեն է նետում փաթեթները՝ չասելով ուղարկողին, թե ինչու։ Կարդալու ոչ մի վավերացման սխալ չկա, քանի որ փաթեթը երբեք չի հասել այն շերտին, որը կստեղծեր այն։

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

Սերվերի մատյանում կարդացեք փաթեթի մակարդակի առաջին բողոքը, ոչ թե կրկնափորձի վերջին տողը։ Հաստատեք, որ երկու կողմերն էլ կրում են նույն տարբերակը նույնական բանալու նյութով, և որ բանալու ֆայլը վերստեղծվել է միայն մի կողմում։

Հրահանգը հեռացնելը անվտանգ վերանորոգում չէ։ Այն անջատում է պաշտպանության շերտը յուրաքանչյուր հաճախորդի համար, և դրանից հետո աշխատող թունելը միայն ապացուցում է, որ այդ շերտն էր անհամապատասխանությունը։

Ինչ դեռ պետք է կարգավորվի առանձին

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

Դրանք նաև չեն ընտրում տվյալների ծածկագիրը։ Դա առանձին բանակցություն է, որը ղեկավարվում է երկու ծայրերի տվյալների ուղու կարգավորումներով, և tls-crypt-ով պաշտպանված թունելը դեռ կարող է օգտագործել ծածկագիր, որը դուք չէիք նախատեսել։

Վերջապես, ընդհանուր բանալին ինքնին խնամք է պահանջում։ Վերաբերվեք դրան որպես գաղտնիքի, տարածեք հաստատված ուղով և փոխարինեք, երբ հեռանա այն ունեցողներից որևէ մեկը։ Քանի որ այն ընդհանուր է, դրա բացահայտումը բոլոր այն ծայրերի բացահայտումն է, որոնք օգտագործում են այն։