Rotera en AWS VPN-PSK: vilken tunnel som faller, och när

Tunneln faller i samma ögonblick som de två ändarna är oense om den fördelade nyckeln, och den ligger nere tills båda sidorna bär det nya värdet. Den delen är väntad: AWS behandlar ändringen som ett avbrott i den valda tunneln, och peeren slutför inte IKE så länge nycklarna skiljer sig. Det som förvånar folk är den andra halvan. Den andra tunneln tar inte över trafiken av sig själv om du inte har kontrollerat att den kan bära den. Rotera i den här ordningen och avbrottet stannar inom en tunnel.

Vad som faktiskt händer när nyckeln ändras

ModifyVpnTunnelOptions skriver om alternativen för en tunnel, identifierad av dess externa IP-adress. Tunneln rivs och byggs upp igen, så IKE och IPsec förhandlar från början med den nya nyckeln. AWS anger att avbrottet kan pågå i flera minuter, vilket är tillräckligt länge för att ett routingprotokoll ska märka det. Den andra tunneln i samma anslutning påverkas inte av anropet.

Det finns en andra effekt som är värd att känna till innan du skickar något. Ändringsoperationen tar hela uppsättningen tunnelalternativ, så ett fält du utelämnar skrivs tillbaka med sitt standardvärde. Om du har justerat livslängderna för fas 1 eller fas 2, eller inställningarna för identifiering av död peer, skickar du de aktuella värdena i samma begäran eller planerar att återställa dem efteråt.

Läs de aktuella värdena först och ändra sedan ett fält. Den ordningen är hela disciplinen i den här uppgiften.

Matcha AWS-tunneln mot rätt peer först

Konsolen märker tunnlar i ordning, och din enhet använder inte den märkningen. Identifiera tunneln via dess externa IP-adress och matcha den mot peer-avsnittet på kundgatewayen. Tunnel 1 i en lokal konfiguration är inte bevis för att du redigerar den tunnel som AWS kallar tunnel 1.

Börja med själva anslutningen, som listar båda tunnlarna och den nyckel som var och en har just nu:

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,PreSharedKey]"

Nyckeln som returneras är den som används just nu. Jämför den med peer-konfigurationen innan du ändrar något, eftersom en avvikelse som redan finns förklarar en tunnel som aldrig var stabil.

Låt den andra tunneln bära trafiken först

Två tunnlar i en anslutning bevisar inte att din enhet har konfigurerat båda, att båda annonserar de prefix du behöver eller att trafik rör sig mellan dem. Kontrollera den alternativa tunneln förhandling, dess rutter och ett verkligt applikationsflöde i båda riktningarna. Med BGP är ett levande grannskap ett användbart bevis men inte samma sak som att bekräfta prefixen. Med statisk routing bekräftar du hur gatewayen väljer väg och vad den gör när den föredragna försvinner.

Om alternativet inte kan bära arbetsbelastningen, schemalägg avbrottet eller reparera den alternativa tunneln innan du rör nyckeln. En statuslampa på en konsolsida är inte ett löfte om oavbruten tjänst.

Rotera en tunnel och verifiera sedan med verklig trafik

När den alternativa vägen är bevisad är sekvensen kort. Anteckna tunnelns adress, dess peer och de inställningar som inte är hemliga, och håll en administrationsväg till gatewayen som inte beror på tunneln du är på väg att bryta.

1. Uppdatera kundgatewayens peer för den valda externa adressen, eller förbered ändringen så att den träder i kraft sekunder efter API-anropet.
2. Skicka ändringsanropet med den nya nyckeln plus aktuella livslängder och DPD-värden.
3. Vänta på att IKE och IPsec kommer tillbaka och bekräfta sedan rutterna och de nödvändiga prefixen.
4. Skicka ett representativt applikationsflöde genom den tunneln och följ båda riktningarna.

Tunneln är oanvändbar medan ändarna är oense och medan AWS tillämpar ändringen, så peer-uppdateringen måste följa omedelbart och inte efter lunchen. Först när den ändrade tunneln bär verklig trafik bör du upprepa proceduren på den andra.

Stoppa om återställning eller routing fortfarande är osäkert efter den första tunneln. Två halvfungerande tunnlar är värre än en som du vet fungerar.

När återställningen fastnar, läs IKE-sidan

En tunnel som ligger nere efter att båda ändarna har den nya nyckeln är vanligtvis en policyavvikelse som rotationen avslöjade snarare än skapade. Förslagen, identiteten peeren skickar och trafikväljarna måste alla stämma med AWS-sidan, och ett värde som överlevde en etablerad tunnel kan fortfarande avvisas under en ny förhandling. Läs förhandlingsstatusen och meddelandet som hör till den innan du ändrar nyckeln en gång till.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query "VpnConnections[0].VgwTelemetry[].[OutsideIpAddress,Status,StatusMessage]"

Om ändringen måste rullas tillbaka ska du inte återställa den gamla nyckeln bara för att den fungerade tidigare. Behandla en komprometterad nyckel som komprometterad och reparera förhandlingen i stället. Avsluta med båda tunnlarna verifierade och hemlighetsinventariet uppdaterat så att varje peer registrerar vilket värde den har, och håll AWS-dokumentationen om tunnelalternativ bredvid runbooken.