OpenVPN username-as-common-name. ինչու է ձեր CN ստուգումը դատարկ
client-connect սկրիպտը, որը համեմատում է common_name-ը username-ի հետ, կարող է անունը համեմատել ինքն իր հետ։ Կապեք վկայականը հաշվի հետ նախքան փոխարինումը կատարվելը։
Դուք ավելացնում եք client-connect սկրիպտ, որը մերժում է ցանկացած կապակցում, որտեղ common_name տարբերվում է username-ից, և դա թվում է կապ վկայականի ու հաշվի միջև։ username-as-common-name-ով աշխատող սերվերի վրա այդ համեմատությունն արդեն կորցրել է իր իմաստը մինչև սկրիպտի աշխատելը։ Երկու արժեքներն էլ նույն տողն են, ուստի թեստը հաջողվում է բոլորովին այլ մեկին տրված վկայականի համար։
Ստուգումը սխալ չէ նրա համար, որ սկրիպտը վատ է գրված։ Այն սխալ է, որովհետև իր կարդացած արժեքը փոխարինվել է ավելի վաղ նույն կապակցման մեջ։
Ինչ է կարծես թե ապացուցում համեմատությունը
Վկայականով նույնականացումը և գաղտնաբառով նույնականացումը առանձին ապացույցներ են, և սերվերը կարող է պահանջել երկուսն էլ՝ չպահանջելով, որ դրանք պատկանեն նույն մարդուն։ Բացը իրական է. վավեր սարքի վկայականը ցանկացած վավեր հաշվի հետ այլ պահանջ է, քան այդ նույն վկայականը մեկ անվանված հաշվի հետ։ common_name-ը username-ի հետ համեմատող սկրիպտը կարդացվում է որպես երկուսի միջև բացակայող օղակ։ Այդպես կլիներ, եթե common_name-ը դեռ նշանակեր այն, ինչ ասում էր վկայականը։
Արդյոք այդպես է, կախված է սերվերի մեկ պարամետրից, և այդ պարամետրը սովորաբար միացվում է անկապ պատճառով, օրինակ՝ յուրաքանչյուր օգտվողի կոնֆիգուրացիայի ֆայլերն ավելի հեշտ անվանելու համար։
Ինչ է անում username-as-common-name-ը անվան հետ
Երբ username-as-common-name-ը միացված է, OpenVPN-ը օգտվողի անունն ու գաղտնաբառը ստուգելուց հետո փոխարինում է վկայականի ընդհանուր անվանումը նույնականացված օգտվողի անունով։ Այդ ստուգման ընթացքում աշխատող ստուգման կեռը դեռ ստանում է վկայականի ընդհանուր անվանումը, քանի որ փոխարինումը դեռ տեղի չի ունեցել։ Ամեն ինչ դրանից հետո, ներառյալ client-connect-ը, տեսնում է օգտվողի անունը։ Այսպիսով՝ ավելի ուշ վերադարձի կանչը մեկ ինքնություն ստանում է երկու անգամ և չի կարող համեմատել այն ներկայացված վկայականի հետ։
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Հետևեք մեկ օրինակելի կապակցման. bob-device-ի համար տրված վկայական, alice անունով հաջող գրացուցակային մուտք և միացված պարամետր։ Ստուգման փուլը դեռ կարող է տեսնել երկու տարբեր տող։ Կապակցման փուլը տեսնում է alice-ը և alice-ը։
Այդ օրինակը ցույց է տալիս, թե ինչու է համեմատությունը դատարկ։ Այն չի ցույց տալիս, որ կապակցումն այլապես կընդունվեր, քանի որ վկայականի վավերացումը և գաղտնաբառի ստուգումը դեռ ինքնուրույն են աշխատում։
Տեղադրեք կապը այնտեղ, որտեղ երկու ինքնությունները դեռ գոյություն ունեն
Կանոնը պետք է կիրառվի այն փուլում, որը միաժամանակ տեսնում է վկայականի ինքնությունը և հաշիվը, ինչը գործնականում նշանակում է օգտվողի անվան և գաղտնաբառի ստուգման կեռ կամ այնտեղ բեռնված հավելում։ Աջակցվող հավելումը, որն արդեն իսկ կատարում է գաղտնաբառի ստուգում, սովորաբար զույգավորման կանոն ավելացնելու ճիշտ տեղն է, քանի որ այն անվան համեմատությամբ փոխարինելը կվերացնի գաղտնաբառի ստուգումը ամբողջությամբ։
Սահմանեք քարտեզագրումը նախքան կոդ գրելը, քանի որ հավասարությունը հազվադեպ է իրական քաղաքականությունը։ Վկայականը հաճախ նույնականացնում է սարք, մինչդեռ մուտքը՝ մարդու, և մեկ սարքը կարող է օրինականորեն սպասարկել մի քանի մարդու։ Պահեք կապը այնպիսի ձևով, որի թողարկումը դուք եք վերահսկում, և որոշեք՝ ինչ է լինում անվանափոխության, վերաթողարկման և տիրույթով որակավորված անունների դեպքում։ Փոքրատառ դարձնելը կամ տիրույթի նախածանցը հեռացնելը՝ առանց գրացուցակը հասկանալու, կարող է միավորել երկու հաշիվ, որոնք պետք է առանձին մնային։
Հիշեք, որ պարամետրը նաև փոխում է, թե որ յուրաքանչյուր հաճախորդի կոնֆիգուրացիան է կիրառվում, քանի որ client-config-dir-ը կապված է ընդհանուր անվանման հետ։
Փորձարկեք զույգավորումը երկու վավեր հավատարմագրով
Սկսեք այն զույգից, որը թույլ է տալիս ձեր քաղաքականությունը, և համոզվեք, որ այն միանում է։ Ապա ներկայացրեք նույն վավեր վկայականը մեկ այլ, բայց այլապես վավեր հաշվի հետ. այդ փորձը պետք է ձախողվի, և այն պետք է ձախողվի զույգավորման կանոնի պատճառով, ոչ թե սխալ մուտքագրված գաղտնաբառի։ Սխալ գաղտնաբառն ապացուցում է, որ գաղտնաբառի ստուգումն աշխատում է, և ոչինչ չի ասում վկայականի ու հաշվի միջև կանոնի մասին։
Ստուգեք նաև բացակայող վկայականի և անվավեր վկայականի ուղիները, և համոզվեք, թե որ ինքնությունն է սերվերն օգտագործում յուրաքանչյուր հաճախորդի կարգավորումների համար։ Եթե համեմատությունը աշխատեցնելու միակ միջոցը username-as-common-name-ը անջատելն է, նախ գնահատեք այդ փոփոխության արժեքը, քանի որ այն յուրաքանչյուր հաճախորդի կոնֆիգուրացիայի որոնումը վերադարձնում է վկայականի անվանը։