Pag-ikot ng PSK ng AWS VPN: aling tunnel ang bumabagsak, at kailan

Bumabagsak ang tunnel sa sandaling hindi magkasundo ang dalawang dulo tungkol sa paunang ibinahaging susi, at nananatili itong bumagsak hanggang sa dalhin ng dalawang panig ang bagong halaga. Inaasahan ang bahaging iyon: itinuturing ng AWS ang pagbabago bilang pagkaantala ng napiling tunnel, at hindi tatapusin ng kapares ang IKE habang magkaiba ang mga susi. Ang ikinagulat ng mga tao ay ang ikalawang kalahati. Hindi kusang kinukuha ng kabilang tunnel ang trapiko maliban kung nasuri mong kaya nitong dalhin ito. Iikot sa ganitong pagkakasunod-sunod at mananatili ang pagkaantala sa loob ng isang tunnel.

Ano ang talagang nangyayari kapag nagbago ang susi

Isinulat muli ng ModifyVpnTunnelOptions ang mga opsyon para sa isang tunnel, na kinikilala sa panlabas na IP address nito. Binabagsak at itinatayo muli ang tunnel, kaya nakikipagnegosyo ang IKE at IPsec mula sa simula gamit ang bagong susi. Sinasabi ng AWS na maaaring tumagal ng ilang minuto ang pagkaantala, na sapat ang haba para mapansin ito ng isang protocol ng ruta. Hindi naaapektuhan ng tawag ang kabilang tunnel sa parehong koneksyon.

May ikalawang epekto na dapat malaman bago magpadala ng kahit ano. Kinukuha ng operasyon ng pagbabago ang buong set ng mga opsyon ng tunnel, kaya ang field na iniwan mo ay isinusulat pabalik kasama ang default nitong halaga. Kung inayos mo ang tagal ng buhay ng yugto 1 o yugto 2, o ang mga setting ng pagtukoy ng patay na kapares, ipasa ang kasalukuyang halaga sa parehong kahilingan o planuhin ang pagbabalik nito pagkatapos.

Basahin muna ang kasalukuyang halaga, pagkatapos ay baguhin ang isang field. Ang pagkakasunod-sunod na iyon ang buong disiplina ng gawaing ito.

Itugma muna ang tunnel ng AWS sa tamang kapares

Nilalagyan ng label ng console ang mga tunnel ayon sa pagkakasunod-sunod, at hindi ginagamit ng device mo ang label na iyon. Kilalanin ang tunnel sa pamamagitan ng panlabas na IP address nito at itugma ito sa seksyon ng kapares sa gateway ng kostumer. Ang tunnel 1 sa lokal na configuration ay hindi patunay na ine-edit mo ang tunnel na tinatawag ng AWS na tunnel 1.

Magsimula sa mismong koneksyon, na naglilista ng dalawang tunnel at ang susi na hawak ng bawat isa ngayon:

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

Ang ibinalik na susi ang ginagamit ngayon. Ihambing ito sa configuration ng kapares bago magbago ng kahit ano, dahil ang pagkakaibang umiiral na ang nagpapaliwanag sa tunnel na hindi kailanman naging matatag.

Hayaang dalhin muna ng kabilang tunnel ang trapiko

Dalawang tunnel sa isang koneksyon ay hindi nagpapatunay na na-configure ng device mo ang dalawa, na parehong nag-aanunsyo ng mga prefix na kailangan mo, o na gumagalaw ang trapiko sa pagitan nila. Suriin ang negosasyon ng alternatibong tunnel, ang mga ruta nito at ang tunay na daloy ng aplikasyon sa dalawang direksyon. Sa BGP, ang buhay na pagkakapitbahay ay kapaki-pakinabang na ebidensya ngunit hindi katulad ng pagkumpirma sa mga prefix. Sa static na ruta, kumpirmahin kung paano pinipili ng gateway ang landas at ano ang ginagawa nito kapag nawala ang ginustong landas.

Kung hindi kayang dalhin ng alternatibo ang karga ng trabaho, iiskedyul ang pagkaantala o ayusin ang alternatibong tunnel bago hawakan ang susi. Ang ilaw ng estado sa pahina ng console ay hindi pangako ng walang-patid na serbisyo.

Iikot ang isang tunnel, pagkatapos ay i-verify gamit ang tunay na trapiko

Kapag napatunayan ang alternatibong landas, maikli ang pagkakasunod-sunod. Itala ang address ng tunnel, ang kapares nito at ang mga setting na hindi lihim, at panatilihin ang landas ng pamamahala patungo sa gateway na hindi umaasa sa tunnel na malapit mo nang sirain.

1. I-update ang kapares ng gateway ng kostumer para sa napiling panlabas na address, o ihanda ang pagbabago para magkabisa ilang segundo pagkatapos ng tawag sa API.
2. Ipadala ang tawag ng pagbabago kasama ang bagong susi at ang kasalukuyang tagal ng buhay at mga halaga ng DPD.
3. Hintayin ang pagbabalik ng IKE at IPsec, pagkatapos ay kumpirmahin ang mga ruta at ang mga kinakailangang prefix.
4. Ipadala ang isang representatibong daloy ng aplikasyon sa tunnel na iyon at panoorin ang dalawang direksyon.

Hindi magagamit ang tunnel habang hindi nagkakasundo ang mga dulo at habang inilalapat ng AWS ang pagbabago, kaya ang update ng kapares ay dapat sumunod agad at hindi pagkatapos ng tanghalian. Kapag dinadala na ng binagong tunnel ang tunay na trapiko saka mo lang ulitin ang pamamaraan sa isa pa.

Huminto kung hindi pa tiyak ang pagbawi o pagruruta pagkatapos ng unang tunnel. Ang dalawang tunnel na kalahating gumagana ay mas masama kaysa sa isang alam mong gumagana.

Kapag natigil ang pagbawi, basahin ang panig ng IKE

Ang tunnel na nananatiling bumagsak pagkatapos hawakan ng dalawang dulo ang bagong susi ay karaniwang pagkakaiba ng patakaran na inilantad ng pag-ikot at hindi nilikha nito. Ang mga panukala, ang pagkakakilanlang ipinapadala ng kapares at ang mga tagapili ng trapiko ay dapat lahat sumang-ayon sa panig ng AWS, at ang halagang nakaligtas sa isang naitatag na tunnel ay maaari pa ring tanggihan sa panahon ng bagong negosasyon. Basahin ang estado ng negosasyon at ang kalakip na mensahe bago baguhin ang susi sa ikalawang pagkakataon.

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

Kung kailangang ibalik ang pagbabago, huwag ibalik ang lumang susi dahil lang gumana ito noon. Ituring na kompromiso ang isang kompromisong susi at ayusin na lang ang negosasyon. Tapusin na na-verify ang dalawang tunnel at na-update ang imbentaryo ng mga lihim para maitala ng bawat kapares kung aling halaga ang hawak nito, at itago ang dokumentasyon ng mga opsyon ng tunnel ng AWS sa tabi ng runbook.