duplicate-cn-ը երկու սարքերին տալիս է մեկ ինքնություն, ոչ թե երկու

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

Առասպելը՝ երկրորդ սեսիան երկրորդ ինքնություն է

Ինտուիցիան ասում է, որ երկու միացում պետք է լինեն երկու հաճախորդ, և երկու հաճախորդ պետք է լինեն երկու սարք՝ իրենց իրավունքներով։ Սերվերը այդպես չի մոդելավորում։ Նա տեսնում է ընդհանուր անուն և duplicate-cn-ը միացված լինելու դեպքում ընդունում է այդ անունը կրող մեկից ավելի կենդանի սեսիա, և յուրաքանչյուրը ստանում է իր սեփական սեսիայի վիճակը դեյմոնում։

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

Այդ տարբերությունն անտեսանելի է, քանի դեռ ամեն ինչ աշխատում է։ Այն շատ տեսանելի է դառնում այն պահին, երբ պետք է տարբերել երկու սարքերը, և դա սովորաբար այն օրն է, երբ նրանցից մեկը կորչում է։

Ինչ է իրականում փոխվում, երբ երկու սեսիա կիսում են մեկ անուն

Առանց այս ընտրանքի, արդեն միացած ընդհանուր անվան տակ նոր միացումը դուրս է մղում նախորդ սեսիան։ Այդ պատճառով նոթբուքը դուրս է ընկնում, երբ պլանշետը միանում է, և դա դիտավորյալ պաշտպանություն է երկիմաստությունից, ոչ թե սխալ։ Ընտրանքի դեպքում երկու սեսիաներն էլ կենդանի են մնում, և սերվերը հետևում է նրանց առանձին՝ ըստ սեսիայի, ոչ ըստ սարքի։

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

Համոզվեք, թե ձեր կառուցվածքն իրականում ինչ է անում, նախքան դրա վրա նախագծելը, որովհետև ընտրանքի ազդեցությունը որոշում է ինքը ընտրանքը, ոչ թե ավանդազրույցները.

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

Այն ստատիկ հասցեն, որը կարծում էիք, թե նշանակել եք

Յուրաքանչյուր հաճախորդի կարգավորումը որոնվում է անունով, և այստեղ է որոգայթը։ client-config-dir ֆայլը, որը կոչված է ընդհանուր անունով կիրառվում է այդ անունն օգտագործող բոլոր սարքերի վրա, ուստի դրա մեջ եղած ifconfig-push-ը երկու սարքերին տալիս է նույն թունելի հասցեն։ Երկրորդ սեսիան կա՛մ չի հաստատվում, կա՛մ բախվում է այնպես, որ նման է երթուղավորման խափանման։

Դինամիկ լողավազանը պատահաբար ավելի լավ է վարվում, որովհետև յուրաքանչյուր սեսիայի հասցե տրվում է լողավազանից ինքնուրույն։ Դա դեռ ձեզ չի տալիս կայուն հասցե յուրաքանչյուր սարքի համար, և իհարկե չի տալիս այդ հասցեին կապված սարքային քաղաքականություն։

Եթե տեղակայումը օգտագործում է username-as-common-name, որոնման բանալին դառնում է նույնականացված օգտվողի անունը՝ վկայականի սուբյեկտի փոխարեն, և նույն բախումը կրկնվում է յուրաքանչյուրի մոտ, ով երկու անգամ մուտք է գործում։ Կարգավորումը ղեկավարող անունը պետք է լինի եզակի յուրաքանչյուր սարքի համար, որպեսզի սարքային կարգավորումը իմաստ ունենա։

Ինչ չի կարող անել համատեղ ինքնությունը հեռացման պահին

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

Մատյանները ժառանգում են նույն երկիմաստությունը։ Կարգավիճակի արտածումը ցույց է տալիս ընդհանուր անուն և իրական հասցե, և երկուսն էլ կարող են պատկանել երկու սարքերից ցանկացածին։ Միջադեպի վերանայումը, որը պետք է իմանա, թե որ մեքենան ինչ է արել, չի կարող պատասխանել այդ հարցին VPN-ի սեփական գրառումներից, որքան էլ մանրամասներ տա մատյանի մակարդակը։

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

Երբ է համատեղումը ճիշտ, և ինչպես սահմանափակել այն

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

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

Ինչ ուղի էլ ընտրեք, փորձարկեք կառավարման մոդելը, ոչ թե մուտքը։ Միացրեք երկու սարքերը, հաստատեք, որ նրանք տարբեր հասցեներ ունեն, ապա մոդելավորեք կորուստ և ստուգեք, որ կարող եք հեռացնել դրանցից ուղիղ մեկը։ openvpn(8) ձեռնարկը սահմանում է ընտրանքի շրջանակը. ձեր հեռացման ընթացակարգը սահմանում է, թե արդյոք համատեղումն իրականում ընդունելի է։