VPN prisijungimo įspėjimai: koks įvykis iš tikrųjų turėtų juos suaktyvinti?
Sėkminga autentifikacija, sukuriamas tunelis ir RADIUS accounting Start yra trys skirtingi teiginiai. Pasirinkite tą, pagal kurį jūsų gavėjas gali veikti, ir tada juos susiekite.
Sėkminga autentifikacija, sukuriamas tunelis ir RADIUS accounting Start yra trys skirtingi teiginiai, o prisijungimo laiškas ką nors reiškia tik pasirinkus vieną iš jų. Dauguma VPN įspėjimų dizainų sumaišo visus tris ir sukuria pašto dėžutę, kuria niekas nepasitiki. Sprendimas priklauso nuo to, kas skaito įspėjimą ir ką jis gali padaryti per kitas penkias minutes. Suklydę įspėjimas tampa triukšmu, slepiančiu vienintelį įvykį, kurio jums reikėjo.
Trys klausimai nusprendžia, kas bus trigeris
Paklauskite, kas jį gaus, ką jis darys ir kaip greitai veiksmas turi įvykti. Saugumo komanda, stebinti piktnaudžiavimą prisijungimo duomenimis, nori nesėkmės ir po to sėkmės modelio iš vienos paskyros per kelias minutes. Operacijų komanda, stebinti pajėgumą, nori sesijos trukmės ir atsijungimo priežasčių, o ne prisijungimų. Pagalbos tarnyba nori sesijos tapatybės, kad galėtų ją susieti su bilietu.
Tie atsakymai rodo į skirtingus įvykius, ir jokia viena taisyklė netenkina visų trijų. Jei gavėjo veiksmas yra „paskambink naudotojui“, autentifikacijos pakanka. Jei veiksmas yra „atleisk licenciją“ arba „patikrink, ar tunelis pernešė srautą“, tinka tik sukūrimas arba accounting Start. Jei veiksmas yra „išrašyk sąskaitą už laiką“, jums reikia Stop įrašų, o ne prisijungimo.
Prieš ką nors konfigūruodami, užrašykite atsakymą vienu sakiniu. „Šis laiškas pasako budinčiam inžinieriui, kad paskyra X atidarė tunelį iš tinklo Y laiku Z, kad jis galėtų patikrinti, ar buvo naudojamas techninės priežiūros langas.“ Jei negalite užpildyti kiekvieno lauko, trigeris dar nepasirinktas.
Suderinkite įvykį su teiginiu, kurį pateikiate
| 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 |
Lentelė slepia priklausomybę: kiekviena eilutė patikima tik tada, kai vartai ją patikimai išleidžia, o jūsų rinkėjas išsaugo reikiamą lauką. Skaitykite įvykio apibrėžimą tiksliai tai versijai, kurią naudojate, nes pavadinimas „sesija sukurta“ keičiasi tarp versijų, o reikšmė keičiasi dažniau nei pavadinimas. Kai apibrėžimas neaiškus, prašykite sesijos įrašo, o ne spėkite pagal etiketę.
Access-Accept laikymas viso to, kas eina po jo, užbaigimu yra dažniausia klaida. Tai sprendimas dėl prisijungimo duomenų, o ne sesija. Veidrodinė klaida yra politikos atitikimą skaityti kaip įgaliojimo įrodymą, kai taisyklė gali atitikti, o kitas žingsnis vis tiek gali nepavykti.
Viena sesija, vienas pranešimas
Viena paskyra, keli įrenginiai, pakartotiniai siuntimai ir prisijungimai iš naujo: vienas laiškas vienam įvykiui bus klaidingas abiem kryptimis, dubliuodamas vieną sesiją ir skaidydamas kitą. Pranešimo raktą kurkite iš vartų ir sesijos identifikatoriaus, o paskyros vardą laikykite atributu, o ne raktu. Naudotojas su nešiojamuoju ir telefonu gali vienu metu turėti du tunelius, ir abu verti savo eilutės.
Pakartotinai siunčiami apskaitos įrašai yra normalūs, todėl prieš pateikdami pranešimą pašalinkite dublikatus pagal sesijos id ir laiko žymą. Tos pačios įrenginio iš eilės einančios sesijos turėtų likti atskiros, o prisijungimas iš naujo techninės priežiūros lango metu turėtų likti matomas, o ne susilieti su ankstesniu. Jei jūsų rinkėjas įrašymo metu perrašo laiko žymas, šalinkite dublikatus pagal pirminio įrašo laukus, o ne pagal išsaugotus.
Trūkstamas Stop įrašas yra neapibrėžtumas, o ne nuolatinė sesija. Vartų perkrovimai, rinkėjo sutrikimai ir UDP praradimas palieka spragas, todėl įspėjimui reikia suderinimo kelio, kuris prieš kam nors padarant išvadą, kad tunelis dar veikia, užklaustų aktyvių sesijų lentelę.
Laikykite auditą ir pranešimus atskirai
Audito srautas ir įspėjimų srautas turi skirtingas užduotis. Saugokite neapdorotus įrašus, įskaitant paskyrą, vartus, sesijos id, laiko žymas ir nutraukimo priežastį, net kai įprasti laiškai grupuojami, slopinami ar siunčiami mažam budinčių sąrašui. Sunkumo slenkstis yra pristatymo filtras, o ne gyvavimo ciklo įvykio, kurį norėjote paskelbti, pasirinkimas.
Siųskite minimalų kontekstą, kurio gavėjui reikia apsaugotam įrašui rasti. Paskyrų vardai, vidiniai adresai ir sesijos detalės yra jautrūs, o laiškas, kuris gerai persiunčiamas, yra laiškas, kuris gerai nuteka.
Tada įrodykite tai nuo pradžios iki pabaigos. Atlikite įprastą prisijungimą ir atsijungimą, prisijungimą iš naujo, dvi vienalaikes sesijas ir priverstinį pristatymo sutrikimą, ir atsekite vieną įvykį nuo vartų per rinkėją iki pristatyto pranešimo. Jei laiškas ateina be sesijos id, sutartis yra nepilna. Jei du laiškai aprašo vieną sesiją, koreliacija suardyta. Nė viena problema nepasireiškia, kai vienintelis dalykas, kurį tikrinate, yra tai, kad pašto pristatymas veikia.