Máte povolit protokoly tunelu AWS VPN na živém tunelu?

Zapnutí protokolů aktivity tunelu pro Site-to-Site VPN je malá změna, která může shodit tunel, který měří. AWS varuje, že povolení protokolování na existujícím tunelu ho může na několik minut přerušit, takže zajímavá otázka není, jak přepnout příznak, ale na kterém tunelu ho přepnout a kdy. Pořadí určují tři podmínky: zda druhý tunel skutečně nese trasy, zda potřebujete události služby, nebo události BGP, a zda změna jde přes konzolu, nebo přes API možností tunelu. Když je zvoráte, skončíte buď s výpadkem, nebo se skupinou protokolů plnou ničeho.

Tři podmínky určují pořadí

Začněte identitou věci, kterou měníte. Potřebujete ID připojení VPN, oblast a vnější IP adresu konkrétního tunelu, protože každé nastavení protokolu v této funkci je na tunel, ne na připojení. Změna použitá na špatnou vnější adresu je změna tunelu, který nikdo neladil.

Cílem je skupina protokolů CloudWatch ve stejné oblasti s politikou uchovávání a přístupu, kterou skutečně chcete. AWS doporučuje předponu /aws/vendedlogs/ pro tyto skupiny, protože obchází limity velikosti zásad prostředků, na které mohou obyčejná jména narazit. Jméno jako /aws/vendedlogs/vpn/branch-a-activity je jen ilustrativní; důležité je, že skupina existuje, že do ní role doručování může zapisovat a že obojí spravuje ten, kdo vlastní konfiguraci VPN. Jméno neuděluje oprávnění a skupina vytvořená bez zásady doručování produkuje ticho, ne chybu.

První podmínka: záložní tunel, který skutečně nese provoz

Tuto podmínku týmy přeskakují. Dva nakonfigurované tunely nejsou důkazem, že aplikace má použitelnou alternativní cestu.

Než se dotknete jednoho tunelu, potvrďte, že druhý nese trasy, na kterých záleží: zkontrolujte směrovací tabulku na straně zákaznické brány a potvrďte, že aplikace skutečně umí přepnout. Okno přerušení u AWS je v minutách, ne v sekundách, a tunel, který existuje jen na papíře, mění diagnostickou změnu ve výpadek. Pokud záložní cesta není prokázaná, naplánujte změnu se stejnou péčí jako každou jinou změnu směrování, místo abyste protokolování brali jako pasivní. Instrumentujte tunel, jehož chování se snažíte vysvětlit, ne ten, ke kterému je snazší se dostat.

Druhá podmínka: protokol aktivity, nebo protokol BGP

Tato podmínka rozhoduje, co skutečně budete moci číst. Záznamy aktivity pokrývají události služby, jako jsou přechody stavu IKE a IPsec a zprávy DPD, což je to, co chcete, když tunel nenaběhne nebo neustále obnovuje klíče. Záznamy BGP jsou samostatný tok s vlastními ovládacími prvky a odpovídají na jinou otázku: zda byly trasy vyměněny a odvolány podle očekávání.

Zapnutí příznaku aktivity není žádost o každý tok, který služba může vysílat. Pokud je podezření na směrování, zapněte obojí; pokud je podezření na vyjednávání fáze 1 nebo fáze 2, tok aktivity je ten, který to ukáže.

Ani jeden tok není zachytávání paketů a tento rozdíl rozhoduje více tiketů, než by měl. Záznamy aktivity a BGP vám říkají, co služba udělala s tunelem a relací, ne co přes ně poslala vaše aplikace. Sáhnout po protokolech tunelu kvůli ladění časového limitu aplikace je chyba kategorie a obvykle stojí jedno okno přerušení, než si toho někdo všimne. Nejprve zvolte otázku, pak tok, který na ni umí odpovědět.

Třetí podmínka: změna přes konzolu, nebo API možností tunelu

Pokud člověk dělá jednorázovou změnu, cesta přes konzolu je v pořádku: VPC console, Site-to-Site VPN connections, vyberte připojení, Actions, Modify VPN tunnel options, vyberte vnější IP, zapněte Tunnel activity log, vyberte skupinu a výstupní formát, uložte uvnitř okna. Pokud se VPN spravuje jako kód, stejné kliknutí je drift, který později srovnáte.

Pro automatizaci má část možností tunelu týkající se protokolu aktivity pevný tvar: LogOptions obsahuje CloudWatchLogOptions s LogEnabled, LogGroupArn a LogOutputFormat. Tento blok je fragment, ne požadavek; modify-vpn-tunnel-options stále potřebuje ID připojení a vnější IP tunelu a zbývající nastavení tunelu musí zachovat ten, kdo vlastní šablonu. Protokolování BGP používá vlastní klíče BgpLogEnabled, BgpLogGroupArn a BgpLogOutputFormat ve stejné struktuře. Přečtěte změnu zpět pomocí describe-vpn-connections, místo abyste věřili, že se volání použilo.

Co vám záznamy mohou a nemohou říct

Když je první tunel hotový a zamýšlená cesta je dostupná, zopakujte stejnou řízenou sekvenci pro druhý tunel, pokud potřebujete i jeho protokoly. Jeden tunel po druhém je celý smysl.

Záznamy přicházejí v tocích identifikovaných připojením a vnější adresou tunelu, takže korelujte s touto identitou, místo abyste čekali, že se historie objeví zpětně. Nic před změnou neexistuje a žádné čekání mezeru nevyplní. Pokud potřebujete základní linii, zaznamenejte aktuální stav tunelu a směrovací tabulku před změnou, aby bylo s čím srovnávat.

Udržujte skupinu protokolů, její uchovávání, její oprávnění k doručování a blok možností tunelu ve stejném inventáři jako samotnou VPN, protože jde o jednu konfiguraci rozprostřenou na čtyři místa. Postup AWS pro povolení protokolů dokumentuje pracovní postup pro každý tunel a jeho varování před přerušením a stojí za to si ho přečíst před změnou, ne po ní. Pak ověřte v pořadí: tunel se vrátil, záznamy se objevují v očekávaném toku a záznamy odpovídají na otázku, kvůli které jste otevřeli tiket. Pokud třetí selže, problém byl ve volbě toku, ne v protokolování.