IKEv2 սերվերի հասցեն ընդդեմ ինքնության. ինչ է իրականում ստուգում հաճախորդը

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

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

Նախ, որն է հասցեն

Կապի հասցեն այն է, ինչ հավաքում է հաճախորդը. IP, DNS անուն, որը որոշվում է մեկին, կամ բեռի հավասարակշռված ճակատ։ Դա տրանսպորտի մասին տեղեկատվություն է և ոչ ավելին։ Ինքնությունը շարժվում է IKEv2 ID-ի օգտակար բեռով և այնուհետև համընկնում է գործընկերոջ վկայականի հետ։ Հասցեի վանդակում DNS անունը չի դառնում ակնկալվող ինքնությունը, իսկ հումքի IP-ն չի դառնում նույնականացում միայն այն պատճառով, որ վարդակից միացված է դրան։

strongSwan առումով հասցեն right կամ left է, իսկ ակնկալվող ինքնությունը՝ rightid կամ leftid, և դա այն է, ինչ նկարագրում է IKEv2 կազմաձևման փաստաթղթերը։ Եթե դուք երբևէ խմբագրել եք միայն հասցեն, ապա կազմաձևել եք զույգի կեսը։

Երկրորդ՝ ինչ կարող է վկայել վկայականը

Ինքնությունը ունի տեսակ, և վկայականը պետք է համապատասխան անուն ունենա։ DNS ինքնությունը բավարարվում է թեմայի այլընտրանքային անվան ընդլայնման մեջ dNSName գրառումով. IP նույնականացման համար անհրաժեշտ է iPAddress մուտք։ vpn.example.com-ի համար տրված վկայականը ոչինչ չի ապացուցում բառացի հասցեի մասին 203.0.113.10, իսկ այդ հասցեի համար տրված վկայականը ոչինչ չի ապացուցում անվան մասին։ Հետևաբար, այլ անվան համար վերաթողարկումը փոխարինում չէ, նույնիսկ երբ նույն բանալին և CA-ը նորից օգտագործվում են։

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

Երրորդ, թե ինչպես է յուրաքանչյուր հաճախորդ նշում ակնկալիքը

Windows-ը վերցնում է ձեր մուտքագրած սերվերի անունը կամ հասցեն և պահանջում է, որ վկայականը համապատասխանի դրան, ուստի IP մուտքագրելը IP ակնկալիք է ստեղծում։ Android-ի IKEv2 հաճախորդը նույն կերպ է վարվում, և երկուսն էլ մերժում են վավեր, հանրության կողմից վստահված վկայականը, որը անվանում է այլ հոսթ։ Պրոֆիլը կարող է սկսել ձախողվել միայն այն պատճառով, որ ինչ-որ մեկը միգրացիայի ժամանակ փոխարինել է հոսթի անունը իր հասցեով։ Տեսեք, թե ինչ է խնդրել հաճախորդը, նախքան նայեք, թե ինչ է պարունակում վկայագիրը։

strongSwan-ում ակնկալիքը հստակ է. դրեք rightid նույնականությունը, որը իրականում ներկայացնում է սերվերը, որը կարող է տարբերվել աջից։ Սահմանելով այն %any, ընդունում է այն, ինչ առաջարկում է գործընկերը և հեռացնում է հենց այն չեկը, որը դուք փորձում եք պահել։

Չորրորդ՝ առանձնացնել օգտվողի մուտքը գործընկերների ինքնությունից

EAP իսկությունը և սերվերի ինքնությունը պատասխանում են տարբեր հարցերի։ EAP ինքնությունը, ինչպիսին է [email protected]ը, ասում է, թե ով է օգտատերը, այն բանից հետո, երբ հաճախորդը որոշել է, որ սերվերը ճիշտն է։ Այդ գաղտնաբառի պտտումը չի կարող շտկել գործընկերների ինքնության անհամապատասխանությունը, քանի որ կապը երբեք չի հասնում օգտվողի մուտքի փուլ։

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

Հինգերորդ, փոխեք այն ստուգված ալիքով

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

Գրանցեք վերջնական հասցեն, ինքնությունը և SAN ցուցակը միասին պրոֆիլի նշումներում։ Հաջորդ անձը, ով կդիպչի վկայականին, կտեսնի, թե երեքից ով է թույլատրվում շարժվել։