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