Accounting ng RADIUS kumpara sa matagumpay na pag-login: ano ang pinatutunayan ng bawat isa
Sinasabi ng Access-Accept na maaaring magsimula ang isang session. Sinasabi ng mga record na Start, Interim-Update at Stop ang nangyari pagkatapos; pinag-uugnay sila ng identifier ng session.
Dalawang tanong ang naghahalo sa bawat usapan tungkol sa pagsingil ng VPN: pinayagan bang kumonekta ang user na ito, at ano ang talagang ginawa niya. Ang una ay sinasagot ng authentication. Ang pangalawa ay nangangailangan ng mga record ng accounting na nagsisimula, nag-a-update at nagtatapos. Ang matagumpay na pag-login ay nagpapatunay sa una at walang sinasabi tungkol sa pangalawa, kaya ang gumaganang setup ng authentication ng RADIUS ay makakagawa pa rin ng walang laman na ulat ng paggamit.
Dalawang magkaibang tanong
Nagpapasya ang authentication kung maaaring magsimula ang koneksyon, at nagbabalik ito ng hatol kasama ng mga attribute tulad ng pool ng address o grupo. Itinatala ng accounting ang serbisyong sumunod, bilang pagkakasunod-sunod ng mga pangyayaring nakatali sa isang session.
Dumadaan sila sa parehong protocol at karaniwang patungo sa parehong server, at iyon ang dahilan kung bakit inaakala ng mga tao na ang isa ay nangangahulugan ng isa pa.
Wala sa isang access request ang nagdadala ng tagal ng session, at wala sa isang Stop record ang muling nagpapasya kung dapat bang tinanggap ang user. Kapag tinatrato sila bilang magkahiwalay na kontrata, nagiging nakikita ang gawain ng integrasyon: kailangan ng isang landas ng desisyon, at ng isa pa ng lifecycle na may simula, gitna at wakas.
Ano ang ibinibigay ng tatlong uri ng record
Binubuksan ng Start record ang isang session, iniuulat ng Interim-Update ang aktibidad habang bukas ito, at isinasara ito ng Stop. Tatlo silang may identifier ng session upang maugnay ito ng tatanggap sa isang pangyayari ng serbisyo.
Ang identifier na iyon ang tanging maaasahang ugnayan sa pagitan nila, dahil ang parehong username ay maaaring may maraming session na sunod-sunod o sabay. Idisenyo ang imbakan sa paligid nito at hindi sa paligid ng pangalan ng account.
Ang pag-acknowledge ng record ay iba sa pag-iimbak nito nang maayos. Ipinagbabawal ng detalye ng accounting ang pag-acknowledge kapag hindi naisulat ang record, kaya sinasabi nga ng tugon na inako ng tatanggap ang responsibilidad. Hindi nito sinasabi na ginamit ito nang tama ng susunod na gawain sa pag-uulat, ng dashboard o ng export ng pagsingil.
Bakit ang username ay hindi ang session
Isang tao ang kumokonekta mula sa laptop sa umaga at sa telepono sa hapon, at parehong nagdadala ang dalawang session ng parehong pangalan ng account. Ang Start na dumarating nang walang katambal na Stop ay hindi maisasara sa pamamagitan ng paghahanap ng pangalan at pagpili ng pinakamatandang bukas na hilera.
Ang shortcut na iyon ang paraan kung paano nagkakaroon ng imposibleng tagal ang mga ulat ng paggamit.
Itago ang pagkakakilanlan ng network access server sa tabi ng identifier ng session, dahil maaaring magtalaga ang dalawang server ng parehong halaga sa magkaibang konteksto at ang pagsasama na nakabatay lamang sa identifier ay maaaring mag-ugnay ng mga session na walang kaugnayan. Kapag natapos ang isang session nang hindi maayos, kailangang magpasya ng patakaran sa pagkakasundo kung paano ito isasara, at ang desisyong iyon ay bahagi ng disenyo at hindi ng manu-manong pag-edit ng database isang beses sa isang buwan.
Saan bagay ang PAM at saan hindi
Tinatawag ng authentication plugin ng OpenVPN ang mga yugto ng authentication at pamamahala ng account ng PAM. Sinusuri ng yugto ng account ang pagiging karapat-dapat; ang pangalan nito ay hindi nangangahulugang accounting ng paggamit, at hindi pinapatakbo ng plugin ang mga hook sa pagbukas at pagsasara ng session ng PAM.
Ang ilang module ng PAM RADIUS ay makakapagpadala ng mga record ng accounting sa pamamagitan ng mga hook ng session na iyon, at gumagana lamang iyon kapag tunay na tinatawag sila ng application.
Kaya ang pagdaragdag ng ganitong module sa isang stack ng authentication ay hindi lumilikha ng mga pangyayari ng paghihiwalay. Kung kailangan mo ang buong lifecycle, pumili ng integrasyong nagmamay-ari nito: isang plugin o sinusuportahang build na naglalabas ng Start, Interim-Update at Stop habang nagbabago ang estado ng koneksyon. Suriin ang katayuan ng maintenance nito at ang dokumentadong pag-uugali kapag hindi available ang tatanggap, dahil ang plugin na tahimik na nagtatapon ng mga record ay kamukhang-kamukha ng isang hindi kailanman nagpadala ng mga iyon. Detalye ng accounting ang nagtatakda ng semantika ng mga record na dapat igalang ng integrasyon.
Isang acceptance run na nagpapatunay sa kontrata
Subukan ang normal na koneksyon at paghihiwalay, pagkatapos ang muling pagkonekta sa ilalim ng parehong account, pagkatapos ang isang client na nawawala nang hindi humihiwalay.
Sundan ang isang identifier ng session mula sa paggawa hanggang sa pag-acknowledge at imbakan, at suriin ang direksyon, mga yunit at interface ng mga counter. Ang bilang ng byte na walang label ay imposibleng i-audit mamaya.
Sa huli, tiyakin na ang session na kinailangang isara ng server dahil sa timeout ay kinakatawan sa paraang nauunawaan ng ulat. Ang kontratang sumasaklaw lamang sa maayos na paghihiwalay ay kontratang nabibigo sa mga araw na pinaka-kailangan mo ito.