Rotace PSK u AWS VPN: který tunel spadne a kdy
Změna jednoho předem sdíleného klíče tunelu AWS VPN shodí tento tunel, dokud se obě strany neshodnou. Nejprve prokažte alternativní cestu, poté rotujte tunely jeden po druhém.
Tunel spadne v okamžiku, kdy se oba konce neshodnou na předem sdíleném klíči, a zůstane dole, dokud obě strany neponesou novou hodnotu. Tato část je očekávaná: AWS považuje změnu za přerušení vybraného tunelu a protějšek nedokončí IKE, dokud se klíče liší. Co lidi překvapí, je druhá polovina. Druhý tunel sám od sebe provoz nepřevezme, pokud jste neověřili, že ho unese. Rotujte v tomto pořadí a výpadek zůstane uvnitř jednoho tunelu.
Co se vlastně stane, když se klíč změní
ModifyVpnTunnelOptions přepisuje možnosti jednoho tunelu, určeného jeho vnější IP adresou. Tunel se strhne a znovu postaví, takže IKE a IPsec vyjednávají od nuly s novým klíčem. AWS uvádí, že přerušení může trvat několik minut, což je dost dlouho na to, aby si toho všiml směrovací protokol. Druhý tunel ve stejném připojení se voláním nemění.
Před odesláním čehokoli je dobré znát druhý efekt. Operace změny bere celou sadu možností tunelu, takže pole, které vynecháte, se zapíše zpět se svou výchozí hodnotou. Pokud jste ladili životnosti fáze 1 nebo fáze 2 nebo nastavení detekce mrtvého protějšku, předejte aktuální hodnoty ve stejném požadavku, nebo je plánujte poté obnovit.
Nejprve si přečtěte aktuální hodnoty, poté změňte jedno pole. Tato posloupnost je celá disciplína tohoto úkolu.
Nejprve přiřaďte tunel AWS ke správnému protějšku
Konzole označuje tunely podle pořadí a vaše zařízení tento štítek nepoužívá. Určete tunel podle jeho vnější IP adresy a přiřaďte ho ke sekci protějšku na zákaznické bráně. Tunel 1 v místní konfiguraci není důkaz, že upravujete tunel, který AWS nazývá tunel 1.
Začněte samotným připojením, které vypisuje oba tunely a klíč, který každý z nich právě drží:
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"Vrácený klíč je ten, který se právě používá. Porovnejte ho s konfigurací protějšku, než cokoli změníte, protože neshoda, která už existuje, vysvětluje tunel, který nikdy nebyl stabilní.
Nejprve nechte provoz nést druhý tunel
Dva tunely v jednom připojení nedokazují, že vaše zařízení má nakonfigurované oba, že oba inzerují prefixy, které potřebujete, ani že mezi nimi proudí provoz. Ověřte vyjednávání alternativního tunelu, jeho trasy a skutečný tok aplikace v obou směrech. U BGP je živé sousedství užitečný důkaz, ale není totéž jako potvrzení prefixů. U statického směrování potvrďte, jak brána volí cestu a co dělá, když preferovaná zmizí.
Pokud alternativa nemůže nést zátěž, naplánujte výpadek nebo alternativní tunel opravte, než se klíče dotknete. Stavová kontrolka na stránce konzole není slib nepřerušené služby.
Zrotujte jeden tunel a poté ověřte skutečným provozem
Když je alternativní cesta prokázaná, je posloupnost krátká. Zapište adresu tunelu, jeho protějšek a ne tajná nastavení a udržujte správcovskou cestu k bráně, která nezávisí na tunelu, který se chystáte přerušit.
- Aktualizujte protějšek zákaznické brány pro vybranou vnější adresu, nebo změnu připravte tak, aby se projevila několik sekund po volání API.
- Odešlete volání změny s novým klíčem plus aktuální životnosti a hodnoty DPD.
- Počkejte, až se IKE a IPsec vrátí, a poté potvrďte trasy a požadované prefixy.
- Prožeňte tímto tunelem reprezentativní tok aplikace a sledujte oba směry.
Tunel je nepoužitelný, dokud se strany neshodnou a dokud AWS změnu aplikuje, takže aktualizace protějšku musí následovat okamžitě, ne po obědě. Teprve když změněný tunel nese skutečný provoz, opakujte postup na druhém.
Zastavte se, pokud je obnova nebo směrování po prvním tunelu stále nejisté. Dva polofunkční tunely jsou horší než jeden, o kterém víte, že funguje.
Když se obnova zasekne, čtěte stranu IKE
Tunel, který zůstane dole poté, co obě strany drží nový klíč, je obvykle neshoda zásad, kterou rotace odhalila, nikoli vytvořila. Návrhy, identita, kterou protějšek posílá, a selektory provozu musí všechny odpovídat straně AWS a hodnota, která přežila zavedený tunel, může být při novém vyjednávání přesto odmítnuta. Přečtěte si stav vyjednávání a zprávu k němu připojenou, než klíč změníte podruhé.
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
--query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"Pokud je třeba změnu vrátit, neobnovujte starý klíč jen proto, že dřív fungoval. Považujte kompromitovaný klíč za kompromitovaný a raději opravte vyjednávání. Skončete s ověřenými oběma tunely a aktualizovaným inventářem tajemství, aby si každý protějšek zaznamenal, kterou hodnotu drží, a dokumentaci k možnostem tunelu AWS mějte u runbooku.