AWS VPN-ի PSK-ի պտտում. որ թունելն է ընկնում և երբ

Թունելն ընկնում է այն պահին, երբ երկու ծայրերը համաձայն չեն նախապես համօգտագործված բանալու շուրջ, և մնում է ներքևում, քանի դեռ երկու կողմերը չեն կրում նոր արժեքը։ Այս մասը սպասելի է. AWS-ը փոփոխությունը դիտարկում է որպես ընտրված թունելի ընդհատում, և գործընկերը չի ավարտի IKE-ն, քանի դեռ բանալիները տարբերվում են։ Այն, ինչ զարմացնում է մարդկանց, երկրորդ կեսն է։ Մյուս թունելն ինքնուրույն չի վերցնում երթևեկությունը, եթե չեք ստուգել, որ այն կարող է կրել այն։ Պտտեք այս հերթականությամբ, և ընդհատումը կմնա մեկ թունելի ներսում։

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

ModifyVpnTunnelOptions-ը վերագրում է մեկ թունելի ընտրանքները, որը նույնականացվում է իր արտաքին IP հասցեով։ Թունելը քանդվում և նորից կառուցվում է, ուստի IKE-ն և IPsec-ը բանակցում են զրոյից նոր բանալիով։ AWS-ը նշում է, որ ընդհատումը կարող է տևել մի քանի րոպե, ինչը բավական երկար է, որպեսզի երթուղավորման արձանագրությունը նկատի այն։ Նույն կապի մյուս թունելին այս կանչը չի դիպչում։

Կա երկրորդ ազդեցություն, որն արժե իմանալ նախքան որևէ բան ուղարկելը։ Փոփոխության գործողությունը վերցնում է թունելի ընտրանքների ամբողջ հավաքածուն, ուստի բաց թողած դաշտը հետ է գրվում իր լռելյայն արժեքով։ Եթե դուք կարգավորել եք 1-ին կամ 2-րդ փուլի կյանքի տևողությունները կամ մեռած գործընկերոջ հայտնաբերման կարգավորումները, փոխանցեք ընթացիկ արժեքները նույն հարցման մեջ կամ պլանավորեք դրանց վերականգնումը հետո։

Նախ կարդացեք ընթացիկ արժեքները, ապա փոխեք մեկ դաշտ։ Այս հաջորդականությունը այս առաջադրանքի ողջ կարգապահությունն է։

Նախ համապատասխանեցրեք AWS-ի թունելը ճիշտ գործընկերոջը

Կոնսոլը թունելները պիտակավորում է ըստ հերթականության, և ձեր սարքը չի օգտագործում այդ պիտակը։ Նույնականացրեք թունելն իր արտաքին IP հասցեով և համապատասխանեցրեք այն հաճախորդի դարպասի գործընկերոջ բաժնին։ Տեղական կազմաձևում թունել 1-ը ապացույց չէ, որ դուք խմբագրում եք այն թունելը, որը AWS-ը կոչում է թունել 1։

Սկսեք հենց կապից, որը թվարկում է երկու թունելները և բանալին, որը յուրաքանչյուրն այժմ պահում է.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

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

Նախ թույլ տվեք մյուս թունելին կրել երթևեկությունը

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

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

Պտտեք մեկ թունել, ապա ստուգեք իրական երթևեկությամբ

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

1. Թարմացրեք հաճախորդի դարպասի գործընկերը ընտրված արտաքին հասցեի համար կամ նախապատրաստեք փոփոխությունը, որպեսզի այն ուժի մեջ մտնի API-ի կանչից վայրկյաններ անց։
2. Ուղարկեք փոփոխության կանչը նոր բանալիով, գումարած ընթացիկ կյանքի տևողությունները և DPD արժեքները։
3. Սպասեք, որ IKE-ն և IPsec-ը վերադառնան, ապա հաստատեք երթուղիները և պահանջվող նախածանցերը։
4. Անցկացրեք ներկայացուցչական հավելվածի հոսք այդ թունելով և դիտեք երկու ուղղությունները։

Թունելն անօգտագործելի է, քանի դեռ ծայրերը համաձայն չեն և քանի դեռ AWS-ը կիրառում է փոփոխությունը, ուստի գործընկերոջ թարմացումը պետք է հետևի անմիջապես, ոչ թե ճաշից հետո։ Միայն երբ փոփոխված թունելը կրում է իրական երթևեկություն, պետք է կրկնեք ընթացակարգը մյուսի վրա։

Կանգ առեք, եթե առաջին թունելից հետո վերականգնումը կամ երթուղավորումը դեռ անորոշ են։ Երկու կիսաաշխատող թունել ավելի վատ է, քան մեկը, որի աշխատանքը գիտեք։

Երբ վերականգնումը կանգ է առնում, կարդացեք IKE կողմը

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

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Եթե փոփոխությունը պետք է հետարկվի, մի վերականգնեք հին բանալին միայն այն պատճառով, որ այն նախկինում աշխատում էր։ Վտանգված բանալին վերաբերվեք որպես վտանգված և փոխարենը շտկեք բանակցությունը։ Ավարտեք երկու թունելների ստուգմամբ և գաղտնիքների գույքագրումը թարմացնելով, որպեսզի յուրաքանչյուր գործընկեր գրանցի, թե որ արժեքն ունի, և AWS-ի թունելի ընտրանքների փաստաթղթերը պահեք runbook-ի կողքին։