Een AWS VPN-PSK roteren: welke tunnel valt weg, en wanneer

De tunnel valt weg op het moment dat de twee uiteinden het oneens zijn over de vooraf gedeelde sleutel, en hij blijft neer tot beide kanten de nieuwe waarde dragen. Dat deel is te verwachten: AWS behandelt de wijziging als een onderbreking van de gekozen tunnel, en de peer zal IKE niet afronden zolang de sleutels verschillen. Wat mensen verrast, is de tweede helft. De andere tunnel neemt het verkeer niet vanzelf over, tenzij u hebt gecontroleerd dat hij het kan dragen. Roteer in deze volgorde en de onderbreking blijft binnen één tunnel.

Wat er werkelijk gebeurt wanneer de sleutel verandert

ModifyVpnTunnelOptions herschrijft de opties voor één tunnel, geïdentificeerd door het externe IP-adres. De tunnel wordt afgebroken en opnieuw opgebouwd, dus IKE en IPsec onderhandelen vanaf nul met de nieuwe sleutel. AWS stelt dat de onderbreking enkele minuten kan duren, wat lang genoeg is voor een routingprotocol om het op te merken. De andere tunnel in dezelfde verbinding wordt niet door de aanroep geraakt.

Er is een tweede effect dat u moet kennen voordat u iets verstuurt. De wijzigingsbewerking neemt de volledige set tunnelopties, dus een veld dat u weglaat wordt teruggeschreven met zijn standaardwaarde. Als u de levensduur van fase 1 of fase 2 hebt afgestemd, of de instellingen voor het opsporen van een dode peer, geef dan de huidige waarden mee in hetzelfde verzoek of plan om ze daarna te herstellen.

Lees eerst de huidige waarden en wijzig dan één veld. Die volgorde is de hele discipline van deze taak.

Koppel de AWS-tunnel eerst aan de juiste peer

De console labelt tunnels op volgorde, en uw apparaat gebruikt dat label niet. Identificeer de tunnel aan zijn externe IP-adres en koppel hem aan het peer-gedeelte op de klantgateway. Tunnel 1 in een lokale configuratie is geen bewijs dat u de tunnel bewerkt die AWS tunnel 1 noemt.

Begin bij de verbinding zelf, die beide tunnels en de sleutel die elk nu heeft, opsomt:

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

De sleutel die terugkomt, is degene die nu in gebruik is. Vergelijk hem met de peer-configuratie voordat u iets wijzigt, want een verschil dat al bestaat verklaart een tunnel die nooit stabiel was.

Laat eerst de andere tunnel het verkeer dragen

Twee tunnels in één verbinding bewijzen niet dat uw apparaat beide heeft geconfigureerd, dat beide de prefixen aankondigen die u nodig hebt, of dat verkeer tussen hen beweegt. Controleer de onderhandeling van de alternatieve tunnel, de routes en een echte applicatiestroom in beide richtingen. Met BGP is een levende adjacency nuttig bewijs, maar niet hetzelfde als het bevestigen van de prefixen. Met statische routing bevestigt u hoe de gateway het pad kiest en wat hij doet wanneer het voorkeurspad verdwijnt.

Als het alternatief de werklast niet kan dragen, plan dan de onderbreking of herstel de alternatieve tunnel voordat u de sleutel aanraakt. Een statuslampje op een consolepagina is geen belofte van ononderbroken dienst.

Roteer één tunnel en verifieer daarna met echt verkeer

Als het alternatieve pad bewezen is, is de volgorde kort. Noteer het tunneladres, de peer en de niet-geheime instellingen, en houd een beheerpad naar de gateway dat niet afhangt van de tunnel die u op het punt staat te breken.

1. Werk de peer van de klantgateway bij voor het gekozen externe adres, of bereid de wijziging voor zodat die seconden na de API-aanroep ingaat.
2. Stuur de wijzigingsaanroep met de nieuwe sleutel plus de huidige levensduren en DPD-waarden.
3. Wacht tot IKE en IPsec terugkomen en bevestig dan de routes en de vereiste prefixen.
4. Stuur een representatieve applicatiestroom door die tunnel en kijk naar beide richtingen.

De tunnel is onbruikbaar zolang de uiteinden het oneens zijn en zolang AWS de wijziging toepast, dus de peer-update moet onmiddellijk volgen en niet na de lunch. Alleen wanneer de gewijzigde tunnel echt verkeer draagt, moet u de procedure op de andere herhalen.

Stop als herstel of routing na de eerste tunnel nog onzeker is. Twee half werkende tunnels zijn slechter dan één waarvan u weet dat hij werkt.

Als het herstel vastloopt, lees dan de IKE-kant

Een tunnel die neer blijft nadat beide uiteinden de nieuwe sleutel hebben, is meestal een beleidsverschil dat de rotatie heeft blootgelegd en niet heeft veroorzaakt. De voorstellen, de identiteit die de peer stuurt en de verkeersselectoren moeten allemaal overeenkomen met de AWS-kant, en een waarde die een gevestigde tunnel overleefde kan tijdens een nieuwe onderhandeling alsnog worden geweigerd. Lees de onderhandelingsstatus en het bijgevoegde bericht voordat u de sleutel een tweede keer wijzigt.

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

Als de wijziging moet worden teruggedraaid, herstel dan niet de oude sleutel alleen omdat die eerder werkte. Behandel een gecompromitteerde sleutel als gecompromitteerd en repareer in plaats daarvan de onderhandeling. Sluit af met beide tunnels geverifieerd en de geheimeninventaris bijgewerkt, zodat elke peer vastlegt welke waarde hij heeft, en houd de AWS-documentatie over tunnelopties naast de runbook.