Ротирање на 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.

Поврзани статии