Известия за вход във 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 оставят празнини, затова известието се нуждае от път за сверка, който пита таблицата с живи сесии, преди някой да заключи, че тунелът все още работи.
Дръжте одита и известията отделно
Потокът за одит и потокът за известия имат различни задачи. Пазете суровите записи, включително акаунт, шлюз, идентификатор на сесия, времеви марки и причина за прекратяване, дори когато рутинните имейли се групират, потискат или изпращат до малък дежурен списък. Прагът на тежест е филтър за доставка, а не избор на събитието от жизнения цикъл, което сте искали да обявите.
Изпращайте минималния контекст, от който получателят се нуждае, за да намери защитения запис. Имената на акаунтите, вътрешните адреси и детайлите на сесиите са чувствителни, а имейл, който се препраща добре, е имейл, който изтича добре.
След това го докажете от край до край. Направете нормален вход и изход, повторно свързване, две едновременни сесии и принудителен отказ при доставка, и проследете едно събитие от шлюза през колектора до доставеното съобщение. Ако имейлът пристигне без идентификатор на сесия, договорът е непълен. Ако два имейла описват една сесия, корелацията е счупена. Нито един от двата проблема не се показва, когато единственото, което тествате, е че доставката на поща работи.