Ĉu vi aktivigu AWS VPN-tunelajn protokolojn sur aktiva tunelo?

Ŝalti tunelajn agadprotokolojn por Site-to-Site VPN estas malgranda ŝanĝo, kiu povas faligi la tunelon, kiun ĝi mezuras. AWS avertas, ke ŝalti protokoladon sur ekzistanta tunelo povas interrompi ĝin dum pluraj minutoj, do la interesa demando ne estas kiel renversi la flagon, sed sur kiu tunelo renversi ĝin kaj kiam. Tri kondiĉoj determinas la ordon: ĉu la alia tunelo vere portas la itinerojn, ĉu vi bezonas servoeventojn aŭ BGP-eventojn, kaj ĉu la ŝanĝo iras tra la konzolo aŭ tra la API de tunelaj opcioj. Se vi maltrafos tion, vi finos aŭ kun interrompo aŭ kun protokolgrupo plena de nenio.

Tri kondiĉoj determinas la ordon

Komencu per la identeco de la afero, kiun vi ŝanĝas. Vi bezonas la VPN-konektan ID, la regionon kaj la eksteran IP-adreson de la koncerna tunelo, ĉar ĉiu protokola agordo en ĉi tiu funkcio estas po tunelo kaj ne po konekto. Ŝanĝo aplikita al la malĝusta ekstera adreso estas ŝanĝo al tunelo, kiun neniu sencimigis.

La celo estas CloudWatch-protokolgrupo en la sama regiono, kun la retenado kaj alirpolitiko, kiun vi vere volas. AWS rekomendas la prefikson /aws/vendedlogs/ por ĉi tiuj grupoj, ĉar ĝi evitas la grandlimojn de rimedpolitikoj, kiujn ordinaraj nomoj povas trafi. Nomo kiel /aws/vendedlogs/vpn/branch-a-activity estas nur ilustra; gravas, ke la grupo ekzistas, ke la livera rolo povas skribi en ĝin, kaj ke ambaŭ estas administrataj de tiu, kiu posedas la VPN-agordon. La nomo ne donas permesojn, kaj grupo kreita sen la livera politiko produktas silenton anstataŭ eraron.

Unua kondiĉo: redunda tunelo, kiu vere portas trafikon

Ĉi tiu estas la kondiĉo, kiun teamoj preterlasas. Du agorditaj tuneloj ne pruvas, ke la aplikaĵo havas uzeblan alternativan vojon.

Antaŭ ol tuŝi unu tunelon, konfirmu, ke la alia portas la itinerojn, kiuj gravas: kontrolu la enrutan tabelon sur la flanko de la klienta pordego kaj konfirmu, ke la aplikaĵo vere povas ŝanĝiĝi al la rezerva vojo. La interrompa fenestro de AWS estas minutoj, ne sekundoj, kaj tunelo, kiu ekzistas nur surpapere, igas diagnostikan ŝanĝon interrompo. Se la rezerva vojo ne estas pruvita, planu la ŝanĝon kun la sama zorgo kiel ĉiu alia enruta ŝanĝo anstataŭ trakti protokoladon kiel pasivan. Instrumentu la tunelon, kies konduton vi provas klarigi, ne tiun, kiu estas pli facile atingebla.

Dua kondiĉo: agadprotokolo aŭ BGP-protokolo

Ĉi tiu decidas, kion vi efektive povos legi. Agadaj rikordoj kovras servoeventojn kiel IKE- kaj IPsec-statajn transirojn kaj DPD-mesaĝojn, kio estas tio, kion vi volas, kiam la tunelo ne leviĝas aŭ daŭre rekreas ŝlosilojn. BGP-rikordoj estas aparta fluo kun propraj kontroloj, kaj ili respondas al alia demando: ĉu itineroj estis interŝanĝitaj kaj retiritaj laŭatende.

Ŝalti la agadflagon ne estas peto por ĉiu fluo, kiun la servo povas elsendi. Se la suspekto estas enrutado, ŝaltu ambaŭ; se la suspekto estas la intertraktado de fazo 1 aŭ fazo 2, la agadfluo estas tiu, kiu montros ĝin.

Neniu el la fluoj estas paketa kaptado, kaj tiu distingo decidas pli da biletoj ol ĝi devus. Agadaj kaj BGP-rikordoj diras al vi, kion la servo faris kun la tunelo kaj la seanco, ne kion via aplikaĵo sendis tra ĝi. Ekpreni tunelajn protokolojn por sencimigi aplikaĵan tempolimon estas kategoria eraro, kaj ĝi kutime kostas interrompan fenestron antaŭ ol iu rimarkas. Elektu unue la demandon, poste la fluon, kiu povas respondi ĝin.

Tria kondiĉo: konzola ŝanĝo aŭ API de tunelaj opcioj

Se homo faras unufojan ŝanĝon, la konzola vojo estas en ordo: VPC console, Site-to-Site VPN connections, elektu la konekton, Actions, Modify VPN tunnel options, elektu la eksteran IP, ŝaltu Tunnel activity log, elektu la grupon kaj la eligan formaton, konservu ene de la fenestro. Se la VPN estas administrata kiel kodo, la sama klako estas deflankiĝo, kiun vi poste kongruigos.

Por aŭtomatigo, la agadprotokola parto de la tunelaj opcioj havas fiksan formon: LogOptions enhavas CloudWatchLogOptions kun LogEnabled, LogGroupArn kaj LogOutputFormat. Tiu bloko estas fragmento, ne peto; modify-vpn-tunnel-options ankoraŭ bezonas la konektan ID kaj la eksteran IP de la tunelo, kaj la ceterajn tunelajn agordojn devas konservi tiu, kiu posedas la ŝablonon. BGP-protokolado uzas siajn proprajn ŝlosilojn BgpLogEnabled, BgpLogGroupArn kaj BgpLogOutputFormat en la sama strukturo. Legu la ŝanĝon reen per describe-vpn-connections anstataŭ fidi, ke la voko aplikiĝis.

Kion la rikordoj povas kaj ne povas diri al vi

Post kiam la unua tunelo estas preta kaj la celita vojo disponeblas, ripetu la saman kontrolitan sinsekvon por la dua tunelo, se vi ankaŭ bezonas ĝiajn protokolojn. Unu tunelo samtempe estas la tuta punkto.

Rikordoj alvenas en fluoj identigitaj de la konekto kaj la ekstera adreso de la tunelo, do korelaciu kun tiu identeco anstataŭ atendi, ke historio aperos retroaktive. Nenio antaŭ la ŝanĝo ekzistas, kaj neniu kvanto da atendo plenigas la breĉon. Se vi bezonas bazlinion, registru la nunan tunelan staton kaj la enrutan tabelon antaŭ la ŝanĝo, por ke ekzistu io por kompari.

Tenu la protokolgrupon, ĝian retenadon, ĝiajn liverajn permesojn kaj la tunelan opciblokon en la sama inventaro kiel la VPN mem, ĉar ili estas unu agordo disvastigita sur kvar lokojn. La proceduro de AWS por ŝalti protokolojn dokumentas la laborfluon po tunelo kaj ĝian interrompan averton, kaj indas legi ĝin antaŭ la ŝanĝo anstataŭ poste. Poste kontrolu laŭorde: la tunelo revenis, rikordoj aperas en la atendata fluo, kaj la rikordoj respondas la demandon, por kiu vi malfermis la bileton. Se la tria malsukcesas, la problemo estis la elekto de fluo kaj ne la protokolado.