Ротация PSK в 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.