Արժե՞ արդյոք միացնել AWS VPN թունելի մատյանները գործող թունելի վրա։

Site-to-Site VPN-ի համար թունելի ակտիվության մատյանների միացումը փոքր փոփոխություն է, որը կարող է գցել այն թունելը, որը նա չափում է։ AWS-ը նախազգուշացնում է, որ գոյություն ունեցող թունելի վրա մատյանավորման միացումը կարող է ընդհատել այն մի քանի րոպեով, ուստի հետաքրքիր հարցը ոչ թե այն է, թե ինչպես շրջել դրոշակը, այլ թե որ թունելի վրա և երբ շրջել այն։ Երեք պայման են որոշում կարգը՝ արդյոք մյուս թունելը իսկապես կրում է երթուղիները, ձեզ պետք են ծառայության իրադարձություններ, թե BGP իրադարձություններ, և փոփոխությունը գնում է կոնսոլով, թե թունելի ընտրանքների API-ով։ Սխալվեք դրանցում, և կհայտնվեք կա՛մ ընդհատման, կա՛մ ոչնչով լցված մատյանների խմբի հետ։

Երեք պայման են որոշում կարգը

Սկսեք այն բանի ինքնությունից, ինչը փոխում եք։ Ձեզ պետք են VPN կապի ID-ն, տարածաշրջանը և կոնկրետ թունելի արտաքին IP հասցեն, քանի որ այս հատկության յուրաքանչյուր մատյանի կարգավորում թունելի համար է, ոչ թե կապի։ Սխալ արտաքին հասցեի վրա կիրառված փոփոխությունը փոփոխություն է այն թունելում, որը ոչ ոք չէր վերականգնում։

Նպատակակետը նույն տարածաշրջանում գտնվող CloudWatch մատյանների խումբն է՝ ձեր իրականում ցանկացած պահպանման և մուտքի քաղաքականությամբ։ AWS-ը խորհուրդ է տալիս /aws/vendedlogs/ նախածանցը այդ խմբերի համար, քանի որ այն խուսափում է ռեսուրսային քաղաքականության չափի սահմաններից, որոնց կարող են բախվել սովորական անունները։ /aws/vendedlogs/vpn/branch-a-activity-ի նման անունը միայն օրինակ է. կարևոր է, որ խումբը գոյություն ունի, որ առաքման դերը կարող է գրել դրա մեջ, և որ երկուսն էլ կառավարվում են VPN կարգավորումը տիրողի կողմից։ Անունը թույլտվություններ չի տալիս, և առաքման քաղաքականությամբ չստեղծված խումբը սխալի փոխարեն լռություն է առաջացնում։

Առաջին պայման՝ պահուստային թունել, որն իսկապես կրում է տրաֆիկ

Սա այն պայմանն է, որը թիմերը բաց են թողնում։ Երկու կարգավորված թունելները ապացույց չեն, որ կիրառությունը ունի օգտագործելի այլընտրանքային ուղի։

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

Երկրորդ պայման՝ ակտիվության մատյան, թե BGP մատյան

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

Ակտիվության դրոշակի միացումը պահանջ չէ ծառայության բոլոր հնարավոր հոսքերի համար։ Եթե կասկածը երթուղավորումն է, միացրեք երկուսն էլ. եթե կասկածը 1-ին կամ 2-րդ փուլի բանակցությունն է, ակտիվության հոսքն է, որ դա ցույց կտա։

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

Երրորդ պայման՝ կոնսոլով փոփոխություն, թե թունելի ընտրանքների API

Եթե մարդը միանվագ փոփոխություն է անում, կոնսոլի ուղին լավ է. VPC console, Site-to-Site VPN connections, ընտրեք կապը, Actions, Modify VPN tunnel options, ընտրեք արտաքին IP-ն, միացրեք Tunnel activity log-ը, ընտրեք խումբը և ելքի ձևաչափը, պահեք պատուհանի ներսում։ Եթե VPN-ը կառավարվում է որպես կոդ, նույն սեղմումը շեղում է, որը հետագայում կհամաձայնեցնեք։

Ավտոմատացման համար թունելի ընտրանքների ակտիվության-մատյանի մասը ֆիքսված ձև ունի. LogOptions-ը պարունակում է CloudWatchLogOptions՝ LogEnabled, LogGroupArn և LogOutputFormat դաշտերով։ Այդ բլոկը բեկոր է, ոչ հարցում. modify-vpn-tunnel-options-ին դեռ պետք են կապի ID-ն և թունելի արտաքին IP-ն, իսկ մնացած թունելի կարգավորումները պետք է պահպանի ձևանմուշի տերը։ BGP մատյանավորումն օգտագործում է իր սեփական BgpLogEnabled, BgpLogGroupArn և BgpLogOutputFormat բանալիները նույն կառուցվածքում։ Կարդացեք փոփոխությունը հետ՝ describe-vpn-connections-ով, փոխարենը վստահելու, որ կանչը կիրառվել է։

Ինչ կարող են և ինչ չեն կարող ասել գրառումները

Երբ առաջին թունելը պատրաստ է և նախատեսված ուղին հասանելի է, կրկնեք նույն վերահսկվող հաջորդականությունը երկրորդ թունելի համար, եթե դրա մատյաններն էլ են ձեզ պետք։ Մեկ թունել միաժամանակ՝ դա է ամբողջ իմաստը։

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

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