Ինչ է տեղի ունենում, երբ փոխարինում եք VPN-ի վկայագրային մարմինը

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

Մեկ փոխարինում, երկու առանձին փոփոխություն

Վկայագրային մարմինը անուն է, հանրային բանալի և ստորագրող գաղտնի բանալի։ Վավերացնողները երբեք չեն վստահում «CA»-ին վերացական։ Նրանք վստահում են մեկ կոնկրետ վկայագրի, որն արդեն գտնվում է վստահության պահոցում, և ընդունում են թողարկողին միայն այն դեպքում, երբ ստորագրությունների շղթան հասնում է այդ պահված պատճենին։ Ուստի CA-ի փոխարինումը փոխում է երկու բան, որոնք ձախողվում են միմյանցից անկախ՝ որ խարիսխներն են ընդունվում և որ գործընկեր ինքնություններն են թողարկվել դրանց ներքո։

VPN-ի տեղակայումների մեծ մասը վավերացնում է երկու ուղղությամբ։ Հաճախորդը նույնականացնում է դարպասի վկայագիրը, իսկ դարպասը՝ հաճախորդի վկայագիրը։ Փոփոխությունը, որը թարմացնում է միայն հաճախորդի փաթեթը, սերվերին թողնում է մերժելու յուրաքանչյուր հաճախորդի, որը դեռ ներկայացնում է հին CA-ի ինքնություն, և հակառակը նույնքան սովորական է։ Սկզբում թվարկեք կիրառման կետերը՝ հաճախորդների վստահության պահոցները, դարպասի ca ֆայլը, նրա առջև TLS-ը վերջացնող ցանկացած պրոքսի և դրսից վերջնակետը ստուգող զոնդը։

Ինչ է ստուգում վավերացնողը, հերթականությամբ

Ուղու վավերացումը բարձրանում է գործընկերոջ վկայագրից միջանկյալների միջով, մինչև հասնում է վստահելի խարիսխի։ Յուրաքանչյուր քայլում այն ստուգում է ստորագրությունը, համոզվում, որ յուրաքանչյուր վկայագիր իր վավերականության պատուհանում է, և հաստատում, որ հիմնական սահմանափակումներն ու բանալու օգտագործումը թույլ են տալիս թողարկողին ստորագրել։ Միայն դրանից հետո է հավելվածը նայում տերևային վկայագրին՝ սուբյեկտի այլընտրանքային անունները պետք է ծածկեն հավաքված անունը, իսկ ընդլայնված բանալու օգտագործումը պետք է թույլ տա սերվերի կամ հաճախորդի նույնականացում։

Այդ շրջագայությունը ցանցից դուրս կրկնելու համար -CAfile-ը ուղղեք հենց այն փաթեթին, որը տեղակայելու եք, այլ ոչ համակարգի պահոցին։ Հակառակ դեպքում ստուգում եք հոսթը, ոչ թե փոփոխությունը՝

openssl verify -CAfile new-ca.crt gateway.crt
openssl verify -CAfile new-ca.crt -untrusted intermediate.crt client.crt
openssl x509 -in gateway.crt -noout -subject -issuer -dates
openssl s_client -connect gw.example.net:443 -CAfile new-ca.crt

Այդ հրամանը աշխատում է միայն պարզ TLS լսողի դեմ, ինչպիսին դարպասի HTTPS կառավարման էջն է, քանի որ OpenVPN-ի կառավարման ուղին նախորդում է TLS-ին, ուստի s_client-ը չի կարող ստուգել թունելի ձեռքսեղմումը։

Այդ սխալների հետևում ընկած ուղու կառուցման կանոնները գտնվում են RFC 5280 6-րդ բաժնում։ Դրանք բացատրում են ձախողումները, որոնք այլապես կամայական են թվում՝ ժամկետանց միջանկյալ վկայագիր, որի մասին ոչ ոք չէր հիշում, վկայագիր, որի բանալու օգտագործումը արգելում է ստորագրումը, կամ անվան սահմանափակում, որը բացառում է ձեր ստուգվող հոսթը։

Ինչու հին թունելը շարունակում է աշխատել

TLS-ը և OpenVPN-ը երկուսն էլ հաստատված սեսիան պահում են կենդանի ձեռքսեղմումն ավարտվելուց հետո։ Ոչինչ չի վերավավերացնում գործընկերոջ վկայագիրը յուրաքանչյուր փաթեթի համար, ուստի փոփոխությունից առաջ միացած հաճախորդը շարունակում է երթևեկություն անցկացնել, մինչև նորից բանակցի, նորից միանա կամ թունելն ընկնի։ Այդ բացն է պատճառը, որ CA-ի փոխարինումը կարող է մեկ ժամ լավ թվալ, ապա ձախողվել ամենավատ պահին՝ նոութբուքը արթնանում է քնից, NAT-ի քարտեզագրումը լրանում է, դարպասը վերագործարկվում է։

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

Ստատիկ բանալու շերտը առանձին պահեք սրանից։ tls-auth-ը HMAC է ավելացնում կառավարման ուղուն, tls-crypt-ը գաղտնագրում և նույնականացնում է այն, և ոչ մեկը վկայագրային նյութ չի կրում, ուստի դրանցից որևէ մեկի պտույտը առանձին փոփոխություն է՝ իր ձախողման եղանակով։ Տեղակայումները, որոնք խառնում են երկուսը, ավարտվում են հաճախորդով, որի ստատիկ բանալին կարգին է, վկայագիրը՝ հնացած, և սխալի հաղորդագրությունը ոչ մեկը չի հիշատակում։

Սուբյեկտի անվան վերաօգտագործման թակարդը

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

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

Պտույտ, որը ցանցը չի տապալում

Պլանավորված փոխարինման համար սահմանափակ ժամանակով ընդունեք երկու խարիսխները՝ մեկ քայլով փոխարկելու փոխարեն։ Թողարկեք նոր CA-ն և նրա միջանկյալները, նոր խարիսխը դրեք յուրաքանչյուր վավերացնողի փաթեթում հինի կողքին, և միայն դրանից հետո սկսեք դրանից գործընկեր վկայագրեր թողարկել։ Հին ինքնություններով գործընկերները վավերացվում են հին խարիսխի դեմ, իսկ նորերը աշխատում են նորի դեմ։

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

Դուրս բերեք հակառակ ուղղությամբ։ Նորից թողարկեք յուրաքանչյուր ինքնություն, որը պետք է մնա, հաստատեք, որ յուրաքանչյուրը ներկայացնում է նոր շղթան, ապա հեռացրեք հին խարիսխը փաթեթներից։ Հանեք հին CA-ի գաղտնի բանալին ծառայությունից, քանի որ դեռ ստորագրել կարող թողարկողը նշանակում է, որ պտույտը ավարտված չէ։ Պահեք վկայագրերն ու թողարկման գրառումները աուդիտի համար։ Կորցրած թողարկողը վերականգնվում է նույն վստահությանը, իսկ բացահայտումը պահանջում է նոր ինքնություններ և հին խարիսխին վերադարձ չի լինում։

Ստուգեք արդյունքը, ոչ թե ֆայլերի ցանկը

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

Հաստատեք, որ նոր ինքնությամբ թարմ կապը հաջողվում է, ապա հաստատեք, որ դուրս բերված CA-ի թողարկած ինքնությունը մերժվում է։ Այդ երկրորդ փորձարկումն է, որ մարդիկ բաց են թողնում, և միակը, որը ցույց է տալիս, որ հին իշխանությունն այլևս հասանելիություն չի տալիս։ Այնտեղ, որտեղ տեղակայումը հենվում է CRL-ի կամ OCSP-ի վրա, ստուգեք, որ նոր վկայագրերի բաշխման կետերը լուծվում են, և որ հարցնող գործընկերները հասնում են պատասխանողին։

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