Rotere ein AWS VPN-PSK: kva tunnel som fell, og når

Tunnelen fell i det augneblunken dei to endane er usamde om den førehandsdelte nøkkelen, og han blir nede til begge sider ber den nye verdien. Den delen er venta: AWS handsamar endringa som eit avbrot av den valde tunnelen, og peer-en vil ikkje fullføre IKE så lenge nøklane er ulike. Det som overraskar folk, er den andre halvdelen. Den andre tunnelen tek ikkje over trafikken av seg sjølv med mindre du har kontrollert at han kan bere han. Roter i denne rekkjefølgja, og avbrotet held seg inne i éin tunnel.

Kva som faktisk skjer når nøkkelen blir endra

ModifyVpnTunnelOptions skriv om alternativa for éin tunnel, identifisert ved den eksterne IP-adressa hans. Tunnelen blir riven ned og bygd opp att, så IKE og IPsec forhandlar frå botnen av med den nye nøkkelen. AWS opplyser at avbrotet kan vare i fleire minutt, noko som er lenge nok til at ein rutingsprotokoll legg merke til det. Den andre tunnelen i same tilkoplinga blir ikkje råka av kallet.

Det er ein andre effekt som er verd å kjenne før du sender noko. Endringsoperasjonen tek heile settet med tunnelalternativ, så eit felt du utelèt blir skrive tilbake med standardverdien sin. Viss du har justert levetidene for fase 1 eller fase 2, eller innstillingane for registrering av død peer, må du sende dei gjeldande verdiane i same førespurnad eller planleggje å gjenopprette dei etterpå.

Les dei gjeldande verdiane først, og endre deretter eitt felt. Den rekkjefølgja er heile disiplinen i denne oppgåva.

Match AWS-tunnelen med rett peer først

Konsollen merkar tunnelar etter rekkjefølgje, og eininga di brukar ikkje den merkinga. Identifiser tunnelen ved den eksterne IP-adressa hans og match han med peer-avsnittet på kundegatewayen. Tunnel 1 i ein lokal konfigurasjon er ikkje prov på at du redigerer tunnelen AWS kallar tunnel 1.

Start med sjølve tilkoplinga, som listar begge tunnelane og nøkkelen kvar av dei har akkurat no:

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

Nøkkelen som kjem tilbake, er den som blir brukt akkurat no. Samanlikn han med peer-konfigurasjonen før du endrar noko, fordi eit avvik som alt finst forklarar ein tunnel som aldri var stabil.

La den andre tunnelen bere trafikken først

To tunnelar i éi tilkopling provar ikkje at eininga di har konfigurert begge, at begge annonserer prefiksa du treng, eller at trafikk flyttar seg mellom dei. Kontroller forhandlinga til den alternative tunnelen, rutene hans og ein reell applikasjonsstraum i begge retningar. Med BGP er eit levande naboskap eit nyttig prov, men ikkje det same som å stadfeste prefiksa. Med statisk ruting stadfestar du korleis gatewayen vel vegen og kva han gjer når den føretrekte forsvinn.

Viss alternativet ikkje kan bere arbeidslasta, planlegg avbrotet eller reparer den alternative tunnelen før du rører nøkkelen. Eit statuslys på ei konsollside er ikkje eit løfte om uavbroten teneste.

Roter éin tunnel, og verifiser deretter med reell trafikk

Når den alternative vegen er provd, er rekkjefølgja kort. Noter tunneladressa, peer-en og dei ikkje-hemmelege innstillingane, og hald ein administrasjonsveg til gatewayen som ikkje er avhengig av tunnelen du er i ferd med å bryte.

1. Oppdater kundegatewayens peer for den valde eksterne adressa, eller førebu endringa slik at ho trer i kraft sekund etter API-kallet.
2. Send endringskallet med den nye nøkkelen pluss gjeldande levetider og DPD-verdiar.
3. Vent på at IKE og IPsec kjem tilbake, og stadfest deretter rutene og dei påkravde prefiksa.
4. Send ein representativ applikasjonsstraum gjennom den tunnelen og følg med på begge retningar.

Tunnelen er ubrukeleg medan endane er usamde og medan AWS brukar endringa, så peer-oppdateringa må følgje med ein gong og ikkje etter lunsj. Berre når den endra tunnelen ber reell trafikk, bør du gjenta prosedyren på den andre.

Stopp viss gjenoppretting eller ruting framleis er usikker etter den første tunnelen. To halvt fungerande tunnelar er verre enn éin du veit fungerer.

Når gjenopprettinga stoppar opp, les IKE-sida

Ein tunnel som blir nede etter at begge endar har den nye nøkkelen, er vanlegvis eit policyavvik som rotasjonen avdekte snarare enn skapte. Framlegga, identiteten peer-en sender og trafikkveljarane må alle stemme med AWS-sida, og ein verdi som overlevde ein etablert tunnel kan framleis bli avvist under ei ny forhandling. Les forhandlingsstatusen og meldinga som er knytt til han, før du endrar nøkkelen ein gong til.

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

Viss endringa må rullast tilbake, må du ikkje gjenopprette den gamle nøkkelen berre fordi han virka før. Handsame ein kompromittert nøkkel som kompromittert, og reparer forhandlinga i staden. Avslutt med begge tunnelane verifiserte og hemmelegheitsinventaret oppdatert slik at kvar peer registrerer kva verdi han har, og hald AWS-dokumentasjonen om tunnelalternativ ved sida av runbooken.