IKEv2 վկայագրի SAN: ինչու է նույնականության ստուգումը ձախողվում

Ձեր վկայագիրը շղթայված է վստահելի CA-ի հետ, ժամկետները կարգին են, և գործընկերը դեռ հրաժարվում է ավարտել 1-ին փուլը ինքնության սխալով։ Հասանելիությունը և վավեր ստորագրությունը միայն կեսն են այն բանի, ինչ ստուգում է IKEv2 հաճախորդը։ Մյուս կեսն այն է, թե արդյոք ակնկալվող ինքնությունը հայտնվում է վկայագրում ճիշտ դաշտում, և այդ ակնկալիքը սահմանում է պրոֆիլը, ոչ թե վկայագրի ֆայլի անվանումը։

Ախտանիշը միշտ նույն ձևն ունի

Կապի պրոֆիլը փոխվում է հոսթի անունից IP հասցեի, կամ թարմացվում է DNS անուն կրող վկայագրից մի վկայագրի, որը կրում է միայն հասցեներ, ևթունելը դադարում է բանակցել։ Ցանցային ուղու վրա ոչինչ չի փոխվել։ Հաճախորդը հասնում է գործընկերոջը, ստանում վկայագիր և մերժում գործընկերոջ ինքնությունը, քանի որ այն նույնացուցիչը, որը նրան ասել էին սպասել, ներկայացված չէ իր ընդունած դաշտում։ Թարմացումները սովորական առիթ են, քանի որ փոխարինող վկայագիրը հաճախ գալիս է այլ ձևանմուշից, քան այն, ինչ փոխարինում է։

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

Համապատասխանեցրեք նույնացուցիչի տեսակը, ոչ միայն արժեքը

dNSName SAN-ը և iPAddress SAN-ը տարբեր դաշտեր են՝ տարբեր համապատասխանեցման կանոններով, ուստի 203.0.113.10-ը որպես DNS տող կրող վկայագիրը չի բավարարում IP ինքնություն սպասող հաճախորդին։ Ժամանակակից վավերացնողները մեծապես անտեսում են ընդհանուր անունը, ուստի վկայագրի մանրամասներում եղած ընկերասեր պիտակը ոչինչ չի ապացուցում այն մասին, թե ինչը կհամապատասխանի։ Եթե անսարքությունների վերացման ընթացքում հոսթի անունը փոխարինվել է հասցեով, ենթադրեք, որ ակնկալվող ինքնությունը տեղափոխվել է նրա հետ, մինչև չստուգեք։ Համեմատեք պրոֆիլի տողը SAN-ի տողի հետ նշան առ նշան, քանի որ վերջում դրված կետը կամ ավելորդ բացատը բավական են։

Նիշերի փոխարինիչները միայն DNS-ի հարմարություն են և հետևում են իրենց իսկ համապատասխանեցման կանոններին, ինչը ևս մեկ պատճառ է, որ IP-ի վրա հիմնված պրոֆիլը երբեք չպետք է հենվի դրանց վրա։

Գտեք, թե որտեղ է յուրաքանչյուր հաճախորդ պահում ակնկալիքը

strongSwan-ում վկայագրի հետ համեմատվող արժեքը գալիս է գործընկերոջ ինքնության կարգավորումից: rightid դասական կոնֆիգուրացիայում, կամ id swanctl-ում հեռավոր կապի բաժնի id-ից։ Apple IKEv2 փոխգործունակության մասին դրա փաստաթղթերը օգտակար են այստեղ, քանի որ շարադրում են այն ինքնության կոնվենցիաները, որոնք օգտագործում է պրոֆիլով ղեկավարվող հաճախորդը, և այդ կոնվենցիաները բացատրում են անհամապատասխանությունների մի դաս, որը լարի վրա պատահական է թվում։

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

Վերանորոգեք պրոֆիլը կամ վկայագիրը՝ գիտակցաբար

Որևէ բան փոխելուց առաջ ստուգեք գործընկերոջ վկայագիրը հաստատված գործիքներով և թվարկեք SAN գրառումները՝ իրենց տեսակներով։ Այդ ստուգումը չի պահանջում մասնավոր բանալի և վերբեռնում, և վայրկյանների ընթացքում լուծում է հարցը։ Եթե տեղակայումը նախատեսում է մեկ DNS ինքնություն, վկայագիրը պետք է այն կրի որպես dNSName գրառում, իսկ եթե տեղակայումը նախատեսում է հասցե, վկայագիրը պետք է iPAddress գրառում ունենա հենց այդ հասցեի համար։

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

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

Թարմացման հայտին տվեք չորս փաստ

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