VPN upozorenja za prijavu: koji događaj ih zapravo treba pokretati?
Uspješna autentifikacija, uspostavljen tunel i RADIUS accounting Start tri su različite tvrdnje. Odaberite onu na koju vaš primalac može djelovati, a zatim je povežite.
Uspješna autentifikacija, uspostavljen tunel i RADIUS accounting Start tri su različite tvrdnje, a e-poruka o prijavi nešto znači tek kad odaberete jednu od njih. Većina dizajna VPN upozorenja pomiješa sve tri i stvori poštanski sandučić kojem nitko ne vjeruje. Odluka se svodi na to tko čita upozorenje i što može učiniti u sljedećih pet minuta. Pogriješite li, upozorenje postaje šum koji skriva jedini događaj koji vam je trebao.
Tri pitanja odlučuju o okidaču
Pitajte tko ga prima, što će učiniti i koliko brzo radnja mora uslijediti. Sigurnosni tim koji prati zloupotrebu akreditiva želi obrazac neuspjeh-pa-uspjeh s jednog računa u roku od nekoliko minuta. Operativni tim koji prati kapacitet želi trajanje sesije i razloge prekida, a ne prijave. Podrška želi identitet sesije kako bi ga mogla upariti s tiketom.
Ti odgovori upućuju na različite događaje i nijedno pravilo ne zadovoljava sva tri. Ako je radnja primaoca «pozovi korisnika», autentifikacija je dovoljna. Ako je radnja «oslobodi licencu» ili «provjeri je li tunel prenosio promet», samo uspostavljanje ili accounting Start će poslužiti. Ako je radnja «naplati vrijeme», potrebni su vam Stop zapisi, a ne prijava.
Zapišite odgovor u jednoj rečenici prije nego što bilo što konfigurišete. «Ova e-poruka govori dežurnom inženjeru da je račun X otvorio tunel s mreže Y u vrijeme Z, kako bi mogao provjeriti je li korišten prozor za održavanje.» Ako ne možete popuniti svako polje, okidač još nije odabran.
Uskladite događaj s tvrdnjom koju iznosite
| 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 zavisnost: svaki red je pouzdan samo ako ga gateway pouzdano emituje i ako vaš kolektor čuva polje koje vam treba. Čitajte definiciju događaja za tačno izdanje koje pokrećete, jer se naziv «sesija uspostavljena» mijenja između verzija, a značenje se mijenja češće od naziva. Kad je definicija nejasna, zatražite snimak sesije umjesto da nagađate iz oznake.
Tretirati Access-Accept kao završetak svega poslije njega najčešća je greška. To je presuda o akreditivima, ne sesija. Zrcalna greška je čitati podudaranje politike kao dokaz autorizacije, kad pravilo može da se podudari, a sljedeći korak ipak može propasti.
Jedna sesija, jedno obavještenje
Jedan račun, više uređaja, ponovna slanja i ponovna povezivanja: e-poruka po događaju bit će pogrešna u oba smjera, duplirajući jednu sesiju i dijeleći drugu. Vežite obavještenje na gateway plus identifikator sesije, a naziv računa tretirajte kao atribut, a ne kao ključ. Korisnik s laptopom i telefonom može držati dva tunela istovremeno i oba zaslužuju svoj red.
Ponovno poslani računovodstveni zapisi su normalni, pa uklonite duplikate po id-u sesije i vremenskoj oznaci prije nego što prikažete poruku. Uzastopne sesije s istog uređaja trebaju ostati odvojene, a ponovno povezivanje tokom prozora za održavanje treba ostati vidljivo umjesto da se stopi s prethodnom. Ako vaš kolektor prepisuje vremenske oznake pri prijemu, uklanjajte duplikate po poljima originalnog zapisa, a ne po pohranjenima.
Nedostajući Stop zapis je neizvjesnost, a ne trajna sesija. Ponovna podizanja gatewaya, prekidi kolektora i gubitak UDP-a ostavljaju praznine, pa upozorenje treba put za usklađivanje koji pita tabelu aktivnih sesija prije nego što bilo tko zaključi da je tunel još otvoren.
Držite reviziju i obavještavanje odvojeno
Tok revizije i tok upozorenja imaju različite poslove. Čuvajte sirove zapise, uključujući račun, gateway, id sesije, vremenske oznake i razlog prekida, čak i kad se rutinske e-poruke grupišu, potiskuju ili šalju na malu dežurnu listu. Prag ozbiljnosti je filter isporuke, a ne izbor događaja životnog ciklusa koji ste namjeravali najaviti.
Pošaljite minimum konteksta koji primalac treba da pronađe zaštićeni zapis. Nazivi računa, interne adrese i detalji sesije su osjetljivi, a e-poruka koja se dobro prosljeđuje je e-poruka koja dobro curi.
Zatim to dokažite od početka do kraja. Provedite normalnu prijavu i odjavu, ponovno povezivanje, dvije istovremene sesije i prisilni neuspjeh isporuke, te pratite jedan događaj od gatewaya kroz kolektor do isporučene poruke. Ako e-poruka stigne bez id-a sesije, ugovor je nepotpun. Ako dvije e-poruke opisuju jednu sesiju, korelacija je pokvarena. Nijedan od tih problema ne pokaže se kad je jedino što testirate to da dostava pošte radi.