Rotacii PSK de AWS VPN: kiu tunelo falas, kaj kiam

La tunelo falas en la momento, kiam la du finoj malkonsentas pri la antaŭe kunhavata ŝlosilo, kaj ĝi restas malsupre ĝis ambaŭ flankoj portos la novan valoron. Tiu parto estas atendita: AWS traktas la ŝanĝon kiel interrompon de la elektita tunelo, kaj la partnero ne finos IKE dum la ŝlosiloj diferencas. Kio surprizas homojn, estas la dua duono. La alia tunelo ne transprenas la trafikon per si mem, krom se vi kontrolis, ke ĝi povas porti ĝin. Rotaciu laŭ ĉi tiu ordo kaj la interrompo restas ene de unu tunelo.

Kio fakte okazas, kiam la ŝlosilo ŝanĝiĝas

ModifyVpnTunnelOptions reskribas la opciojn por unu tunelo, identigita per ĝia ekstera IP-adreso. La tunelo estas malkonstruata kaj rekonstruata, do IKE kaj IPsec intertraktas de nulo kun la nova ŝlosilo. AWS deklaras, ke la interrompo povas daŭri plurajn minutojn, kio estas sufiĉe longa por ke enkursiga protokolo rimarku ĝin. La alia tunelo en la sama konekto ne estas tuŝata de la alvoko.

Ekzistas dua efiko inda scii antaŭ ol vi sendos ion ajn. La modifa operacio prenas la plenan aron da tunelaj opcioj, do kampo, kiun vi lasas ekstere, estas reskribata kun sia defaŭlta valoro. Se vi agordis la vivdaŭrojn de fazo 1 aŭ fazo 2, aŭ la agordojn por detekto de mortinta partnero, pasigu la nunajn valorojn en la sama peto aŭ planu restarigi ilin poste.

Unue legu la nunajn valorojn, poste ŝanĝu unu kampon. Tiu sinsekvo estas la tuta disciplino de ĉi tiu tasko.

Unue parigu la AWS-tunelon kun la ĝusta partnero

La konzolo etikedas tunelojn laŭ ordo, kaj via aparato ne uzas tiun etikedon. Identigu la tunelon per ĝia ekstera IP-adreso kaj parigu ĝin kun la partnera sekcio ĉe la klienta pordego. Tunelo 1 en loka agordo ne estas pruvo, ke vi redaktas la tunelon, kiun AWS nomas tunelo 1.

Komencu de la konekto mem, kiu listigas ambaŭ tunelojn kaj la ŝlosilon, kiun ĉiu nun tenas:

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

La ŝlosilo, kiu revenas, estas tiu uzata nun. Komparu ĝin kun la partnera agordo antaŭ ol ŝanĝi ion ajn, ĉar malkongruo, kiu jam ekzistas, klarigas tunelon, kiu neniam estis stabila.

Unue lasu la alian tunelon porti la trafikon

Du tuneloj en unu konekto ne pruvas, ke via aparato agordis ambaŭ, ke ambaŭ anoncas la prefiksojn, kiujn vi bezonas, aŭ ke trafiko moviĝas inter ili. Kontrolu la intertraktadon de la alternativa tunelo, ĝiajn itinerojn kaj realan aplikaĵofluon en ambaŭ direktoj. Kun BGP, viva apudeco estas utila pruvo sed ne la samo kiel konfirmi la prefiksojn. Kun statika enkursigo, konfirmu kiel la pordego elektas la vojon kaj kion ĝi faras, kiam la preferata malaperas.

Se la alternativo ne povas porti la laborŝarĝon, planu la interrompon aŭ riparu la alternativan tunelon antaŭ ol tuŝi la ŝlosilon. Statuslumo sur konzola paĝo ne estas promeso pri seninterrompa servo.

Rotaciu unu tunelon, poste kontrolu per reala trafiko

Kiam la alternativa vojo estas pruvita, la sinsekvo estas mallonga. Notu la tunelan adreson, ĝian partneron kaj la ne-sekretajn agordojn, kaj tenu administran vojon al la pordego, kiu ne dependas de la tunelo, kiun vi baldaŭ rompos.

1. Ĝisdatigu la partneron de la klienta pordego por la elektita ekstera adreso, aŭ preparu la ŝanĝon tiel, ke ĝi efikiĝu sekundojn post la API-alvoko.
2. Sendu la modifan alvokon kun la nova ŝlosilo plus la nunaj vivdaŭroj kaj DPD-valoroj.
3. Atendu, ke IKE kaj IPsec revenu, poste konfirmu la itinerojn kaj la postulatajn prefiksojn.
4. Puŝu reprezentan aplikaĵofluon tra tiu tunelo kaj observu ambaŭ direktojn.

La tunelo estas neuzebla dum la finoj malkonsentas kaj dum AWS aplikas la modifon, do la partnera ĝisdatigo devas sekvi tuj anstataŭ post la tagmanĝo. Nur kiam la ŝanĝita tunelo portas realan trafikon, vi ripetu la proceduron sur la alia.

Haltu, se reakiro aŭ enkursigo ankoraŭ estas necertaj post la unua tunelo. Du duone funkciantaj tuneloj estas pli malbonaj ol unu, pri kiu vi scias, ke ĝi funkcias.

Kiam reakiro stagnas, legu la IKE-flankon

Tunelo, kiu restas malsupre post kiam ambaŭ finoj tenas la novan ŝlosilon, estas kutime politika malkongruo, kiun la rotacio malkovris, ne kreis. La proponoj, la identeco, kiun la partnero sendas, kaj la trafik-selektiloj ĉiuj devas kongrui kun la AWS-flanko, kaj valoro, kiu postvivis establitan tunelon, ankoraŭ povas esti malakceptita dum nova intertraktado. Legu la intertraktadan statuson kaj la mesaĝon alkroĉitan al ĝi antaŭ ol ŝanĝi la ŝlosilon duan fojon.

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

Se la ŝanĝo devas esti malfarita, ne restarigu la malnovan ŝlosilon nur ĉar ĝi antaŭe funkciis. Traktu kompromititan ŝlosilon kiel kompromititan kaj riparu la intertraktadon anstataŭe. Finiĝu kun ambaŭ tuneloj kontrolitaj kaj la sekreta inventaro ĝisdatigita, por ke ĉiu partnero registru, kiun valoron ĝi tenas, kaj tenu la dokumentaron pri AWS-tunelaj opcioj apud la runbook.