Om 'n AWS VPN-PSK te roteer: watter tonnel val weg, en wanneer

Die tonnel val weg op die oomblik wanneer die twee kante oor die pre-shared sleutel verskil, en dit bly weg totdat beide kante die nuwe waarde dra. Dié deel is verwag: AWS beskou die verandering as 'n onderbreking van die gekose tonnel, en die eweknie sal nie IKE voltooi terwyl die sleutels verskil nie. Wat mense verras, is die tweede helfte. Die ander tonnel neem nie vanself die verkeer oor nie, tensy jy nagegaan het dat dit dit kan dra. Roteer in hierdie volgorde, dan bly die onderbreking binne een tonnel.

Wat werklik gebeur wanneer die sleutel verander

ModifyVpnTunnelOptions herskryf die opsies vir een tonnel, geïdentifiseer deur sy buite-IP-adres. Die tonnel word afgebreek en herbou, so IKE en IPsec onderhandel van nuuts af met die nuwe sleutel. AWS sê die onderbreking kan etlike minute duur, wat lank genoeg is vir 'n roeteringsprotokol om dit op te merk. Die ander tonnel in dieselfde verbinding word nie deur die oproep geraak nie.

Daar is 'n tweede effek wat jy moet weet voordat jy enigiets stuur. Die wysigingsbewerking neem die volle stel tonnelopsies, so 'n veld wat jy uitlaat, word met sy verstekwaarde teruggeskryf. As jy die leeftye van fase 1 of fase 2, of die instellings vir dooie eweknie-opsporing, aangepas het, gee die huidige waardes in dieselfde versoek deur of beplan om dit daarna te herstel.

Lees eers die huidige waardes en verander dan een veld. Dié volgorde is die hele dissipline van hierdie taak.

Pas die AWS-tonnel eers by die regte eweknie

Die konsole benoem tonnels volgens volgorde, en jou toestel gebruik nie daardie etiket nie. Identifiseer die tonnel aan sy buite-IP-adres en pas dit by die eweknie-blok op die kliëntpoort. Tonnel 1 in 'n plaaslike konfigurasie is nie bewys dat jy die tonnel wysig wat AWS tonnel 1 noem nie.

Begin by die verbinding self, wat albei tonnels en die sleutel wat elkeen tans hou, lys:

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

Die sleutel wat terugkom, is die een wat nou in gebruik is. Vergelyk dit met die eweknie-konfigurasie voordat jy iets verander, want 'n bestaande verskil verklaar 'n tonnel wat van die begin af nooit stabiel was nie.

Laat die ander tonnel eers die verkeer dra

Twee tonnels in een verbinding bewys nie dat jou toestel albei opgestel het nie, dat albei die voorvoegsels adverteer wat jy nodig het nie, of dat verkeer tussen hulle beweeg nie. Kontroleer die alternatiewe tonnel se onderhandeling, sy roetes en 'n werklike toepassingsvloei in albei rigtings. Met BGP is 'n lewende aangrensing nuttige bewyse, maar nie dieselfde as om die voorvoegsels te bevestig nie. Met statiese roetering bevestig jy hoe die poort die pad kies en wat dit doen wanneer die voorkeurpad verdwyn.

As die alternatief nie die werklas kan dra nie, skeduleer die onderbreking of herstel die alternatiewe tonnel voordat jy aan die sleutel raak. 'n Statuslig op 'n konsolbladsy is nie 'n belofte van ononderbroke diens nie.

Roteer een tonnel en verifieer dan met werklike verkeer

Met die alternatiewe pad bewys, is die volgorde kort. Teken die tonneladres, sy eweknie en die nie-geheime instellings aan, en hou 'n bestuurspad na die poort wat nie van die tonnel afhang wat jy op die punt staan om te breek nie.

1. Werk die kliëntpoort-eweknie by vir die gekose buite-adres, of berei die verandering voor sodat dit sekondes ná die API-oproep in werking tree.
2. Stuur die wysigingsoproep met die nuwe sleutel plus die huidige leeftye en DPD-waardes.
3. Wag tot IKE en IPsec terugkom en bevestig dan die roetes en die vereiste voorvoegsels.
4. Stuur 'n verteenwoordigende toepassingsvloei deur daardie tonnel en kyk na albei rigtings.

Die tonnel is onbruikbaar terwyl die kante verskil en terwyl AWS die wysiging toepas, so die eweknie-opdatering moet onmiddellik volg eerder as ná die middagete. Net wanneer die veranderde tonnel werklike verkeer dra, moet jy die prosedure op die ander een herhaal.

Stop as herstel of roetering ná die eerste tonnel nog onseker is. Twee halfwerkende tonnels is slegter as een waarvan jy weet dit werk.

Wanneer herstel vasval, lees die IKE-kant

'n Tonnel wat weggebly het nadat albei kante die nuwe sleutel het, is gewoonlik 'n beleidsverskil wat die rotasie blootgelê het eerder as geskep het. Die voorstelle, die identiteit wat die eweknie stuur en die verkeerskeuses moet almal met die AWS-kant ooreenstem, en 'n waarde wat 'n gevestigde tonnel oorleef het, kan steeds tydens 'n nuwe onderhandeling verwerp word. Lees die onderhandelingstatus en die boodskap daaraan voordat jy die sleutel 'n tweede keer verander.

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

As die verandering teruggedraai moet word, moet jy nie die ou sleutel herstel net omdat dit vroeër gewerk het nie. Beskou 'n gekompromitteerde sleutel as gekompromitteer en maak eerder die onderhandeling reg. Eindig met albei tonnels geverifieer en die geheime-inventaris bygewerk sodat elke eweknie aanteken watter waarde dit hou, en hou die AWS-tonnelopsies-dokumentasie langs die runbook.