Ar reikėtų įjungti AWS VPN tunelio žurnalus veikiančiame tunelyje?

Site-to-Site VPN tunelio veiklos žurnalų įjungimas yra mažas pakeitimas, kuris gali numesti tunelį, kurį jis matuoja. AWS įspėja, kad žurnalų įjungimas esamame tunelyje gali jį kelioms minutėms nutraukti, todėl įdomus klausimas yra ne kaip perjungti vėliavėlę, o kuriame tunelyje ir kada tai padaryti. Tvarką nustato trys sąlygos: ar kitas tunelis tikrai perduoda maršrutus, ar jums reikia paslaugos įvykių, ar BGP įvykių, ir ar pakeitimas atliekamas per konsolę, ar per tunelio parinkčių API. Jei tai supainiosite, liksite arba su pertraukimu, arba su žurnalų grupe, pilna nieko.

Tvarką nustato trys sąlygos

Pradėkite nuo to, ką keičiate, tapatybės. Jums reikia VPN ryšio ID, regiono ir konkretaus tunelio išorinio IP adreso, nes kiekvienas šios funkcijos žurnalo nustatymas yra pagal tunelį, o ne pagal ryšį. Pakeitimas, pritaikytas neteisingam išoriniam adresui, yra pakeitimas tunelyje, kurio niekas nedebugino.

Paskirties vieta yra CloudWatch žurnalų grupė tame pačiame regione su saugojimo ir prieigos politika, kurios tikrai norite. AWS rekomenduoja šioms grupėms prefiksą /aws/vendedlogs/, nes jis išvengia išteklių politikos dydžio apribojimų, su kuriais gali susidurti paprasti pavadinimai. Pavadinimas kaip /aws/vendedlogs/vpn/branch-a-activity yra tik iliustracija; svarbu tai, kad grupė egzistuoja, kad pristatymo vaidmuo gali į ją rašyti ir kad abu valdo tas, kam priklauso VPN konfigūracija. Pavadinimas nesuteikia leidimų, o grupė, sukurta be pristatymo politikos, sukuria tylą, o ne klaidą.

Pirmoji sąlyga: atsarginis tunelis, kuris tikrai perduoda srautą

Tai sąlyga, kurią komandos praleidžia. Du sukonfigūruoti tuneliai nėra įrodymas, kad programėlė turi naudojamą alternatyvų kelią.

Prieš liesdami vieną tunelį, patvirtinkite, kad kitas perduoda svarbius maršrutus: patikrinkite maršrutizavimo lentelę kliento šliuzo pusėje ir patvirtinkite, kad programėlė tikrai gali persijungti. AWS pertraukos langas yra minutės, o ne sekundės, o tunelis, egzistuojantis tik popieriuje, diagnostinį pakeitimą paverčia pertraukimu. Jei atsarginis kelias neįrodytas, suplanuokite pakeitimą taip pat rūpestingai kaip bet kurį kitą maršrutizavimo pakeitimą, o ne laikykite žurnalų įjungimo pasyviu veiksmu. Instrumentuokite tunelį, kurio elgesį bandote paaiškinti, o ne tą, į kurį lengviau patekti.

Antroji sąlyga: veiklos žurnalas arba BGP žurnalas

Tai nusprendžia, ką iš tikrųjų galėsite perskaityti. Veiklos įrašai apima paslaugos įvykius, tokius kaip IKE ir IPsec būsenų perėjimai ir DPD pranešimai, ko norite, kai tunelis nepakyla arba nuolat atnaujina raktus. BGP įrašai yra atskiras srautas su savo valdikliais, ir jie atsako į kitą klausimą: ar maršrutai buvo apsikeisti ir atšaukti taip, kaip tikėtasi.

Veiklos vėliavėlės įjungimas nėra prašymas kiekvienam srautui, kurį paslauga gali išleisti. Jei įtariamas maršrutizavimas, įjunkite abu; jei įtariamos 1 arba 2 fazės derybos, veiklos srautas tai parodys.

Nė vienas srautas nėra paketų gaudymas, ir šis skirtumas išsprendžia daugiau bilietų, nei turėtų. Veiklos ir BGP įrašai pasako, ką paslauga padarė su tuneliu ir sesija, o ne ką jūsų programėlė per juos nusiuntė. Kreipimasis į tunelio žurnalus, norint derinti programėlės laiko limitą, yra kategorijos klaida, ir ji paprastai kainuoja pertraukos langą, kol kas nors tai pastebi. Pirmiausia pasirinkite klausimą, paskui srautą, galintį į jį atsakyti.

Trečioji sąlyga: pakeitimas konsolėje arba tunelio parinkčių API

Jei žmogus atlieka vienkartinį pakeitimą, konsolės kelias tinka: VPC console, Site-to-Site VPN connections, pasirinkite ryšį, Actions, Modify VPN tunnel options, pasirinkite išorinį IP, įjunkite Tunnel activity log, pasirinkite grupę ir išvesties formatą, išsaugokite lange. Jei VPN valdomas kaip kodas, tas pats paspaudimas yra nukrypimas, kurį vėliau suderinsite.

Automatizavimui tunelio parinkčių veiklos žurnalo dalis turi fiksuotą formą: LogOptions, kuriame yra CloudWatchLogOptions su LogEnabled, LogGroupArn ir LogOutputFormat. Tas blokas yra fragmentas, o ne užklausa; modify-vpn-tunnel-options vis dar reikia ryšio ID ir tunelio išorinio IP, o likusius tunelio nustatymus turi išsaugoti šablono savininkas. BGP žurnalas naudoja savo raktus BgpLogEnabled, BgpLogGroupArn ir BgpLogOutputFormat toje pačioje struktūroje. Perskaitykite pakeitimą atgal su describe-vpn-connections, o ne pasitikėkite, kad kvietimas buvo pritaikytas.

Ką įrašai gali ir ko negali pasakyti

Kai pirmasis tunelis baigtas ir numatytas kelias prieinamas, pakartokite tą pačią kontroliuojamą seką antrajam tuneliui, jei jo žurnalų taip pat reikia. Vienas tunelis vienu metu yra visa esmė.

Įrašai ateina srautais, identifikuojamais pagal ryšį ir tunelio išorinį adresą, todėl koreliuokite su ta tapatybe, o ne tikėkitės, kad istorija atsiras atgaline data. Niekas prieš pakeitimą neegzistuoja, ir joks laukimas neužpildo spragos. Jei jums reikia bazinės linijos, prieš pakeitimą užfiksuokite dabartinę tunelio būseną ir maršrutizavimo lentelę, kad būtų su kuo palyginti.

Laikykite žurnalų grupę, jos saugojimą, pristatymo leidimus ir tunelio parinkčių bloką tame pačiame inventoriuje kaip ir patį VPN, nes tai viena konfigūracija, paskirstyta keturiose vietose. AWS žurnalų įjungimo procedūra dokumentuoja kiekvieno tunelio darbo eigą ir įspėjimą apie pertraukimą, ir ją verta perskaityti prieš pakeitimą, o ne po jo. Tada patikrinkite iš eilės: tunelis grįžo, įrašai pasirodo laukiamame sraute, o įrašai atsako į klausimą, dėl kurio atidarėte bilietą. Jei trečiasis nepavyksta, problema buvo srauto pasirinkimas, o ne žurnalai.