In AWS VPN-PSK rotearje: hokker tunnel falt, en wannear

De tunnel falt op it stuit dat de beide einen it net iens binne oer de foarôf dielde kaai, en hy bliuwt del oant beide kanten de nije wearde drage. Dat part is ferwachte: AWS behannelet de feroaring as in ûnderbrekking fan de keazen tunnel, en de peer sil IKE net ôfmeitsje wylst de kaaien ferskille. Wat minsken ferrast, is de twadde helte. De oare tunnel nimt it ferkear net út himsels oer, útsein as jo kontrolearre hawwe dat er it drage kin. Rotearje yn dizze folchoarder en de ûnderbrekking bliuwt binnen ien tunnel.

Wat der eins bart as de kaai feroaret

ModifyVpnTunnelOptions skriuwt de opsjes fan ien tunnel oer, identifisearre troch syn eksterne IP-adres. De tunnel wurdt delhelle en op 'e nij boud, dus IKE en IPsec ûnderhannelje fanôf it begjin mei de nije kaai. AWS stelt dat de ûnderbrekking ferskate minuten duorje kin, wat lang genôch is foar in routingprotokol om it op te merken. De oare tunnel yn deselde ferbining wurdt net troch de oprop rekke.

Der is in twadde effekt dy't it witten wurdich is foardat jo wat stjoere. De wizigingsbewurking nimt de folsleine set tunnelopsjes, dus in fjild dat jo weilitte wurdt weromskreaun mei syn standertwearde. As jo de libbensdoer fan faze 1 of faze 2, of de ynstellingen foar it opspoaren fan deade peer, ôfstimd hawwe, jou dan de aktuele wearden troch yn deselde oanfraach of plan om se dêrnei werom te setten.

Lês earst de aktuele wearden en feroarje dan ien fjild. Dy folchoarder is de hiele dissipline fan dizze taak.

Keppelje de AWS-tunnel earst oan de goede peer

De konsole labelt tunnels op folchoarder, en jo apparaat brûkt dat label net. Identifisearje de tunnel oan syn eksterne IP-adres en keppelje him oan 'e peer-seksje op 'e klantpoarte. Tunnel 1 yn in lokale konfiguraasje is gjin bewiis dat jo de tunnel bewurkje dy't AWS tunnel 1 neamt.

Begjin by de ferbining sels, dy't beide tunnels en de kaai listet dy't elk op dit stuit hat:

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

De kaai dy't weromkomt is dejinge dy't no brûkt wurdt. Fergelykje dy mei de peer-konfiguraasje foardat jo wat feroarje, want in ôfwiking dy't al bestiet ferklearret in tunnel dy't nea stabyl wie.

Lit earst de oare tunnel it ferkear drage

Twa tunnels yn ien ferbining bewiist net dat jo apparaat beide konfigurearre hat, dat beide de prefiksen oankundigje dy't jo nedich hawwe, of dat ferkear tusken har beweecht. Kontrolearje de ûnderhanneling fan 'e alternative tunnel, syn rûtes en in echte applikaasjestream yn beide rjochtingen. Mei BGP is in libbene neistlizzing nuttich bewiis, mar net itselde as it befêstigjen fan 'e prefiksen. Mei statyske routing befêstigje jo hoe't de poarte it paad kiest en wat dy docht as it foarkarspaad ferdwynt.

As it alternatyf de wurklêst net drage kin, plan dan de ûnderbrekking of reparearje de alternative tunnel foardat jo de kaai oanreitsje. In statuslampke op in konsolside is gjin ûnthjit fan ûnûnderbrutsen tsjinst.

Rotearje ien tunnel en ferifiearje dan mei echt ferkear

Mei it alternative paad bewiisd is de folchoarder koart. Skriuw it tunneladres, syn peer en de net-geheime ynstellingen op, en hâld in behearpaad nei de poarte dat net ôfhinget fan 'e tunnel dy't jo op it punt steane te brekken.

1. Wurkje de klantpoarte-peer by foar it keazen eksterne adres, of tariede de feroaring sadat dy sekonden nei de API-oprop yngiet.
2. Stjoer de wizigingsopop mei de nije kaai plus de aktuele libbensdoeren en DPD-wearden.
3. Wachtje oant IKE en IPsec weromkomme en befêstigje dan de rûtes en de fereaske prefiksen.
4. Stjoer in represintative applikaasjestream troch dy tunnel en sjoch nei beide rjochtingen.

De tunnel is ûnbrûkber wylst de einen it net iens binne en wylst AWS de wiziging tapast, dus de peer-bywurking moat daliks folgje en net nei de middei. Pas as de feroare tunnel echt ferkear draacht, moatte jo de proseduere op 'e oare werhelje.

Stop as weromkringing of routing nei de earste tunnel noch ûnwis is. Twa healwurkjende tunnels binne slimmer as ien dêr't jo fan witte dat er wurket.

As weromkringing fêstrint, lês dan de IKE-kant

In tunnel dy't del bliuwt neidat beide einen de nije kaai hawwe, is meastentiids in beliedsôfwiking dy't de rotaasje bleatlein hat en net makke hat. De foarstellen, de identiteit dy't de peer stjoert en de ferkearsselektearren moatte allegear oerienkomme mei de AWS-kant, en in wearde dy't in fêstige tunnel oerlibbe hat, kin by in nije ûnderhanneling dochs noch wegere wurde. Lês de ûnderhannelingsstatus en it berjocht dêroan foardat jo de kaai in twadde kear feroarje.

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

As de feroaring weromdraaid wurde moat, set dan de âlde kaai net werom allinnich om't er earder wurke. Behannelje in kompromittearre kaai as kompromittearre en reparearje ynstee de ûnderhanneling. Einigje mei beide tunnels ferifiearre en it geheimenynventaris bywurke, sadat elke peer fêstleit hokker wearde er hat, en hâld de AWS-dokumintaasje oer tunnelopsjes njonken it runbook.