Предупредувања за најава на 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 за завршување на сите следни чекори е најчестата грешка. Тоа е пресуда за акредитивите, не сесија. Огледалната грешка е да се чита совпаѓањето на политика како доказ за авторизација, кога правилото може да се совпадне, а следниот чекор сепак може да пропадне.
Една сесија, едно известување
Една сметка, повеќе уреди, повторни испраќања и повторни поврзувања: една е-пошта по настан ќе биде погрешна во двете насоки, дуплирајќи ја едната сесија и разделувајќи ја другата. Клучот на известувањето ставете го на портата плус идентификатор на сесијата, а името на сметката третирајте го како атрибут, а не како клуч. Корисникот со пренослив компјутер и телефон може да држи два тунели истовремено, и двата заслужуваат свој ред.
Повторно испратените сметководствени записи се нормални, затоа отстранете ги дупликатите по id на сесијата и временската ознака пред да ја прикажете пораката. Последователните сесии од истиот уред треба да останат одделни, а повторното поврзување за време на прозорец за одржување треба да остане видливо наместо да се спои со претходната. Ако вашиот собирач ги препишува временските ознаки при преземање, отстранете ги дупликатите по полињата на оригиналниот запис, не по зачуваните.
Недостасувачкиот Stop запис е неизвесност, не постојана сесија. Рестартирањата на портата, прекините на собирачот и загубата на UDP оставаат празнини, затоа предупредувањето бара пат за усогласување што ја прашува табелата со активни сесии пред некој да заклучи дека тунелот продолжува да работи.
Држете ја ревизијата и известувањето одделно
Текот за ревизија и текот за предупредувања имаат различни задачи. Чувајте ги суровите записи, вклучително сметка, порта, id на сесија, временски ознаки и причина за прекин, дури и кога рутинските е-пораки се групираат, потиснуваат или се испраќаат на мал дежурен список. Прагот на сериозност е филтер за доставување, не избор на настанот од животниот циклус што сакавте да го објавите.
Испратете го минималниот контекст што му е потребен на примачот за да го најде заштитениот запис. Имињата на сметките, внатрешните адреси и деталите за сесијата се чувствителни, а е-поштата што добро се препраќа е е-пошта што добро истекува.
Потоа докажете го од почеток до крај. Извршете нормална најава и одјава, повторно поврзување, две истовремени сесии и принуден неуспех при доставување, и следете еден настан од портата преку собирачот до доставената порака. Ако е-поштата пристигне без id на сесија, договорот е нецелосен. Ако две е-пораки опишуваат една сесија, корелацијата е скршена. Ниту еден од двата проблема не се појавува кога единственото што го тестирате е дека доставувањето пошта работи.