Opozorila ob prijavi v VPN: kateri dogodek naj jih pravzaprav sproži?
Uspešna avtentikacija, vzpostavljen tunel in RADIUS accounting Start so tri različne trditve. Izberite tisto, na katero se lahko vaš prejemnik odzove, in jih nato povežite.
Uspešna avtentikacija, vzpostavljen tunel in RADIUS accounting Start so tri različne trditve, e-poštno sporočilo o prijavi pa nekaj pomeni šele, ko izberete eno od njih. Večina zasnov opozoril VPN vse tri zmeša in ustvari nabiralnik, ki mu nihče ne zaupa. Odločitev je odvisna od tega, kdo opozorilo prebere in kaj lahko stori v naslednjih petih minutah. Če to zgrešite, opozorilo postane hrup, ki skrije edini dogodek, ki ste ga potrebovali.
O prožilcu odločajo tri vprašanja
Vprašajte, kdo ga bo prejel, kaj bo storil in kako hitro mora dejanje nastopiti. Varnostna ekipa, ki spremlja zlorabo poverilnic, želi v nekaj minutah vzorec neuspeha in nato uspeha z enega računa. Operativna ekipa, ki spremlja zmogljivost, želi trajanje seje in razloge za prekinitev, ne prijav. Helpdesk želi identiteto seje, da jo lahko poveže z zahtevkom.
Ti odgovori kažejo na različne dogodke in nobeno posamezno pravilo ne zadovolji vseh treh. Če je dejanje prejemnika »pokliči uporabnika«, zadostuje avtentikacija. Če je dejanje »sprosti licenco« ali »preveri, ali je tunel prenašal promet«, bo delovala samo vzpostavitev ali accounting Start. Če je dejanje »zaračunaj čas«, potrebujete zapise Stop, ne prijave.
Preden kar koli nastavite, zapišite odgovor v enem stavku. »To sporočilo pove dežurnemu inženirju, da je račun X ob času Z odprl tunel iz omrežja Y, da lahko preveri, ali je bilo uporabljeno okno za vzdrževanje.« Če ne morete izpolniti vsakega polja, prožilec še ni izbran.
Uskladite dogodek s trditvijo, ki jo podajate
| 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 |
Tabela skriva odvisnost: vsaka vrstica je zanesljiva le, če jo prehod zanesljivo pošilja in vaš zbiralnik ohrani polje, ki ga potrebujete. Preberite definicijo dogodka za točno tisto različico, ki jo upravljate, ker se ime »seja vzpostavljena« med različicami spreminja, pomen pa se spreminja pogosteje kot ime. Ko je definicija nejasna, prosite za posnetek seje, namesto da bi ugibali po oznaki.
Obravnavati Access-Accept kot dokončanje vsega, kar sledi, je najpogostejša napaka. To je razsodba o poverilnicah, ne seja. Zrcalna napaka je brati ujemanje s pravilnikom kot dokaz avtorizacije, ko se pravilo lahko ujema in naslednji korak vseeno lahko spodleti.
Ena seja, eno obvestilo
En račun, več naprav, ponovna pošiljanja in ponovne povezave: eno e-poštno sporočilo na dogodek bo napačno v obe smeri, eno sejo bo podvojilo in drugo razdelilo. Ključ obvestila naj bosta prehod in identifikator seje, ime računa pa obravnavajte kot atribut, ne kot ključ. Uporabnik s prenosnikom in telefonom ima lahko hkrati dva tunela in oba si zaslužita svojo vrstico.
Ponovno poslani knjigovodski zapisi so običajni, zato pred izrisom sporočila odstranite dvojnike po id-ju seje in časovnem žigu. Zaporedne seje z iste naprave naj ostanejo ločene, ponovna povezava med oknom za vzdrževanje pa naj ostane vidna, namesto da se zlije s prejšnjo. Če vaš zbiralnik pri zajemu prepisuje časovne žige, odstranjujte dvojnike po poljih izvirnega zapisa, ne po shranjenih.
Manjkajoč zapis Stop je negotovost, ne trajna seja. Ponovni zagoni prehoda, izpadi zbiralnika in izguba UDP puščajo vrzeli, zato opozorilo potrebuje pot usklajevanja, ki povpraša tabelo aktivnih sej, preden kdo sklene, da tunel še deluje.
Revizijo in obveščanje imejte ločeno
Tok revizije in tok opozoril imata različne naloge. Ohranite surove zapise, vključno z računom, prehodom, id-jem seje, časovnimi žigi in razlogom zaključka, tudi ko so rutinska e-poštna sporočila združena, zatrta ali poslana na majhen dežurni seznam. Prag resnosti je filter dostave, ne izbira dogodka življenjskega cikla, ki ste ga želeli objaviti.
Pošljite najmanjši kontekst, ki ga prejemnik potrebuje za iskanje zaščitenega zapisa. Imena računov, notranji naslovi in podrobnosti seje so občutljivi, e-pošta, ki se dobro posreduje, pa je e-pošta, ki dobro pušča.
Nato to dokažite od začetka do konca. Izvedite običajno prijavo in odjavo, ponovno povezavo, dve sočasni seji in vsiljeno napako dostave ter sledite enemu dogodku od prehoda skozi zbiralnik do dostavljenega sporočila. Če e-pošta prispe brez id-ja seje, je pogodba nepopolna. Če dve e-pošti opisujeta eno sejo, je korelacija pokvarjena. Nobena od težav se ne pokaže, ko je edino, kar testirate, to, da dostava pošte deluje.