Оповещения о входе в VPN: какое событие должно их на самом деле запускать?
Успешная аутентификация, установленный туннель и RADIUS accounting Start — это три разных утверждения. Выберите то, на которое получатель может отреагировать, и затем сопоставьте их.
Успешная аутентификация, установленный туннель и RADIUS accounting Start — это три разных утверждения, и письмо о входе что-то значит только после того, как вы выберете одно из них. Большинство схем оповещений VPN смешивают все три и создают почтовый ящик, которому никто не доверяет. Решение зависит от того, кто читает оповещение и что он может сделать в следующие пять минут. Если ошибиться, оповещение превращается в шум, скрывающий то единственное событие, которое вам было нужно.
Три вопроса определяют триггер
Спросите, кто его получит, что он сделает и как быстро должно произойти действие. Команда безопасности, следящая за злоупотреблением учётными данными, хочет увидеть схему «неудача, затем успех» из одной учётной записи в течение нескольких минут. Операционная команда, следящая за ёмкостью, хочет длительность сеанса и причины отключения, а не входы. Служба поддержки хочет идентификатор сеанса, чтобы сопоставить его с заявкой.
Эти ответы указывают на разные события, и ни одно правило не удовлетворяет все три. Если действие получателя — «позвонить пользователю», достаточно аутентификации. Если действие — «освободить лицензию» или «проверить, что туннель передавал трафик», подойдёт только установка или accounting Start. Если действие — «выставить счёт за время», нужны записи Stop, а не вход.
Запишите ответ одним предложением, прежде чем что-либо настраивать. «Это письмо сообщает дежурному инженеру, что учётная запись X открыла туннель из сети Y во время Z, чтобы он мог проверить, использовалось ли окно обслуживания.» Если вы не можете заполнить каждое поле, триггер ещё не выбран.
Сопоставьте событие с утверждением, которое вы делаете
| Record | What it proves | What it leaves open |
|---|---|---|
| Rejected credentials | The attempt failed at the credential step | Whether it was a stale client or a real person |
| Access-Accept | Credentials passed for this attempt | Anything about tunnel state or policy |
| Policy match record | A rule matched the request | Whether later steps completed |
| Tunnel established | The gateway accepted a session | Whether traffic flowed or the user got an address |
| Accounting Start | User service began at the accounting layer | Whether the application behind it worked |
| Accounting Stop | That session was closed, with a reason field | Whether the reason is meaningful on your release |
Таблица скрывает зависимость: каждая строка заслуживает доверия только тогда, когда шлюз надёжно её выдаёт, а ваш сборщик сохраняет нужное поле. Читайте определение события именно для той версии, которую вы эксплуатируете, потому что название «сеанс установлен» меняется между версиями, а смысл меняется чаще названия. Когда определение расплывчато, запросите запись сеанса, а не угадывайте по метке.
Считать Access-Accept завершением всего, что идёт после него, — самая распространённая ошибка. Это вердикт об учётных данных, а не сеанс. Зеркальная ошибка — читать совпадение политики как доказательство авторизации, тогда как правило может совпасть, а следующий шаг всё равно может не выполниться.
Один сеанс — одно уведомление
Одна учётная запись, несколько устройств, повторные отправки и переподключения: письмо на каждое событие будет неверным в обе стороны, дублируя один сеанс и разделяя другой. Стройте ключ уведомления по шлюзу плюс идентификатору сеанса, а имя учётной записи считайте атрибутом, а не ключом. Пользователь с ноутбуком и телефоном может держать два туннеля одновременно, и оба заслуживают собственной строки.
Повторно отправленные записи учёта — это нормально, поэтому удаляйте дубликаты по идентификатору сеанса и отметке времени до формирования сообщения. Последовательные сеансы с одного устройства должны оставаться раздельными, а переподключение во время окна обслуживания должно оставаться видимым, а не сливаться с предыдущим. Если ваш сборщик переписывает отметки времени при приёме, удаляйте дубликаты по полям исходной записи, а не по сохранённым.
Отсутствующая запись Stop — это неопределённость, а не постоянный сеанс. Перезагрузки шлюза, сбои сборщика и потери UDP оставляют пробелы, поэтому оповещению нужен путь сверки, который запрашивает таблицу активных сеансов, прежде чем кто-либо решит, что туннель всё ещё работает.
Держите аудит и уведомления отдельно
Поток аудита и поток оповещений решают разные задачи. Сохраняйте необработанные записи, включая учётную запись, шлюз, идентификатор сеанса, отметки времени и причину завершения, даже когда обычные письма группируются, подавляются или отправляются небольшому списку дежурных. Порог серьёзности — это фильтр доставки, а не выбор события жизненного цикла, о котором вы хотели объявить.
Отправляйте минимум контекста, необходимого получателю, чтобы найти защищённую запись. Имена учётных записей, внутренние адреса и детали сеанса чувствительны, а письмо, которое хорошо пересылается, — это письмо, которое хорошо утекает.
Затем докажите это от начала до конца. Проведите обычный вход и выход, переподключение, два одновременных сеанса и принудительный сбой доставки, а затем проследите одно событие от шлюза через сборщик до доставленного сообщения. Если письмо приходит без идентификатора сеанса, контракт неполон. Если два письма описывают один сеанс, корреляция нарушена. Ни одна из этих проблем не проявляется, когда единственное, что вы проверяете, — это работа доставки почты.