VPN-ensalutaj avertoj: kiun eventon ili efektive devus ekigi?
Sukcesa aŭtentigo, establita tunelo kaj RADIUS accounting Start estas tri malsamaj asertoj. Elektu tiun, pri kiu via ricevanto povas agi, kaj poste kunligu ilin.
Sukcesa aŭtentigo, establita tunelo kaj RADIUS accounting Start estas tri malsamaj asertoj, kaj ensaluta retpoŝto signifas ion nur post kiam vi elektas unu el ili. Plej multaj dezajnoj de VPN-avertoj miksas ĉiujn tri kaj produktas retpoŝtan keston, kiun neniu fidas. La decido dependas de tio, kiu legas la averton kaj kion li povas fari en la sekvaj kvin minutoj. Se vi eraras pri tio, la averto fariĝas bruo, kiu kaŝas la solan eventon, kiun vi bezonis.
Tri demandoj decidas la ekigilon
Demandu, kiu ricevos ĝin, kion li faros, kaj kiom rapide la ago devas okazi. Sekureca teamo, kiu observas misuzon de legitimiloj, volas ŝablonon malsukceso-poste-sukceso de unu konto ene de minutoj. Operacia teamo, kiu observas kapaciton, volas daŭron de sesio kaj kialojn de malkonekto, ne ensalutojn. Helpodesko volas la identecon de la sesio, por ke ĝi povu kongruigi bileton.
Tiuj respondoj montras al malsamaj eventoj, kaj neniu unuopa regulo kontentigas ĉiujn tri. Se la ago de la ricevanto estas «voku la uzanton», aŭtentigo sufiĉas. Se la ago estas «liberigu permesilon» aŭ «kontrolu ĉu la tunelo portis trafikon», nur establo aŭ accounting Start taŭgos. Se la ago estas «fakturu la tempon», vi bezonas Stop-rikordojn anstataŭ ensaluto.
Skribu la respondon kiel unu frazon antaŭ ol agordi ion ajn. «Ĉi tiu retpoŝto diras al la deĵora inĝeniero, ke konto X malfermis tunelon el reto Y je tempo Z, por ke li povu kontroli, ĉu la bontenada fenestro estis uzita.» Se vi ne povas plenigi ĉiun kampon, la ekigilo ankoraŭ ne estas elektita.
Kongruigu la eventon kun la aserto, kiun vi faras
| 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 |
La tabelo kaŝas dependecon: ĉiu vico estas fidinda nur se la enirejo elsendas ĝin fidinde kaj via kolektanto konservas la kampon, kiun vi bezonas. Legu la difinon de la evento por la preciza versio, kiun vi funkciigas, ĉar la nomo «sesio establita» ŝanĝiĝas inter versioj, kaj la signifo ŝanĝiĝas pli ofte ol la nomo. Kiam difino estas malklara, petu sesian kaptaĵon anstataŭ diveni laŭ la etikedo.
Trakti Access-Accept kiel la finiĝon de ĉio post ĝi estas la plej ofta eraro. Ĝi estas verdikto pri legitimiloj, ne sesio. La spegula eraro estas legi politikan kongruon kiel pruvon de rajtigo, kiam regulo povas kongrui kaj la sekva paŝo tamen povas malsukcesi.
Unu sesio, unu sciigo
Unu konto, pluraj aparatoj, reelsendoj kaj rekonektoj: retpoŝto por ĉiu evento estos malĝusta en ambaŭ direktoj, duobligante unu sesion dum ĝi disigas alian. Ŝlosilu la sciigon per la enirejo plus sesia identigilo, kaj traktu la kontan nomon kiel atributon anstataŭ la ŝlosilo. Uzanto kun tekkomputilo kaj telefono povas teni du tunelojn samtempe, kaj ambaŭ meritas sian propran linion.
Reelsenditaj kontadaj rikordoj estas normalaj, do forigu duplikatojn laŭ la sesia identigilo kaj la tempstampo antaŭ ol montri la mesaĝon. Sinsekvaj sesioj de la sama aparato devus resti apartaj, kaj rekonekto dum bontenada fenestro devus resti videbla anstataŭ kolapsi en la antaŭan. Se via kolektanto reverkite tempstampojn dum enigo, forigu duplikatojn laŭ la kampoj de la originala rikordo, ne la konservitaj.
Mankanta Stop-rikordo estas necerteco, ne konstanta sesio. Restartoj de la enirejo, paneoj de la kolektanto kaj perdo de UDP ĉiuj lasas breĉojn, do la averto bezonas repacigan vojon, kiu demandas la tabelon de vivantaj sesioj antaŭ ol iu konkludas, ke tunelo ankoraŭ funkcias.
Tenu aŭdon kaj sciigon aparte
La aŭda fluo kaj la averta fluo havas malsamajn taskojn. Konservu la krudajn rikordojn, inkluzive konton, enirejon, sesian identigilon, tempstampojn kaj kialon de finiĝo, eĉ kiam rutinaj retpoŝtoj estas grupigitaj, subpremitaj aŭ senditaj al malgranda deĵora listo. Sojlo de graveco estas livera filtro, ne elekto de la vivekla evento, kiun vi volis anonci.
Sendu la minimuman kuntekston, kiun la ricevanto bezonas por trovi la protektitan rikordon. Kontaj nomoj, internaj adresoj kaj detaloj de sesio estas sentemaj, kaj retpoŝto, kiu bone plusendiĝas, estas retpoŝto, kiu bone likas.
Poste pruvu ĝin de komenco ĝis fino. Rulu normalan ensaluton kaj elsaluton, rekonekton, du samtempajn sesiojn kaj devigitan liveran malsukceson, kaj spuru unu eventon de la enirejo tra la kolektanto ĝis la liverita mesaĝo. Se la retpoŝto alvenas sen sesia identigilo, la kontrakto estas nekompleta. Se du retpoŝtoj priskribas unu sesion, la kunligo estas rompita. Neniu el la du problemoj montriĝas, kiam la sola afero, kiun vi testas, estas ke retpoŝta liverado funkcias.