Nebula-ի վկայականի վերաբեռնումը IP-ն չփոխեց. ահա թե ինչու
Վերաբեռնումը վերընթերցում է հոսթի հավատարմագրերը միայն այն դեպքում, երբ overlay-հասցեն մնում է նույնը։ Հասցեի փոփոխությունը նշանակում է վերագործարկում և ցանցի փոփոխություն, ոչ թե կրկնակի փորձ։
Դուք թողարկում եք նոր հոսթ-վկայական այլ overlay-հասցեով, պատճենում այն հին ֆայլի վրա, ուղարկում վերաբեռնումը, և հոսթը շարունակում է պատասխանել նախկին հասցեով։ Բնական արձագանքն է ենթադրել, որ վերաբեռնումը ձախողվել է կամ սխալ ֆայլ է կարդացվել։ Սովորաբար ոչ մեկը չի պատահել. ընթացքի մեջ գտնվող պրոցեսը դիտավորյալ պահպանել է այն ինքնությունը, որն արդեն ուներ, որովհետև փոխարինումը փոխել է մի բան, որը վերաբեռնումը չի կարող կիրառել։
Nebula-ի PKI վերաբեռնման աջակցությունը փաստաթղթավորված է հենց այդ սահմանով, և հեշտ է բաց թողնել այն, երբ նույն փաստաթղթերը ցույց են տալիս, որ վերաբեռնումը աշխատում է այլ փոփոխությունների համար։
Ինչ է իրականում վերընթերցում վերաբեռնումը
Հոսթ-վկայականը պարզապես հավատարմագիր չէ այնպես, ինչպես SSH բանալին։ Այն կրում է overlay-հասցեն, հոսթի անունը, խմբերի անդամակցությունները և վավերականության պատուհանը, և այս բոլորը կապված են CA-ի ստորագրությամբ։ Դեմոնն օգտագործում է այդ ստորագրված բովանդակությունը՝ որոշելու, թե ինչպես ներկայանա և ինչ կանոններ կիրառվեն իր նկատմամբ։
Վերաբեռնումը թույլ է տալիս պրոցեսին վերցնել թարմացված հավատարմագիր՝ առանց իր թունելները կորցնելու, ինչը արժեքավոր է սովորական ռոտացիայի համար՝ նույն հասցեն, նույն անունը, նույն խմբերը, ավելի ուշ ժամկետ։ Սահմանափակումն այն է, որ ինքնությունը պետք է մնա նույնը։ Փոխեք overlay-հասցեն, և վերաբեռնման ուղին չի կարող կիրառել այն, որովհետև հասցեն այն բանի մասն է, ինչին արդեն իսկ պարտավորվել է աշխատող օրինակը։
Այսպիսով՝ ձեր տեսած վարքը փաստաթղթավորված սահմանն է, որը կատարում է իր աշխատանքը, ոչ թե լուռ ձախողում։ Սկավառակի ֆայլը նոր է. հիշողության մեջ ինքնությունը հին է. պրոցեսը վերագործարկումից բացի այդ տարբերությունը հարթելու աջակցվող ճանապարհ չունի։
Հասցեն, անունը և խմբերը մեկ ինքնություն են
Օգտակար է վկայականը դիտարկել որպես մեկ գրառում, այլ ոչ թե առանձին խմբագրելի դաշտերի հավաքածու։ Հասցեն տեղափոխելը նախապատվություն փոխելու նման չէ, որովհետև հասցեն հանդիպում է այլ հոսթերի peer-կարգավորումներում, ծառայությունների կապերում և ինքնության դեմ գրված քաղաքականություններում։
| Field | What changes when you replace it |
|---|---|
| Overlay address | Peers that pinned the old address, service bindings, and any rule written against it |
| Host name | Name-based policy and the identities other hosts expect to see |
| Groups | Which access rules match, even if the address stays identical |
| Validity window | Nothing structural, which is why renewal reloads cleanly |
Խմբերը առանձին տողի արժանի են, որովհետև առաջացնում են նույն շփոթության ավելի լուռ տարբերակը։ Հոսթը, որը պահում է իր հասցեն, բայց փոխում է խմբերը, վերագործարկումից հետո կարող է հասնել այլ ծառայությունների, և թեստը, որը միայն ping է անում հին հասցեին, բոլորովին առողջ կթվա, մինչդեռ դրա տակ մուտքի որոշումները փոխվել են։ Ստուգեք կանոնով ընդգրկված մեկ ծառայություն, ոչ միայն հասանելիությունը։ Սա է թունելը հաստատելու և քաղաքականությունը հաստատելու տարբերությունը։
Համեմատեք բեռնված վկայականը փոխարինողի հետ
Նախքան կենթադրեք, որ դեմոնը անտեսել է ֆայլը, կարդացեք երկուսն էլ։ Տպեք այն վկայականը, որը մտադիր եք բեռնել, և հաստատեք այն դաշտերը, որոնք կարծում եք՝ փոխել եք, ապա հաստատեք, որ աշխատող կարգավորումը ցույց է տալիս այդ ուղին, այլ ոչ թե պատճենն այլ տեղ։
nebula-cert print -path /etc/nebula/host.crt
systemctl status nebula
ps -o args= -p $(pgrep -f 'nebula -config' | head -1)Պրոցեսի արգումենտներն ավելի կարևոր են, քան մարդիկ սպասում են։ Միավորը, որը փոխանցում է -config /etc/nebula/config.yml, կարդում է այդ ֆայլի pki.cert գրառումը, և ժամանակավոր պանակում տեղադրված վկայականը ոչնչի վրա չի ազդում։ Ստուգեք ուղին աշխատող հրամանի տողում, ոչ թե այն փաստաթղթում, որին հետևել եք։ Եթե երկուսը տարբեր են, դուք գտել եք խնդիրը՝ առանց վկայականին դիպչելու։
Եթե նոր վկայականն այլ հասցե ունի, իսկ պրոցեսը պահել է հինը, ապա հիմա բացատրություն ունեք, ոչ թե հանելուկ։ Վերագործարկեք այն, եթե դա ընդունելի է, և հասցեի փոփոխությունը դիտարկեք որպես պլանավորված ցանցային փոփոխություն, ոչ թե պատահական։
Հասցեի փոփոխությունը ցանցի փոփոխություն է
Պլանավորեք այնպես, ինչպես կպլանավորեիք մեքենայի տեղափոխումը։ Մյուս հոսթերը գուցե ամրացրել են հին հասցեն իրենց կարգավորումներում, ծառայությունները գուցե բացահայտ կապված են դրան, և firewall-ի կանոնները գուցե գրված են դրա դեմ։ Վկայականը փոխելը տեղափոխում է հոսթը, իսկ հոսթը տեղափոխելը անվավեր է դարձնում ենթադրությունները այլ տեղերում։
Այս ընթացքում հասանելի պահեք կառավարման երկրորդ ուղի, որովհետև գուցե հենց overlay-կապն է, որ դուք ընդհատում եք։ Դա անել այն թունելի վրայով, որը պատրաստվում եք կոտրել, հինգ րոպեի փոփոխությունը տեղում այցի վերածելու դասական եղանակն է։
Վերագործարկման ընդունելիությունը կախված է նրանից, թե ինչ է անում հոսթը, և դա պլանավորման, ոչ տեխնիկական հարց է։ Պարտադիր է գիտակցել վերագործարկման պահանջը՝ վերաբեռնումը հինգերորդ անգամ ուղարկելու փոխարեն։
Հին հավատարմագրերը հեռացրեք առանձին
Մեկ մեքենայի վրա փոխարինում տեղադրելը թողնում է, որ յուրաքանչյուր peer դեռ վստահի այն հավատարմագրերին, որոնք արդեն գիտի։ Եթե փոփոխության պատճառը փոխզիջումն էր, հին ինքնությունը պետք է հեռացվի վստահության կամ արգելափակման ցանկի ընթացակարգով, որպեսզի peer-երը իսկապես մերժեն այն։
Սա առանձին քայլ է՝ իր ստուգմամբ. մեկ այլ հոսթից հաստատեք, որ հին ինքնությունն այլևս չի աշխատում, փոխարենը ենթադրելու, թե նոր ֆայլը կատարել է աշխատանքը։ Nebula-ի PKI կարգավորման փաստաթղթերը ներառում են վերաբեռնվող պարամետրերը և այստեղ նկարագրված հասցեի սահմանափակումը, և արժե այն ամբողջությամբ կարդալ նախքան արտադրական որևէ բան ռոտացնելը։