Апавяшчэнні пра ўваход у 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 пакідаюць прабелы, таму апавяшчэнню патрэбны шлях зверкі, які запытвае табліцу актыўных сеансаў, перш чым хтосьці зробіць выснову, што тунель яшчэ працуе.
Трымайце аўдыт і апавяшчэнні асобна
Патток аўдыту і патток апавяшчэнняў маюць розныя задачы. Захоўвайце зыходныя запісы, уключаючы ўліковы запіс, шлюз, ідэнтыфікатар сеанса, час і прычыну завяршэння, нават калі звычайныя лісты групаваліся, падаўляліся або адпраўляліся ў невялікі спіс чарговых. Парог сур’ёзнасці — гэта фільтр дастаўкі, а не выбар падзеі жыццёвага цыклу, якую вы хацелі абвясціць.
Даслайце мінімум кантэксту, патрэбнага атрымальніку, каб знайсці абароненую запіс. Імёны ўліковых запісаў, унутраныя адрасы і дэталі сеансаў адчувальныя, а ліст, які добра перасылаецца, — гэта ліст, які добра ўцякае.
Затым давядзіце гэта ад пачатку да канца. Прайдзіце звычайны ўваход і выхад, перападключэнне, два адначасовыя сеансы і прымусовы збой дастаўкі, і прасачыце адну падзею ад шлюза праз зборшчык да дастаўленага паведамлення. Калі ліст прыходзіць без ідэнтыфікатара сеанса, кантракт няпоўны. Калі два лісты апісваюць адзін сеанс, суаднясенне зламанае. Ні адна з гэтых праблем не выяўляецца, калі адзінае, што вы правяраеце, — гэта праца дастаўкі пошты.