Հարցրեք, թե ինչ գաղտնագրում է օգտագործում VPN-ը, և պատասխանը սովորաբար գալիս է մեկ բառով՝ AES-256, կամ ChaCha20, կամ գուցե WireGuard։ Այդ պատասխանը նշում է մեկ շերտի մեկ բաղադրիչ, մինչդեռ այն, ինչ իրականում պաշտպանում է կապը, չորս տարբեր դերեր կատարող ալգորիթմների ամբողջություն է։ Բաղադրիչը կառուցվածքի հետ շփոթելը ամենատարածված սխալն է այս զրույցներում, և այն ստեղծում է համեմատություններ, որոնք հնարավոր չէ լուծել։

Չորս աշխատանք մեկ կապի մեջ

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

Որոշ նախագծեր միավորում են երկու դեր մեկի մեջ։ AES-GCM-ը և ChaCha20-Poly1305-ը նույնականացված գաղտնագրման կառուցվածքներ են, ուստի գաղտնիությունը և ամբողջականությունը գալիս են միասին. AES-CBC-ն այդպիսին չէ և պահանջում է առանձին հաղորդագրության նույնականացման կոդ՝ իր սեփական բանալիով։ Ուստի առաջարկը որպես անկախ թվերի պարկ կարդալը սխալ է կարդում զույգերով նախագծվածները։

Դերերը նաև տարբեր շերտերում են, դրա համար նույն բառը երկու արտադրանքում կարող է տարբեր բան նշանակել։ Բլոկային գաղտնագիրը ESP-ում և բլոկային գաղտնագիրը TLS-ում նույն պրիմիտիվն են տարբեր բանակցություններում՝ տարբեր պահանջներով։ Ուստի պրիմիտիվը առանց դրա ռեժիմի և շերտի մեջբերելը կարող է ավելի վատ լինել, քան ոչինչ չմեջբերելը։

Ինչու գաղտնագրի անունը գրեթե ոչինչ չի ասում

Մի պահ լուրջ վերաբերվեք AES-256 արտահայտությանը. այն նշում է բլոկային գաղտնագիր և բանալու չափ։ Այն ոչինչ չի ասում աշխատանքի ռեժիմի, ամբողջականության ապահովման, բանալիների հաստատման կամ զուգընկերոջ նույնականացման ձևի մասին։ Երկու արտադրանք կարող են երկուսն էլ գովազդել AES-256 և տարբերվել մնացած ամեն ինչում, ներառյալ մեկը չնույնականացված ռեժիմով և մյուսը՝ AEAD ռեժիմով և ժամանակակից բանալիների փոխանակմամբ։

TLS 1.3-ը այս բաժանումը մտցրեց ստանդարտի մեջ, ինչը օգտակար ուղղում է նրանց համար, ովքեր սովորել են ավելի հին բառապաշարը։ Նրա գաղտնագրման հավաքածուները նշում են միայն AEAD-ն և հեշը, մինչդեռ բանալիների փոխանակման խմբերը և ստորագրության ալգորիթմները բանակցվում են որպես առանձին պարամետրեր։ Ուստի TLS 1.3-ի հավաքածուի անունը համադրելի չէ TLS 1.2-ի հավաքածուի անվան հետ հավասար հիմքով, թեև երկուսն էլ հայտնվում են կարգավորման ֆայլի նույն դաշտում։ Աուդիտորը, որը համեմատում է երկու տողերը ուղղակիորեն, գալիս է եզրակացության, որը պրոտոկոլը չի աջակցում։ Կարդացեք նաև բանակցված խումբը և ստորագրության պարամետրերը, հակառակ դեպքում համեմատությունը թերի է։

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

Շերտը որոշում է բառապաշարը

IPsec-ի տեղակայումը բանակցում է երկու անգամ. IKE-ի առաջարկ հսկիչ ալիքի համար և ESP-ի ձևափոխում տվյալների համար, և երկուսը կարող են օրինականորեն տարբերվել։ Առաջինը կարդալը և ենթադրելը, թե այն նկարագրում է երկրորդը, աուդիտի ընթացքում շփոթության սովորական աղբյուր է, որովհետև կարգավորման ֆայլը հիշատակում է երկուսին էլ, և հետաքրքիրը երկրորդն է։

LayerWhat is negotiated thereWhat it does not cover
IKE proposalAlgorithms and groups for the control channel that builds the tunnelThe algorithms protecting the data itself
ESP transformEncryption and integrity for tunneled packetsPeer identity, which authentication already settled
TLS handshakeAEAD and hash, plus separately negotiated groups and signaturesRouting, authorization or retention policy
WireGuardNothing; the algorithm set is fixed by the protocolEverything above the cryptographic arrangement

Մեկ գրադարանում հասանելի անունը ավտոմատ կերպով չի իրականացվում մեկ այլ տվյալների ուղու համար։ Ուստի այն պնդումը, որ մեր արտադրանքը աջակցում է AES-256-ին, ավելի թույլ է, քան հնչում է, և դրա համար էլ փոխգործունակության խնդիրը սովորաբար լուծվում է պահպանվող հատումը գտնելով, այլ ոչ թե երկու կողմերում բոլոր հին ալգորիթմները միացնելով։

TLS 1.3-ի սպեցիֆիկացիան բաժանման ամենապարզ հրապարակված օրինակն է, որովհետև այն հավաքածուն սահմանում է որպես զույգ և մնացածը տեղափոխում է իր սեփական բանակցություն։ Երբ այդ ձևը ծանոթ է, IPsec-ի առաջարկը և WireGuard-ի մեկ ֆիքսված հավաքածուն կարդացվում են որպես նույն գաղափարի տարբերակներ։

Կարդացեք բանակցված արդյունքը, ապա կանգ առեք

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

openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg show

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

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

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

Առնչվող հոդվածներ