Чи варто вмикати журнали тунелю AWS VPN на робочому тунелі?

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

Порядок визначають три умови

Почніть з ідентичності того, що ви змінюєте. Вам потрібні ID підключення 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 усе ще потребує ID підключення й зовнішнього IP тунелю, а решту налаштувань тунелю має зберегти власник шаблону. Журналювання BGP використовує власні ключі BgpLogEnabled, BgpLogGroupArn і BgpLogOutputFormat у тій самій структурі. Прочитайте зміну назад за допомогою describe-vpn-connections, а не покладайтеся на те, що виклик застосовано.

Що записи можуть і чого не можуть вам сказати

Коли перший тунель готовий і потрібний шлях доступний, повторіть ту саму контрольовану послідовність для другого тунелю, якщо його журнали теж потрібні. Один тунель за раз — у цьому весь сенс.

Записи надходять у потоках, що визначаються підключенням і зовнішньою адресою тунелю, тож корелюйте з цією ідентичністю, а не чекайте, що історія з'явиться заднім числом. Нічого до зміни не існує, і жодне очікування не заповнить прогалину. Якщо потрібна базова лінія, зафіксуйте поточний стан тунелю й таблицю маршрутизації до зміни, щоб було з чим порівнювати.

Тримайте групу журналів, її зберігання, права доставки й блок параметрів тунелю в тому самому реєстрі, що й сам VPN, бо це одна конфігурація, рознесена на чотири місця. Процедура AWS з увімкнення журналів описує робочий процес для кожного тунелю та попередження про переривання, і її варто прочитати до зміни, а не після. Потім перевірте по черзі: тунель повернувся, записи з'являються в очікуваному потоці й записи відповідають на питання, заради якого ви відкрили заявку. Якщо третій пункт не виконано, проблема була у виборі потоку, а не в журналюванні.