Dapat mo bang i-enable ang mga log ng tunnel ng AWS VPN sa isang live na tunnel?

Ang pag-on ng mga log ng aktibidad ng tunnel para sa isang Site-to-Site VPN ay isang maliit na pagbabago na maaaring magpabagsak sa tunnel na sinusukat nito. Nagbabala ang AWS na ang pag-enable ng logging sa isang umiiral na tunnel ay maaaring makagambala dito nang ilang minuto, kaya ang kawili-wiling tanong ay hindi kung paano iikot ang bandila kundi kung aling tunnel ito iikot at kailan. Tatlong kondisyon ang nagtatakda ng pagkakasunod-sunod: kung talagang dinadala ng kabilang tunnel ang mga ruta, kung kailangan mo ng mga kaganapan ng serbisyo o mga kaganapan ng BGP, at kung dumadaan ang pagbabago sa console o sa API ng mga opsyon ng tunnel. Kapag nagkamali ka, mapupunta ka sa pagkagambala o sa isang pangkat ng log na puno ng wala.

Tatlong kondisyon ang nagtatakda ng pagkakasunod-sunod

Magsimula sa pagkakakilanlan ng bagay na binabago mo. Kailangan mo ang ID ng koneksyon ng VPN, ang Rehiyon at ang panlabas na IP address ng partikular na tunnel, dahil ang bawat setting ng log sa feature na ito ay bawat tunnel at hindi bawat koneksyon. Ang pagbabagong inilapat sa maling panlabas na address ay pagbabago sa isang tunnel na walang nagde-debug.

Ang destinasyon ay isang pangkat ng log ng CloudWatch sa parehong Rehiyon, kasama ang retention at patakaran sa pag-access na talagang gusto mo. Inirerekomenda ng AWS ang unlaping /aws/vendedlogs/ para sa mga pangkat na ito dahil iniiwasan nito ang mga limitasyon sa laki ng patakaran ng mapagkukunan na maaaring mabangga ng mga ordinaryong pangalan. Ang pangalan tulad ng /aws/vendedlogs/vpn/branch-a-activity ay isang halimbawa lamang; ang mahalaga ay umiiral ang pangkat, makakapagsulat dito ang papel ng paghahatid, at pareho silang pinamamahalaan ng nagmamay-ari ng configuration ng VPN. Ang pangalan ay hindi nagbibigay ng pahintulot, at ang pangkat na ginawa nang walang patakaran ng paghahatid ay nagbubunga ng katahimikan sa halip na error.

Unang kondisyon: isang redundant na tunnel na talagang nagdadala ng trapiko

Ito ang kondisyong nilalaktawan ng mga koponan. Ang dalawang naka-configure na tunnel ay hindi patunay na may magagamit na alternatibong landas ang application.

Bago mo hawakan ang isang tunnel, tiyakin na dinadala ng isa ang mahahalagang ruta: tingnan ang routing table sa gilid ng gateway ng customer at tiyakin na talagang makakalipat ang application. Ang window ng pagkagambala ng AWS ay minuto, hindi segundo, at ang tunnel na umiiral lamang sa papel ay ginagawang pagkagambala ang isang diagnostic na pagbabago. Kung hindi napatunayan ang redundant na landas, planuhin ang pagbabago nang may parehong pag-iingat tulad ng anumang iba pang pagbabago sa routing sa halip na ituring ang logging na passive. Instrumentuhin ang tunnel na sinusubukan mong ipaliwanag ang pag-uugali, hindi ang mas madaling maabot.

Ikalawang kondisyon: log ng aktibidad o log ng BGP

Ito ang nagtatakda kung ano ang talagang mababasa mo. Sinasaklaw ng mga talaan ng aktibidad ang mga kaganapan ng serbisyo tulad ng mga paglipat ng estado ng IKE at IPsec at mga mensahe ng DPD, na siyang kailangan mo kapag hindi bumabangon ang tunnel o patuloy na nagre-refresh ng mga key. Ang mga talaan ng BGP ay isang hiwalay na stream na may sariling mga kontrol, at sinasagot nila ang ibang tanong: kung ang mga ruta ay naipagpalit at naibalik ayon sa inaasahan.

Ang pag-enable ng bandila ng aktibidad ay hindi isang kahilingan para sa bawat stream na maaaring ilabas ng serbisyo. Kung ang hinala ay routing, i-enable ang pareho; kung ang hinala ay negosasyon ng phase 1 o phase 2, ang stream ng aktibidad ang magpapakita nito.

Wala sa dalawang stream ang packet capture, at ang pagkakaibang iyon ay lumulutas ng mas maraming ticket kaysa nararapat. Sinasabi ng mga talaan ng aktibidad at BGP kung ano ang ginawa ng serbisyo sa tunnel at session, hindi kung ano ang ipinadala ng iyong application sa pamamagitan nito. Ang pag-abot sa mga log ng tunnel para i-debug ang timeout ng application ay isang pagkakamali sa kategorya, at karaniwang nagkakahalaga ito ng isang window ng pagkagambala bago may makapansin. Piliin muna ang tanong, pagkatapos ang stream na makasasagot nito.

Ikatlong kondisyon: pagbabago sa console o API ng mga opsyon ng tunnel

Kung isang tao ang gumagawa ng isang beses na pagbabago, maayos ang landas sa console: VPC console, Site-to-Site VPN connections, piliin ang koneksyon, Actions, Modify VPN tunnel options, piliin ang panlabas na IP, i-enable ang Tunnel activity log, piliin ang pangkat at ang format ng output, i-save sa loob ng window. Kung ang VPN ay pinamamahalaan bilang code, ang parehong pag-click ay drift na iaayos mo mamaya.

Para sa automation, ang bahagi ng log ng aktibidad ng mga opsyon ng tunnel ay may nakapirming hugis: LogOptions na naglalaman ng CloudWatchLogOptions kasama ang LogEnabled, LogGroupArn at LogOutputFormat. Ang bloke na iyon ay isang fragment, hindi isang kahilingan; kailangan pa rin ng modify-vpn-tunnel-options ang ID ng koneksyon at ang panlabas na IP ng tunnel, at ang natitirang mga setting ng tunnel ay dapat pangalagaan ng nagmamay-ari ng template. Gumagamit ang logging ng BGP ng sarili nitong mga key BgpLogEnabled, BgpLogGroupArn at BgpLogOutputFormat sa parehong istruktura. Basahin muli ang pagbabago gamit ang describe-vpn-connections sa halip na maniwala na inilapat ang tawag.

Ano ang masasabi at hindi masasabi ng mga talaan

Kapag tapos na ang unang tunnel at available na ang nilalayong landas, ulitin ang parehong kontroladong pagkakasunod-sunod para sa ikalawang tunnel kung kailangan mo rin ang mga log nito. Isang tunnel sa isang pagkakataon ang buong punto.

Dumarating ang mga talaan sa mga stream na kinikilala ng koneksyon at ng panlabas na address ng tunnel, kaya iugnay sa pagkakakilanlang iyon sa halip na asahan na lalabas ang kasaysayan nang paatras. Walang umiiral bago ang pagbabago, at walang paghihintay na pumupuno sa puwang. Kung kailangan mo ng baseline, itala ang kasalukuyang estado ng tunnel at ang routing table bago ang pagbabago upang may maihahambing.

Panatilihin ang pangkat ng log, ang retention nito, ang mga pahintulot sa paghahatid at ang bloke ng mga opsyon ng tunnel sa parehong imbentaryo ng VPN mismo, dahil isa lamang itong configuration na nakakalat sa apat na lugar. Ang pamamaraan ng AWS sa pag-enable ng mga log ay nagdodokumento ng workflow bawat tunnel at ang babala nito sa pagkagambala, at sulit itong basahin bago ang pagbabago at hindi pagkatapos. Pagkatapos, i-verify nang sunud-sunod: bumalik ang tunnel, lumalabas ang mga talaan sa inaasahang stream, at sinasagot ng mga talaan ang tanong na dahilan ng pagbubukas mo ng ticket. Kung nabigo ang pangatlo, ang problema ay ang pagpili ng stream at hindi ang logging.