Ці варта ўключаць журналы тунэля AWS VPN на працоўным тунэлі?

Уключэнне журналаў актыўнасці тунэля для Site-to-Site VPN — дробнае змяненне, якое можа абрынуць тунэль, які яно вымярае. AWS папярэджвае, што ўключэнне журналавання на існуючым тунэлі можа перапыніць яго на некалькі хвілін, таму цікавае пытанне не ў тым, як пераключыць сцяг, а ў тым, на якім тунэлі і калі гэта зрабіць. Парадак вызначаюць тры ўмовы: ці сапраўды іншы тунэль нясе маршруты, ці патрэбны вам падзеі сэрвісу або падзеі BGP, і ці ідзе змяненне праз кансоль або праз API параметраў тунэля. Памыліцеся — і атрымаеце або перапынак, або групу журналаў, поўную нічога.

Тры ўмовы вызначаюць парадак

Пачніце з ідэнтычнасці таго, што вы змяняеце. Патрэбны ідэнтыфікатар злучэння VPN, рэгіён і знешні IP-адрас канкрэтнага тунэля, бо кожная налада журнала ў гэтай функцыі — на тунэль, а не на злучэнне. Змяненне, прымененае да няправільнага знешняга адраса, — гэта змяненне тунэля, які ніхто не адладжваў.

Прызначэнне — група журналаў CloudWatch у тым жа рэгіёне, з палітыкай захавання і доступу, якой вы сапраўды хочаце. AWS рэкамендуе прэфікс /aws/vendedlogs/ для гэтых груп, бо ён пазбягае абмежаванняў памеру палітыкі рэсурсаў, на якія могуць натыкнуцца звычайныя назвы. Назва накшталт /aws/vendedlogs/vpn/branch-a-activity — толькі ілюстрацыя; важна, што група існуе, што роля дастаўкі можа ў яе пісаць і што абедзве кіруюцца тым, хто валодае канфігурацыяй VPN. Назва не дае правоў, а група, створаная без палітыкі дастаўкі, дае цішыню, а не памылку.

Першая ўмова: рэзервовы тунэль, які сапраўды нясе трафік

Гэта ўмова, якую каманды прапускаюць. Два наладжаныя тунэлі не даказваюць, што ў праграмы ёсць працаздольны альтэрнатыўны шлях.

Перш чым крануць адзін тунэль, пераканайцеся, што іншы нясе тыя маршруты, якія важныя: праверце табліцу маршрутызацыі на баку шлюза заказчыка і пераканайцеся, што праграма сапраўды можа пераключыцца. Акно перапынку ў AWS — хвіліны, а не секунды, і тунэль, які існуе толькі на паперы, ператварае дыягнастычнае змяненне ў перапынак. Калі рэзервовы шлях не даказаны, плануйце змяненне з той жа асцярогай, як любое іншае змяненне маршрутызацыі, замест таго каб лічыць журналаванне пасіўным. Інструментуйце тунэль, паводзіны якога вы спрабуеце патлумачыць, а не той, да якога лягчэй дабрацца.

Другая ўмова: журнал актыўнасці ці журнал BGP

Гэтая ўмова вырашае, што вы зможаце прачытаць. Запісы актыўнасці ахопліваюць падзеі сэрвісу, такія як пераходы станаў IKE і IPsec і паведамленні DPD, — менавіта тое, што трэба, калі тунэль не ўздымаецца або пастаянна перазаводзіць ключы. Запісы BGP — асобны паток са сваімі кіравальнымі сродкамі, і яны адказваюць на іншае пытанне: ці абменьваліся маршруты і ці адклікаліся яны як чакалася.

Уключэнне сцяга актыўнасці — не запыт на кожны паток, які сэрвіс можа выдаваць. Калі падазрэнне ў маршрутызацыі, уключыце абодва; калі падазрэнне ў перамовах фазы 1 або фазы 2, паток актыўнасці — той, што гэта пакажа.

Ні адзін з патокаў не з'яўляецца захопам пакетаў, і гэтае адрозненне вырашае больш заявак, чым трэба. Запісы актыўнасці і BGP кажуць, што сэрвіс зрабіў з тунэлем і сеансам, а не што ваша праграма праз іх адправіла. Звяртацца да журналаў тунэля, каб адладзіць тайм-аўт праграмы, — памылка катэгорыі, і яна звычайна каштуе акна перапынку, перш чым хтосьці гэта заўважыць. Спачатку выберыце пытанне, потым паток, які можа на яго адказаць.

Трэцяя ўмова: змяненне праз кансоль ці API параметраў тунэля

Калі чалавек робіць разовае змяненне, шлях праз кансоль падыходзіць: VPC console, Site-to-Site VPN connections, выберыце злучэнне, Actions, Modify VPN tunnel options, выберыце знешні IP, уключыце Tunnel activity log, выберыце групу і фармат вываду, захавайце ў межах акна. Калі VPN кіруецца як код, той самы клік — гэта дрыфт, які вы ўзгодніце пазней.

Для аўтаматызацыі частка журнала актыўнасці ў параметрах тунэля мае фіксаваную форму: LogOptions змяшчае CloudWatchLogOptions з LogEnabled, LogGroupArn і LogOutputFormat. Гэты блок — фрагмент, а не запыт; modify-vpn-tunnel-options усё яшчэ патрабуе ідэнтыфікатар злучэння і знешні IP тунэля, а астатнія налады тунэля павінен захаваць той, хто валодае шаблонам. Журналаванне BGP выкарыстоўвае свае ключы BgpLogEnabled, BgpLogGroupArn і BgpLogOutputFormat у той жа структуры. Перачытайце змяненне праз describe-vpn-connections замест таго, каб давяраць, што выклік прымяніўся.

Што запісы могуць і не могуць вам сказаць

Калі першы тунэль гатовы і патрэбны шлях даступны, паўтарыце тую ж кантраляваную паслядоўнасць для другога тунэля, калі яго журналы таксама патрэбны. Па адным тунэлі за раз — у гэтым і ўвесь сэнс.

Запісы прыходзяць у патоках, ідэнтыфікаваных злучэннем і знешнім адрасам тунэля, таму карэлюйце па гэтай ідэнтычнасці, а не чакайце, што гісторыя з'явіцца заднім чыслом. Нічога да змянення не існуе, і ніякае чаканне не запоўніць прабел. Калі патрэбна базавая лінія, зафіксуйце бягучы стан тунэля і табліцу маршрутызацыі да змянення, каб было з чым параўноўваць.

Трымайце групу журналаў, яе захаванне, яе дазволы на дастаўку і блок параметраў тунэля ў тым жа інвентары, што і сам VPN, бо гэта адна канфігурацыя, раскіданая па чатырох месцах. Працэдура ўключэння журналаў AWS апісвае працоўны працэс для кожнага тунэля і папярэджанне пра перапынак, і яе варта прачытаць да змянення, а не пасля. Затым праверце па парадку: тунэль вярнуўся, запісы з'яўляюцца ў чаканым патоку, і запісы адказваюць на пытанне, дзеля якога вы адкрылі заяўку. Калі трэцяе не выканана, праблема была ў выбары патоку, а не ў журналаванні.