Упозорења о пријави на 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-а сесије, уговор је непотпуна. Ако два имејла описују једну сесију, корелација је покварена. Ниједан од та два проблема се не показује када је једино што тестирате то да достава поште ради.