Rotere en AWS VPN-PSK: hvilken tunnel faller, og når

Tunnelen faller i det øyeblikket de to endene er uenige om den forhåndsdelte nøkkelen, og den blir nede til begge sider bærer den nye verdien. Den delen er forventet: AWS behandler endringen som en avbrytelse av den valgte tunnelen, og peer-en vil ikke fullføre IKE så lenge nøklene er forskjellige. Det som overrasker folk, er den andre halvdelen. Den andre tunnelen overtar ikke trafikken av seg selv med mindre du har kontrollert at den kan bære den. Roter i denne rekkefølgen, og avbruddet holder seg inne i én tunnel.

Hva som faktisk skjer når nøkkelen endres

ModifyVpnTunnelOptions skriver om alternativene for én tunnel, identifisert ved dens eksterne IP-adresse. Tunnelen rives ned og bygges på nytt, så IKE og IPsec forhandler fra bunnen av med den nye nøkkelen. AWS oppgir at avbruddet kan vare i flere minutter, noe som er lenge nok til at en rutingsprotokoll merker det. Den andre tunnelen i samme tilkobling berøres ikke av kallet.

Det er en andre effekt som er verdt å kjenne før du sender noe. Endringsoperasjonen tar hele settet med tunnelalternativer, så et felt du utelater skrives tilbake med standardverdien sin. Hvis du har justert levetidene for fase 1 eller fase 2, eller innstillingene for registrering av død peer, må du sende de gjeldende verdiene i samme forespørsel eller planlegge å gjenopprette dem etterpå.

Les de gjeldende verdiene først, og endre deretter ett felt. Den rekkefølgen er hele disiplinen i denne oppgaven.

Match AWS-tunnelen med riktig peer først

Konsollen merker tunneler etter rekkefølge, og enheten din bruker ikke den merkingen. Identifiser tunnelen ved dens eksterne IP-adresse og match den med peer-avsnittet på kundegatewayen. Tunnel 1 i en lokal konfigurasjon er ikke bevis for at du redigerer tunnelen AWS kaller tunnel 1.

Start med selve tilkoblingen, som lister begge tunnelene og nøkkelen hver av dem har akkurat nå:

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

Nøkkelen som kommer tilbake, er den som brukes akkurat nå. Sammenlign den med peer-konfigurasjonen før du endrer noe, fordi et avvik som allerede finnes forklarer en tunnel som aldri var stabil.

La den andre tunnelen bære trafikken først

To tunneler i én tilkobling beviser ikke at enheten din har konfigurert begge, at begge annonserer prefiksene du trenger, eller at trafikk beveger seg mellom dem. Kontroller forhandlingen til den alternative tunnelen, rutene dens og en reell applikasjonsstrøm i begge retninger. Med BGP er et levende naboforhold et nyttig bevis, men ikke det samme som å bekrefte prefiksene. Med statisk ruting bekrefter du hvordan gatewayen velger veien og hva den gjør når den foretrukne forsvinner.

Hvis alternativet ikke kan bære arbeidsbelastningen, planlegg avbruddet eller reparer den alternative tunnelen før du rører nøkkelen. Et statuslys på en konsollside er ikke et løfte om uavbrutt tjeneste.

Roter én tunnel, og verifiser deretter med reell trafikk

Når den alternative veien er bevist, er rekkefølgen kort. Noter tunneladressen, peer-en og de ikke-hemmelige innstillingene, og hold en administrasjonsvei til gatewayen som ikke avhenger av tunnelen du er i ferd med å bryte.

1. Oppdater kundegatewayens peer for den valgte eksterne adressen, eller forbered endringen slik at den trer i kraft sekunder etter API-kallet.
2. Send endringskallet med den nye nøkkelen pluss gjeldende levetider og DPD-verdier.
3. Vent på at IKE og IPsec kommer tilbake, og bekreft deretter rutene og de påkrevde prefiksene.
4. Send en representativ applikasjonsstrøm gjennom den tunnelen og følg med på begge retninger.

Tunnelen er ubrukelig mens endene er uenige og mens AWS anvender endringen, så peer-oppdateringen må følge umiddelbart og ikke etter lunsj. Bare når den endrede tunnelen bærer reell trafikk, bør du gjenta prosedyren på den andre.

Stopp hvis gjenoppretting eller ruting fortsatt er usikker etter den første tunnelen. To halvt fungerende tunneler er verre enn én du vet fungerer.

Når gjenopprettingen stopper opp, les IKE-siden

En tunnel som blir nede etter at begge ender har den nye nøkkelen, er vanligvis et policyavvik som rotasjonen avdekket snarere enn skapte. Forslagene, identiteten peer-en sender og trafikkvelgerne må alle stemme med AWS-siden, og en verdi som overlevde en etablert tunnel kan fortsatt avvises under en ny forhandling. Les forhandlingsstatusen og meldingen som er knyttet til den, før du endrer nøkkelen en gang til.

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

Hvis endringen må rulles tilbake, må du ikke gjenopprette den gamle nøkkelen bare fordi den virket før. Behandle en kompromittert nøkkel som kompromittert, og reparer forhandlingen i stedet. Avslutt med begge tunnelene verifisert og hemmelighetsinventaret oppdatert slik at hver peer registrerer hvilken verdi den har, og hold AWS-dokumentasjonen om tunnelalternativer ved siden av runbooken.