Ինչպես է OpenVPN data-ciphers-ը ընտրում տվյալների ալիքի ծածկագիրը
Սերվերը առաջարկում է ցանկ, իսկ հաճախորդն ընտրում է առաջին համընկնումը։ Կարդացեք մատյանի երկու տողերն էլ, համեմատեք ցանկերը և ավելացրեք պահուստային տարբերակ միայն այնտեղ, որտեղ զուգընկերոջն այն պետք է։
Թունելը բարձրանում է, մատյանը ցույց է տալիս ծածկագիր, և պրոֆիլի ստուգումը շարունակվում է։ Այնուհետև զուգընկերոջ մոտ գալիս է թարմացում, և նույն պրոֆիլը ձախողվում է ընդհանուր ծածկագիր չկա հաղորդագրությամբ, ինչը մարդկանց ուղարկում է ջնջվելիք հրահանգ փնտրելու։ Օգտակար է հասկանալ, որ data-ciphers-ը նկարագրում է բանակցություն, այլ ոչ թե կարգավորում։ Մի կողմն առաջարկում է ցանկ, մյուսն ընտրում է դրանից, և արդյունքը մեկ ալգորիթմ է, որն աջակցում են երկուսն էլ։ Այդ փոխանակումը կարդալը բացատրում է այս ձախողումների մեծ մասը նախքան տողը փոխելը։
Երկու ալիք, երկու կարգավորում
Մեկ OpenVPN նստաշրջան ունի կառավարման ալիք և տվյալների ալիք։ Կառավարման ալիքը կատարում է TLS ձեռքսեղմումը, որը նույնականացնում է զուգընկերներին և բանակցում բանալիները։ Տվյալների ալիքը գաղտնագրում է ձեր երթևեկությունը կրող փաթեթները։
data-ciphers-ը կարգավորում է երկրորդը։ Կառավարման ալիքն ունի իր ընտրանքները, և պրոֆիլի ինքնության ստուգումները երրորդ, առանձին հարց են։ Մեկի փոփոխությունը չի ուղղում մյուսին, դրա համար պրոֆիլը կարող է ճիշտ թվալ և այնուամենայնիվ ձախողվել որոշակի փուլում։
Երեքը պահեք առանձին արկղերում, երբ կարդում եք կարգավորման ֆայլ։
Կարդացեք բանակցությունը մատյանից
Հաճախորդի մատյանը նշում է երկու արդյունքները, երբ կապը հաջողվում է։ Մեկ տողը հաղորդում է կառավարման ալիքի և դրա TLS մանրամասների մասին, իսկ մյուսը՝ ընտրված տվյալների ալիքի ծածկագրի մասին։
Կարդացեք երկուսն էլ, որովհետև նրանք պատասխանում են տարբեր հարցերի։ Կառավարման ալիքի խափանումը կանգնեցնում է կապը նախքան որևէ տվյալների ծածկագիր կարևոր դառնալը։ Տվյալների ալիքի անհամապատասխանությունը հայտնվում է հաջող ձեռքսեղմումից հետո՝ ընդհանուր ծածկագիր չկա հաղորդագրությամբ։
Ապա համեմատեք առաջարկվող ցանկերը երկու կողմերում։ Անուն, որը մի զուգընկերոջ տարբերակը կամ նրա ծածկագրային հիմքը չի տրամադրում, չի կարող ընտրվել, անկախ նրանից, թե որքան վաղ է այն հայտնվում մյուս զուգընկերոջ ցանկում։
Ինչպես է իրականում տեղի ունենում ընտրությունը
Սերվերը ձեռքսեղմման ընթացքում հրում է իր data-ciphers ցանկը հաճախորդին, և հաճախորդն ընտրում է այդ ցանկի առաջին գրառումը, որն ինքն էլ է աջակցում։ Հետևաբար հերթականությունը պատկանում է սերվերի կարգավորմանը, ոչ թե հաճախորդի։
Այդ մանրամասնությունը բացատրում է շփոթեցնող արդյունքների մի դաս։ Հաճախորդի ցանկի վերադասավորումը ոչինչ չի փոխում, քանի դեռ որոշում է սերվերի ցանկը։ Ծածկագիր ավելացնելը, որը հաճախորդը չի կարող տրամադրել, նույնպես ոչինչ չի փոխում, քանի որ հաճախորդը պետք է կարողանա օգտագործել ընտրված գրառումը։
Ավելի նոր թողարկումները փոխեցին լռելյայն ցանկը և վերանվանեցին այն ընտրանքը, որը նախկինում պահում էր այն, այնպես որ տարբեր տարբերակների երկու զուգընկերներ կարող են չհամաձայնվել առանց որևէ մեկի պրոֆիլը խմբագրելու։ Ստուգեք տարբերակը յուրաքանչյուր կողմում նախքան տպագրական սխալ ենթադրելը։
Ցանկը վերացական իմաստով ուժի դասակարգում չէ։ Այն թեկնածուների բազմություն է, և ընտրվածը սերվերի հերթականությամբ առաջին փոխադարձ աջակցվող գրառումն է։ Դրա համար տարբեր տեսք ունեցող երկու ցանկեր կարող են բանակցել նույն ծածկագիրը։ Դրա համար էլ նույն տեսք ունեցող երկու ցանկեր կարող են ձախողվել։
Ավելի հին զուգընկերներին պետք է դիտավորյալ պահուստ
Զուգընկերը, որը բոլորովին չի կարող բանակցել, որովհետև ավելի հին է մեխանիզմից կամ անջատել է այն, կարիք ունի փաստաթղթավորված համատեղելիության պայմանավորվածության։ Պահուստային ընտրանքը գոյություն ունի հենց այդ դեպքի համար և վերաբերում է զուգընկերներին, որոնք չեն մասնակցում բանակցություններին։
Դա նույնը չէ, ինչ միացնել յուրաքանչյուր հին ծածկագիր, որպեսզի հաղորդագրությունը անհետանա։ Լայն ցանկը թուլացնում է նստաշրջանը յուրաքանչյուր զուգընկերոջ համար, ներառյալ նրանց, ովքեր կբանակցեին ինչ-որ ուժեղ բան։
Համաձայնեցրեք երկու կողմերին՝ փոխարենը չխմբագրելով անկապ ալգորիթմների անուններ։ Եթե սերվերի թարմացումը հեռացրել է հին ընտրանք, ուղղումը պատկանում է տարբերակների պլանին, ոչ թե հաճախորդի շտապողականությանը։
Պահպանեք ստուգումը անձեռնմխելի
Տվյալների ալիքի անհամապատասխանությունը պատճառ չէ ընդունելու չստուգված սերվեր։ Վկայագրի ստուգումը, սպասվող սերվերի անունը և կառավարման ալիքի պաշտպանության կարգավորումները առանձնացված են ծածկագրի ընտրությունից և պետք է վերապրեն ցանկացած համատեղելիության փոփոխություն։
Գրանցեք միասին բանակցված տվյալների ծածկագիրը, հաճախորդի տարբերակը և սերվերի տարբերակը, որպեսզի հաջորդ համեմատությունը սկսվի փաստերից, այլ ոչ թե պրոֆիլի ֆայլից։
Աջակցվող ուղղումից հետո փորձարկեք սկզբնական կապը և վերաբանակցությունը, որովհետև մեկ անգամ հաստատված նստաշրջանը դեռ կարող է ձախողվել, երբ բանալիները թարմացվում են։
Եթե թունելը հաստատվում է, իսկ կայքերը դեռ ձախողվում են, ծածկագիրն այլևս կասկածյալը չէ։ Շարունակեք երթուղավորմամբ և DNS-ով։ Աշխատանքի հերթականությունը՝ կարդացեք մատյանի երկու տողերը, համեմատեք երկու ցանկերը, ստուգեք տարբերակները, պահուստ ավելացրեք միայն դրա կարիքն ունեցող զուգընկերոջ համար, ապա նորից փորձարկեք թարմացման ուղին։