Стоит ли включать журналы туннеля 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 по включению журналов описывает рабочий процесс для каждого туннеля и предупреждение о прерывании, и её стоит прочитать до изменения, а не после. Затем проверьте по порядку: туннель вернулся, записи появляются в ожидаемом потоке и записи отвечают на вопрос, ради которого вы открыли заявку. Если третий пункт не выполнен, проблема была в выборе потока, а не в журналировании.