RADIUS એકાઉન્ટિંગ વિરુદ્ધ સફળ લોગિન: દરેક શું સાબિત કરે છે

દરેક VPN બિલિંગ ચર્ચામાં બે પ્રશ્નો ભેળવાઈ જાય છે: આ વપરાશકર્તાને કનેક્ટ થવાની પરવાનગી હતી કે નહીં, અને તેણે ખરેખર શું કર્યું. પ્રથમનો જવાબ પ્રમાણીકરણ આપે છે. બીજા માટે એકાઉન્ટિંગ રેકોર્ડ જરૂરી છે જે શરૂ થાય, અપડેટ થાય અને પૂરા થાય. સફળ લોગિન પ્રથમ સાબિત કરે છે અને બીજા વિશે કંઈ કહેતું નથી, તેથી કાર્યરત RADIUS પ્રમાણીકરણ સેટઅપ હજી પણ ખાલી વપરાશ અહેવાલ બનાવી શકે છે.

બે અલગ પ્રશ્નો

પ્રમાણીકરણ નક્કી કરે છે કે કનેક્શન શરૂ થઈ શકે કે નહીં, અને તે સરનામાં પૂલ અથવા જૂથ જેવા એટ્રિબ્યુટ સાથે ચુકાદો પરત આપે છે. એકાઉન્ટિંગ પછીની સેવા નોંધે છે, એક સેશન સાથે જોડાયેલી ઘટનાઓના ક્રમ તરીકે.

તેઓ એક જ પ્રોટોકોલ પર અને સામાન્ય રીતે એક જ સર્વર પર જાય છે, અને તેથી જ લોકો ધારે છે કે એક બીજાનો અર્થ છે.

એક્સેસ વિનંતીમાં કંઈ પણ સેશનનો સમયગાળો રાખતું નથી, અને Stop રેકોર્ડમાં કંઈ પણ વપરાશકર્તાને દાખલ કરવો જોઈતો હતો કે નહીં તે ફરી નક્કી કરતું નથી. તેમને અલગ કરાર તરીકે ગણવાથી ઇન્ટિગ્રેશન કાર્ય દૃશ્યમાન થાય છે: એક માર્ગને નિર્ણયની જરૂર છે, બીજાને શરૂઆત, મધ્ય અને અંત સાથેના જીવનચક્રની.

ત્રણ રેકોર્ડ પ્રકાર તમને શું આપે છે

Start રેકોર્ડ સેશન ખોલે છે, Interim-Update ખુલ્લું હોય ત્યારે પ્રવૃત્તિ જણાવે છે, અને Stop તેને બંધ કરે છે. ત્રણેય સેશન ઓળખકર્તા રાખે છે જેથી પ્રાપ્તકર્તા તેમને એક સેવા ઘટના સાથે જોડી શકે.

તે ઓળખકર્તા તેમની વચ્ચેની એકમાત્ર વિશ્વસનીય કડી છે, કારણ કે એક જ વપરાશકર્તાનામ પર ક્રમમાં અથવા સમાંતરમાં ઘણાં સેશન હોઈ શકે છે. સંગ્રહને ખાતાના નામની આસપાસ નહીં, તેની આસપાસ ડિઝાઇન કરો.

રેકોર્ડ સ્વીકારવો તેને સારી રીતે સંગ્રહવાથી અલગ બાબત છે. એકાઉન્ટિંગ સ્પેસિફિકેશન સ્વીકૃતિ પર પ્રતિબંધ મૂકે છે જ્યારે રેકોર્ડ લખી શકાયો ન હોય, તેથી પ્રતિભાવ તમને કહે છે કે પ્રાપ્તકર્તાએ જવાબદારી લીધી. તે કહેતું નથી કે પછીનું રિપોર્ટિંગ કાર્ય, ડેશબોર્ડ અથવા બિલિંગ નિકાસે તેનો યોગ્ય ઉપયોગ કર્યો.

કેમ વપરાશકર્તાનામ એ સેશન નથી

એક વ્યક્તિ સવારે લેપટોપથી અને બપોરે ફોનથી કનેક્ટ થાય છે, અને બંને સેશન એક જ ખાતાનું નામ ધરાવે છે. મેળ ખાતા Stop વિના આવતું Start, નામ શોધીને સૌથી જૂની ખુલ્લી પંક્તિ પસંદ કરીને બંધ કરી શકાતું નથી.

એ શોર્ટકટ એ છે કે કેવી રીતે વપરાશ અહેવાલો અશક્ય સમયગાળા મેળવે છે.

નેટવર્ક એક્સેસ સર્વરની ઓળખ સેશન ઓળખકર્તાની બાજુમાં રાખો, કારણ કે બે સર્વર અલગ સંદર્ભોમાં એક જ મૂલ્ય સોંપી શકે છે અને ફક્ત ઓળખકર્તા પર મર્જ કરવાથી અસંબંધિત સેશન જોડાઈ શકે છે. જ્યારે સેશન અસભ્ય રીતે પૂરું થાય, ત્યારે સમાધાન નીતિએ નક્કી કરવું પડે છે કે તેને કેવી રીતે બંધ કરવું, અને એ નિર્ણય ડિઝાઇનમાં હોવો જોઈએ, મહિનામાં એક વાર કરવામાં આવતા જાતે ડેટાબેઝ સંપાદનમાં નહીં.

PAM ક્યાં બંધ બેસે છે અને ક્યાં નહીં

OpenVPNનું પ્રમાણીકરણ પ્લગઇન PAMના પ્રમાણીકરણ અને ખાતા-વ્યવસ્થાપન તબક્કા બોલાવે છે. ખાતા તબક્કો પાત્રતા તપાસે છે; તેના નામનો અર્થ વપરાશ એકાઉન્ટિંગ નથી, અને પ્લગઇન PAMના સેશન ખોલવા અને બંધ કરવાના હૂક ચલાવતું નથી.

કેટલાક PAM RADIUS મોડ્યુલ તે સેશન હૂક દ્વારા એકાઉન્ટિંગ રેકોર્ડ મોકલી શકે છે, અને તે ત્યારે જ કામ કરે છે જ્યારે એપ્લિકેશન ખરેખર તેમને બોલાવે.

તેથી પ્રમાણીકરણ સ્ટેકમાં આવું મોડ્યુલ ઉમેરવાથી ડિસ્કનેક્ટ ઘટનાઓ ઊભી થતી નથી. જો તમને પૂરું જીવનચક્ર જોઈએ, તો એવું ઇન્ટિગ્રેશન પસંદ કરો જે તેનું ધારક હોય: પ્લગઇન અથવા સમર્થિત બિલ્ડ જે કનેક્શનની સ્થિતિ બદલાતાં Start, Interim-Update અને Stop ઉત્સર્જિત કરે. તેની જાળવણી સ્થિતિ અને પ્રાપ્તકર્તા અનુપલબ્ધ હોય ત્યારેનું દસ્તાવેજીકૃત વર્તન તપાસો, કારણ કે રેકોર્ડ ચૂપચાપ પડતા મૂકતું પ્લગઇન તેના જેવું જ દેખાય છે જેણે તેમને કદી મોકલ્યા ન હોય. એકાઉન્ટિંગ સ્પેસિફિકેશન તે રેકોર્ડની અર્થશાસ્ત્ર વ્યાખ્યાયિત કરે છે જેનું ઇન્ટિગ્રેશનને પાલન કરવું પડે.

કરાર સાબિત કરતી સ્વીકૃતિ પરીક્ષા

સામાન્ય કનેક્શન અને ડિસ્કનેક્શનની પરીક્ષા કરો, પછી એક જ ખાતા હેઠળ ફરી કનેક્શન, પછી ડિસ્કનેક્ટ ન થઈને અદ્રશ્ય થતું ક્લાયન્ટ.

એક સેશન ઓળખકર્તાને ઉત્પાદનથી સ્વીકૃતિ થઈને સંગ્રહ સુધી અનુસરો, અને કાઉન્ટરોની દિશા, એકમો અને ઇન્ટરફેસ તપાસો. લેબલ વગરની બાઇટ ગણતરી પછી ઓડિટ કરવી અશક્ય છે.

અંતે ખાતરી કરો કે સર્વરને સમયસીમા પૂરી કરવી પડેલી સેશન અહેવાલ સમજે તે રીતે રજૂ થઈ છે. જે કરાર ફક્ત શિષ્ટ ડિસ્કનેક્શન આવરી લે છે તે એવો કરાર છે જે તમને સૌથી વધુ જરૂર હોય તેવા દિવસોમાં નિષ્ફળ જાય છે.