Ротація 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.

Схожі статті