VPN-innloggingsvarsel: kva hending bør eigentleg utløyse dei?
Vellukka autentisering, ein etablert tunnel og ein RADIUS accounting Start er tre ulike påstandar. Vel den mottakaren din kan handle på, og korreler deretter.
Vellukka autentisering, ein etablert tunnel og ein RADIUS accounting Start er tre ulike påstandar, og ein innloggings-e-post betyr først noko når du vel ein av dei. Dei fleste design for VPN-varsel blandar alle tre og lagar ein innboks ingen stolar på. Avgjerda heng saman med kven som les varselet og kva dei kan gjere dei neste fem minutta. Går det gale, blir varselet støy som skjuler den eine hendinga du trong.
Tre spørsmål avgjer utløysaren
Spør kven som får det, kva dei vil gjere og kor raskt handlinga må skje. Eit tryggingsteam som overvakar misbruk av innloggingsdata vil ha eit mønster med feil og deretter suksess frå éin konto innan få minutt. Eit driftsteam som overvakar kapasitet vil ha sesjonslengd og årsaker til fråkopling, ikkje innloggingar. Ein helpdesk vil ha identiteten til sesjonen for å kunne matche ein sak.
Desse svara peikar på ulike hendingar, og ingen einskild regel tilfredsstiller alle tre. Viss handlinga til mottakaren er «ring brukaren», er autentisering nok. Viss handlinga er «frigjer ein lisens» eller «stadfest at tunnelen bar trafikk», duger berre etablering eller accounting Start. Viss handlinga er «fakturer tida», treng du Stop-postar i staden for ei innlogging.
Skriv svaret som éi setning før du konfigurerer noko. «Denne e-posten fortel vaktande ingeniør at konto X opna ein tunnel frå nettverk Y på tidspunkt Z, slik at dei kan sjekke om vedlikehaldsvindauget vart brukt.» Viss du ikkje kan fylle kvart felt, er utløysaren ikkje vald enno.
Tilpass hendinga til påstanden du legg fram
| 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 |
Tabellen skjuler ein avhengigskap: kvar rad er berre påliteleg viss gatewayen sender henne ut påliteleg og innsamlar din behaldar feltet du treng. Les hendingsdefinisjonen for nøyaktig den versjonen du køyrer, fordi namnet «sesjon etablert» endrar seg mellom versjonar, og tydinga endrar seg oftare enn namnet. Når ein definisjon er vag, be om eit sesjonsopptak i staden for å gjette frå etiketten.
Å handsame ein Access-Accept som fullføringa av alt som følgjer, er den vanlegaste feilen. Det er ein dom over innloggingsdata, ikkje ein sesjon. Spegel-feilen er å lese eit policytreff som prov på autorisasjon, når ein regel kan treffe og neste steg framleis kan feile.
Éin sesjon, eitt varsel
Éin konto, fleire einingar, gjenutsendingar og gjenoppkoplingar: éin e-post per hending vil vere feil i begge retningar, duplisere éin sesjon medan han deler ein annan. Nøkle varselet på gatewayen pluss ein sesjons-ID, og handsam kontonamnet som eit attributt i staden for nøkkelen. Ein brukar med laptop og telefon kan ha to tunnelar samstundes, og begge fortener si eiga linje.
Gjenutsende rekneskapspostar er normale, så fjern duplikat på sesjons-ID og tidsstempel før du gjev ut meldinga. Påfølgjande sesjonar frå same eining bør haldast åtskilde, og ei gjenoppkopling i eit vedlikehaldsvindauge bør halde fram som synleg i staden for å falle saman med den førre. Viss innsamlar din skriv om tidsstempel ved inntak, fjern duplikat på felta i den opphavlege posten, ikkje dei lagra.
Ein manglande Stop-post er usikkerheit, ikkje ein permanent sesjon. Omstart av gateway, utfall i innsamlar og UDP-tap etterlèt alle hol, så varselet treng ein avstemmingsveg som spør den levande sesjonstabellen før nokon konkluderer med at ein tunnel framleis er oppe.
Hald revisjon og varsel åtskilde
Revisjonsstraumen og varselstraumen har ulike oppgåver. Ta vare på råpostane, inkludert konto, gateway, sesjons-ID, tidsstempel og årsak til avslutning, sjølv når rutine-e-postar blir grupperte, undertrykte eller sende til ei lita vaktliste. Ein alvorlegheitsterskel er eit leveringsfilter, ikkje eit val av livssyklushendinga du meinte å kunngjere.
Send den minste konteksten mottakaren treng for å finne den verna posten. Kontonamn, interne adresser og sesjonsdetaljar er sensitive, og ein e-post som blir vidaresend godt, er ein e-post som lek godt.
Prov det deretter ende til ende. Køyr ei vanleg innlogging og utlogging, ei gjenoppkopling, to samtidige sesjonar og ein tvinga leveringsfeil, og spor éi hending frå gatewayen gjennom innsamlar til den leverte meldinga. Viss e-posten kjem utan sesjons-ID, er kontrakten ufullstendig. Viss to e-postar skildrar éin sesjon, er korrelasjonen broten. Ingen av problema viser seg når det einaste du testar er at e-postlevering fungerer.