Rotation af en AWS VPN-PSK: hvilken tunnel falder, og hvornår

Tunnelen falder i det øjeblik, de to ender er uenige om den forudelte nøgle, og den bliver nede, indtil begge sider bærer den nye værdi. Den del er forventet: AWS behandler ændringen som en afbrydelse af den valgte tunnel, og peer'en afslutter ikke IKE, mens nøglerne er forskellige. Det, der overrasker folk, er den anden halvdel. Den anden tunnel overtager ikke trafikken af sig selv, medmindre du har kontrolleret, at den kan bære den. Rotér i denne rækkefølge, og afbrydelsen bliver inde i én tunnel.

Hvad der faktisk sker, når nøglen ændres

ModifyVpnTunnelOptions omskriver indstillingerne for én tunnel, identificeret ved dens eksterne IP-adresse. Tunnelen rives ned og genopbygges, så IKE og IPsec forhandler fra bunden med den nye nøgle. AWS angiver, at afbrydelsen kan vare flere minutter, hvilket er længe nok til, at en routingprotokol bemærker det. Den anden tunnel i samme forbindelse berøres ikke af kaldet.

Der er en anden effekt, som er værd at kende, før du sender noget. Ændringsoperationen tager hele sættet af tunnelindstillinger, så et felt, du udelader, skrives tilbage med sin standardværdi. Hvis du har justeret levetiderne for fase 1 eller fase 2 eller indstillingerne for registrering af død peer, skal du sende de aktuelle værdier i samme anmodning eller planlægge at gendanne dem bagefter.

Læs de aktuelle værdier først, og ændr derefter ét felt. Den rækkefølge er hele disciplinen i denne opgave.

Match AWS-tunnelen med den rigtige peer først

Konsollen mærker tunneler efter rækkefølge, og din enhed bruger ikke den mærkning. Identificer tunnelen ved dens eksterne IP-adresse, og match den med peer-afsnittet på kundegatewayen. Tunnel 1 i en lokal konfiguration er ikke bevis for, at du redigerer den tunnel, AWS kalder tunnel 1.

Start med selve forbindelsen, som viser begge tunneler og den nøgle, hver af dem aktuelt har:

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

Den nøgle, der kommer tilbage, er den, der bruges lige nu. Sammenlign den med peer-konfigurationen, før du ændrer noget, fordi en uoverensstemmelse, der allerede findes, forklarer en tunnel, der aldrig var stabil.

Lad den anden tunnel bære trafikken først

To tunneler i én forbindelse beviser ikke, at din enhed har begge konfigureret, at begge annoncerer de præfikser, du har brug for, eller at trafik bevæger sig mellem dem. Kontroller den alternative tunnels forhandling, dens ruter og en reel applikationsstrøm i begge retninger. Med BGP er et levende naboskab nyttigt bevis, men ikke det samme som at bekræfte præfikserne. Med statisk routing skal du bekræfte, hvordan gatewayen vælger vejen, og hvad den gør, når den foretrukne forsvinder.

Hvis alternativet ikke kan bære arbejdsbyrden, planlæg afbrydelsen, eller reparer den alternative tunnel, før du rører nøglen. Et statuslys på en konsolside er ikke et løfte om uafbrudt service.

Rotér én tunnel, og verificer derefter med reel trafik

Når den alternative vej er bevist, er rækkefølgen kort. Notér tunneladressen, dens peer og de ikke-hemmelige indstillinger, og hold en administrationsvej til gatewayen, der ikke afhænger af den tunnel, du er ved at bryde.

1. Opdater kundegatewayens peer for den valgte eksterne adresse, eller forbered ændringen, så den træder i kraft sekunder efter API-kaldet.
2. Send ændringskaldet med den nye nøgle plus de aktuelle levetider og DPD-værdier.
3. Vent på, at IKE og IPsec kommer tilbage, og bekræft derefter ruterne og de krævede præfikser.
4. Send en repræsentativ applikationsstrøm gennem den tunnel, og hold øje med begge retninger.

Tunnelen er ubrugelig, mens enderne er uenige, og mens AWS anvender ændringen, så peer-opdateringen skal følge med det samme i stedet for efter frokost. Kun når den ændrede tunnel bærer reel trafik, bør du gentage proceduren på den anden.

Stop, hvis genopretning eller routing stadig er usikker efter den første tunnel. To halvt fungerende tunneler er værre end én, du ved virker.

Når genopretningen går i stå, læs IKE-siden

En tunnel, der forbliver nede, efter at begge ender har den nye nøgle, er normalt en policy-uoverensstemmelse, som rotationen afslørede snarere end skabte. Forslagene, den identitet peer'en sender, og trafikvælgerne skal alle stemme overens med AWS-siden, og en værdi, der overlevede en etableret tunnel, kan stadig afvises under en ny forhandling. Læs forhandlingsstatus og den vedhæftede meddelelse, før du ændrer nøglen en anden gang.

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

Hvis ændringen skal rulles tilbage, må du ikke gendanne den gamle nøgle, blot fordi den virkede før. Behandl en kompromitteret nøgle som kompromitteret, og reparer i stedet forhandlingen. Afslut med begge tunneler verificeret og hemmelighedsinventaret opdateret, så hver peer registrerer, hvilken værdi den har, og hold AWS-dokumentationen om tunnelindstillinger ved siden af runbooken.