Դուք գտնում եք առաջարկ՝ ավելացնել opt-verify, ավելացնում եք տողը, և գաղտնագրման սխալը մնում է ճիշտ այնտեղ, որտեղ եղել է։ Այդ արդյունքը կանխատեսելի է, որովհետև ընտրանքը երբեք գաղտնագրում չի բանակցել։ Դա ընտրանքների հետևողականության ստուգում էր, 2.6-ում հնացած և 2.7-ում հեռացված, և պրոֆիլը, որը դրանով դեռ վերլուծվում է, դրանով ոչինչ չի պարտադրել։

Օգտակար է իմանալ, թե տողը նախկինում ինչ էր անում, նախքան եզրակացնելը, որ դա է բացակայող մասը։ Պատմությունը նաև բացատրում է, թե ինչու այն հիմա չի կարող օգնել։

Ինչ էր պարտադրում ընտրանքը նախկինում

2.6-ի ձեռնարկը opt-verify-ը նշում է որպես հնացած և նկարագրում նախկին վարքը՝ սերվերը հեռացնում է այն հաճախորդներին, ում հայտարարված ընտրանքները չեն համապատասխանում իրեններին, համեմատելով այնպիսի բաներ, ինչպիսիք են սարքի տեսակը և MTU-ն։ Այդ ստուգումը նաև կախված է ընտրանքների հետևողականության ստուգման միացված մնալուց, ուստի disable-occ-ով աշխատող սերվերը երբեք չի ունեցել այն։ Ուշադրություն դարձրեք, թե ինչից է կառուցված համեմատությունը՝ մյուս կողմի կոնֆիգուրացիան նկարագրող տեքստից։ Այն ոչինչ չի ասում այն մասին, թե որ գաղտնագրումը կօգտագործի տվյալների ալիքը։

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

Ինչ է անում 2.7-ը, երբ տեսնում է տողը

2.7-ում ընտրանքը չկա։ Վերլուծիչը դեռ ճանաչում է անունը, դրա համար հին պրոֆիլը բեռնվում է առանց շարահյուսական սխալի, և այն հաղորդում է, որ ընտրանքը հեռացվել է, փոխարենը լուռ շրջանցելու։ Անուն ճանաչելը և վարք պարտադրելը տարբեր բաներ են, և դեռ միայն առաջինն է տեղի ունենում։ Հեռացման նշումները տալիս են պատճառը՝ երբ պարամետրերի շուրջ հնարավոր է բանակցել, երկու կողմերը կարող են օրինականորեն ունենալ տարբեր ընտրանքային տողեր՝ համաձայնելով կապակցմանը։

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

Որտեղ է իրականում ձախողումը

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

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

Փոխարինեք մտադրությունը, ոչ միայն տողը

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

Մի՛ պատասխանեք հին առաջարկին, թե բոլոր գաղտնագրումները անջատված են, միացնելով յուրաքանչյուր պատմական ալգորիթմ։

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

Նպատակը աջակցվող սահմանափակումն ու աշխատող նույնականացված ուղին է, ոչ թե հին դրոշակը, որը դեռ վերլուծվում է։

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