Сповіщення про вхід у 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 залишають прогалини, тому сповіщенню потрібен шлях звірки, який запитує таблицю активних сеансів, перш ніж хтось вирішить, що тунель досі працює.
Тримайте аудит і сповіщення окремо
Потік аудиту й потік сповіщень мають різні завдання. Зберігайте необроблені записи, зокрема обліковий запис, шлюз, ідентифікатор сеансу, позначки часу та причину завершення, навіть коли звичайні листи групуються, пригнічуються або надсилаються до невеликого списку чергових. Поріг серйозності — це фільтр доставки, а не вибір події життєвого циклу, про яку ви хотіли оголосити.
Надсилайте мінімум контексту, потрібного одержувачу, щоб знайти захищений запис. Імена облікових записів, внутрішні адреси й деталі сеансу є чутливими, а лист, який добре пересилається, — це лист, який добре витікає.
Потім доведіть це від початку до кінця. Проведіть звичайний вхід і вихід, перепідключення, два одночасні сеанси й примусовий збій доставки, а потім простежте одну подію від шлюзу через збирач до доставленого повідомлення. Якщо лист надходить без ідентифікатора сеансу, контракт неповний. Якщо два листи описують один сеанс, кореляція зламана. Жодна з цих проблем не проявляється, коли єдине, що ви перевіряєте, — це робота доставки пошти.