RADIUS-kontado kontraŭ sukcesa ensaluto: kion pruvas ĉiu

Du demandoj miksiĝas en ĉiu diskuto pri VPN-fakturado: ĉu ĉi tiu uzanto rajtis konektiĝi, kaj kion ĝi fakte faris. La unuan respondas aŭtentikigo. La dua postulas kontadajn rikordojn, kiuj komenciĝas, ĝisdatiĝas kaj finiĝas. Sukcesa ensaluto pruvas la unuan kaj diras nenion pri la dua, tial funkcianta RADIUS-aŭtentikigo ankoraŭ povas produkti malplenan uzadan raporton.

Du malsamaj demandoj

Aŭtentikigo decidas, ĉu konekto rajtas komenciĝi, kaj ĝi liveras verdikton plus atributojn kiel adresaron aŭ grupon. Kontado registras la servon, kiu sekvis, kiel sinsekvon de eventoj ligitaj al unu sesio.

Ili vojaĝas laŭ la sama protokolo kaj kutime al la sama servilo, kaj ĝuste tial homoj supozas, ke unu implicas la alian.

Nenio en alirpeto portas la daŭron de la sesio, kaj nenio en rikordo Stop redecidas, ĉu la uzanto devus esti akceptita. Trakti ilin kiel apartajn kontraktojn igas la integriĝan laboron videbla: unu vojo bezonas decidon, la alia bezonas vivciklon kun komenco, mezo kaj fino.

Kion donas al vi la tri rikordaj tipoj

Rikordo Start malfermas sesion, Interim-Update raportas aktivecon dum ĝi estas malfermita, kaj Stop fermas ĝin. Ĉiuj tri portas sesian identigilon, por ke la ricevanto povu rilatigi ilin al unu serva evento.

Tiu identigilo estas la sola fidinda ligo inter ili, ĉar la sama uzantnomo povas teni plurajn sesiojn sinsekve aŭ paralele. Projektu vian konservadon ĉirkaŭ ĝi, ne ĉirkaŭ la konta nomo.

Konfirmi rikordon estas aparta afero de bone konservi ĝin. La kontada specifo malpermesas la konfirmon, kiam la rikordo ne povis esti skribita, do respondo ja diras al vi, ke la ricevanto akceptis respondecon. Ĝi ne diras al vi, ke la posta raporta tasko, la panelo aŭ la faktura eksporto konsumis ĝin ĝuste.

Kial la uzantnomo ne estas la sesio

Unu persono konektiĝas matene de tekkomputilo kaj posttagmeze de telefono, kaj ambaŭ sesioj portas la saman kontan nomon. Start, kiu alvenas sen sia kongrua Stop, ne povas esti fermita serĉante la nomon kaj elektante la plej malnovan malfermitan vicon.

Tiu fuŝsolvo estas kiel uzadaj raportoj akiras neeblajn daŭrojn.

Tenu la identecon de la retpollingva servilo apud la sesia identigilo, ĉar du serviloj povas atribui la saman valoron en malsamaj kuntekstoj, kaj kunfandi nur laŭ la identigilo povas kunigi nerilatajn sesiojn. Kiam sesio finiĝas malglate, la reamortiza politiko devas decidi, kiel fermi ĝin, kaj tiu decido apartenas al la dezajno, ne al mana datumbaza redakto farita unufoje monate.

Kie PAM taŭgas kaj kie ne

La aŭtentikiga kromaĵo de OpenVPN vokas la aŭtentikigajn kaj kontoadministrajn stadiojn de PAM. La konto-stadio kontrolas taŭgecon; ĝia nomo ne signifas uzadan kontadon, kaj la kromaĵo ne regas la sesiajn malfermajn kaj fermajn hokojn de PAM.

Kelkaj PAM RADIUS-moduloj povas sendi kontadajn rikordojn per tiuj sesiaj hokoj, kaj tio funkcias nur kiam la aplikaĵo efektive vokas ilin.

Aldoni tian modulon al aŭtentikiga stako do ne kreas malkonektajn eventojn. Se vi bezonas la plenan vivciklon, elektu integriĝon, kiu posedas ĝin: kromaĵon aŭ subtenatan konstruadon, kiu elsendas Start, Interim-Update kaj Stop dum la konekto ŝanĝas staton. Kontrolu ĝian prizorgan staton kaj ĝian dokumentitan konduton, kiam la ricevanto ne disponeblas, ĉar kromaĵo, kiu silente forĵetas rikordojn, aspektas idente al unu, kiu neniam sendis ilin. La kontada specifo difinas la rikordan semantikon, kiun la integriĝo devas respekti.

Akcepta kuro, kiu pruvas la kontrakton

Testu normalan konekton kaj malkonekton, poste rekonekton sub la sama konto, poste klienton, kiu malaperas sen malkonekti.

Spuru unu sesian identigilon de generado tra konfirmo ĝis konservado, kaj kontrolu la direkton, unuojn kaj interfacon de la nombriloj. Senetikedan bajtokalkulon ne eblas poste revizii.

Fine, konfirmu, ke sesio, kiun la servilo devis haltigi pro tempolimo, estas reprezentita tiel, kiel la raporto komprenas. Kontrakto, kiu kovras nur glatajn malkonektojn, estas kontrakto, kiu malsukcesas en la tagoj, kiam vi plej bezonas ĝin.