Ротация на PSK за AWS VPN: кой тунел пада и кога

Промяната на един предварително споделен ключ на тунел в AWS VPN сваля този тунел, докато двете страни не се съгласят. Първо докажете алтернативния път, после ротирайте тунелите един по един.

Тунелът пада в момента, в който двете страни не са съгласни за предварително споделения ключ, и остава свален, докато и двете страни не носят новата стойност. Тази част е очаквана: AWS третира промяната като прекъсване на избрания тунел и партньорът няма да завърши IKE, докато ключовете се различават. Това, което изненадва хората, е втората половина. Другият тунел не поема трафика сам, освен ако не сте проверили, че може да го носи. Ротирайте в този ред и прекъсването остава в един тунел.

Какво всъщност се случва, когато ключът се промени

ModifyVpnTunnelOptions пренаписва опциите на един тунел, идентифициран по външния му IP адрес. Тунелът се разваля и изгражда наново, така че IKE и IPsec договарят от нулата с новия ключ. AWS посочва, че прекъсването може да продължи няколко минути, което е достатъчно дълго, за да го забележи протокол за маршрутизация. Другият тунел в същото свързване не се засяга от извикването.

Има втори ефект, който си струва да знаете, преди да изпратите каквото и да е. Операцията за промяна приема пълния набор опции на тунела, така че поле, което пропуснете, се записва обратно със стойността си по подразбиране. Ако сте настроили времената на живот на фаза 1 или фаза 2, или настройките за откриване на мъртъв партньор, подайте текущите стойности в същата заявка или планирайте да ги възстановите след това.

Първо прочетете текущите стойности, после променете едно поле. Тази последователност е цялата дисциплина на тази задача.

Първо съпоставете тунела на AWS с правилния партньор

Конзолата обозначава тунелите по ред, а вашето устройство не използва този етикет. Идентифицирайте тунела по външния му IP адрес и го съпоставете с партньорската секция на клиентския шлюз. Тунел 1 в локална конфигурация не е доказателство, че редактирате тунела, който AWS нарича тунел 1.

Започнете от самото свързване, което изброява двата тунела и ключа, който всеки от тях държи в момента:

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

Върнатият ключ е този, който се използва в момента. Сравнете го с партньорската конфигурация, преди да промените нещо, защото несъответствие, което вече съществува, обяснява тунел, който никога не е бил стабилен.

Първо накарайте другия тунел да носи трафика

Два тунела в едно свързване не доказват, че устройството ви е конфигурирало и двата, че и двата обявяват префиксите, от които се нуждаете, или че трафикът се движи между тях. Проверете договарянето на алтернативния тунел, маршрутите му и реален поток на приложение в двете посоки. С BGP живото съседство е полезно доказателство, но не е същото като потвърждаване на префиксите. При статично маршрутизиране потвърдете как шлюзът избира пътя и какво прави, когато предпочитаният изчезне.

Ако алтернативата не може да носи натоварването, планирайте прекъсването или поправете алтернативния тунел, преди да пипнете ключа. Светлинен индикатор на страница в конзолата не е обещание за непрекъсната услуга.

Ротирайте един тунел, после проверете с реален трафик

След като алтернативният път е доказан, последователността е кратка. Запишете адреса на тунела, неговия партньор и несекретните настройки и поддържайте път за управление към шлюза, който не зависи от тунела, който ще прекъснете.

  1. Обновете партньора на клиентския шлюз за избрания външен адрес или подгответе промяната така, че да влезе в сила секунди след извикването на API.
  2. Изпратете извикването за промяна с новия ключ плюс текущите времена на живот и стойности на DPD.
  3. Изчакайте IKE и IPsec да се върнат, после потвърдете маршрутите и необходимите префикси.
  4. Прекарайте представителен поток на приложение през този тунел и наблюдавайте двете посоки.

Тунелът е неизползваем, докато страните не се съгласят и докато AWS прилага промяната, така че обновяването на партньора трябва да последва веднага, а не след обяд. Само когато промененият тунел носи реален трафик, повторете процедурата на другия.

Спрете, ако възстановяването или маршрутизирането все още са несигурни след първия тунел. Два наполовина работещи тунела са по-лоши от един, за който знаете, че работи.

Когато възстановяването зацикли, четете страната на IKE

Тунел, който остава свален, след като двете страни държат новия ключ, обикновено е несъответствие в политиката, което ротацията е разкрила, а не създала. Предложенията, идентичността, която партньорът изпраща, и селекторите на трафик трябва да съвпадат със страната на AWS, а стойност, преживяла установен тунел, все още може да бъде отхвърлена при ново договаряне. Прочетете състоянието на договарянето и съобщението към него, преди да промените ключа втори път.

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

Ако промяната трябва да се отмени, не възстановявайте стария ключ само защото преди е работил. Третирайте компрометиран ключ като компрометиран и поправете договарянето вместо това. Завършете с проверени два тунела и обновен инвентар на тайните, така че всеки партньор да записва коя стойност държи, и дръжте документацията за опциите на тунела на AWS до runbook-а.

Подобни статии