RADIUS अकाउंटिंग विरुद्ध यशस्वी लॉगिन: प्रत्येक काय सिद्ध करते

प्रत्येक VPN बिलिंग चर्चेत दोन प्रश्न एकमेकांत मिसळतात: या वापरकर्त्याला कनेक्ट होण्याची परवानगी होती का, आणि त्याने प्रत्यक्षात काय केले. पहिल्याचे उत्तर प्रमाणीकरण देते. दुसऱ्यासाठी सुरू होणाऱ्या, अद्ययावत होणाऱ्या आणि संपणाऱ्या अकाउंटिंग नोंदी लागतात. यशस्वी लॉगिन पहिले सिद्ध करते आणि दुसऱ्याबद्दल काहीच सांगत नाही, म्हणून कार्यरत RADIUS प्रमाणीकरण सेटअप तरीही रिकामा वापर अहवाल तयार करू शकतो.

दोन वेगळे प्रश्न

प्रमाणीकरण ठरवते की कनेक्शन सुरू होऊ शकते का, आणि ते पत्ता पूल किंवा गट यांसारख्या गुणधर्मांसह निर्णय परत देते. अकाउंटिंग त्यानंतर आलेल्या सेवेची एका सत्राशी जोडलेल्या घटनांचा क्रम म्हणून नोंद करते.

ते एकाच प्रोटोकॉलवरून आणि सहसा एकाच सर्व्हरकडे जातात, आणि म्हणूनच लोक गृहीत धरतात की एकाचा अर्थ दुसरे असा होतो.

प्रवेश विनंतीत सत्राचा कालावधी काहीच नसतो, आणि Stop नोंदीत वापरकर्त्याला प्रवेश द्यायला हवा होता का हे पुन्हा ठरत नाही. त्यांना वेगळे करार मानल्यास एकत्रीकरणाचे काम दिसते: एका मार्गाला निर्णय हवा, दुसऱ्याला सुरुवात, मध्य आणि शेवट असलेले जीवनचक्र हवे.

तीन नोंद प्रकार काय देतात

Start नोंद सत्र उघडते, Interim-Update ते उघडे असताना क्रियाकलाप कळवते, आणि Stop ते बंद करते. तिन्ही सत्र ओळखकर्ता बाळगतात जेणेकरून प्राप्तकर्ता त्यांना एका सेवा घटनेशी जोडू शकेल.

तीच ओळख त्यांच्यातील एकमेव विश्वासार्ह दुवा आहे, कारण एकाच वापरकर्तानावावर सलग किंवा समांतर अनेक सत्रे असू शकतात. साठवण खात्याच्या नावाभोवती नाही, तिच्याभोवती रचा.

नोंद स्वीकारणे आणि ती चांगल्या प्रकारे साठवणे वेगळ्या गोष्टी आहेत. नोंद लिहिता आली नाही तेव्हा अकाउंटिंग तपशील स्वीकृतीस प्रतिबंध करतो, म्हणून प्रतिसाद तुम्हाला सांगतो की प्राप्तकर्त्याने जबाबदारी घेतली. पण नंतरचे अहवाल काम, डॅशबोर्ड किंवा बिलिंग निर्यात यांनी ती योग्यरित्या वापरली हे सांगत नाही.

वापरकर्तानाव सत्र का नाही

एक व्यक्ती सकाळी लॅपटॉपवरून आणि दुपारी फोनवरून कनेक्ट होते, आणि दोन्ही सत्रे एकच खाते नाव बाळगतात. जुळणारी Stop नसलेली Start, नाव शोधून सर्वात जुनी उघडी ओळ निवडून बंद करता येत नाही.

हाच शॉर्टकट वापर अहवालांना अशक्य कालावधी मिळवून देतो.

नेटवर्क प्रवेश सर्व्हरची ओळख सत्र ओळखकर्त्याजवळ ठेवा, कारण दोन सर्व्हर वेगवेगळ्या संदर्भांत एकच मूल्य देऊ शकतात आणि केवळ ओळखकर्त्यावर विलीन केल्यास असंबंधित सत्रे जोडली जाऊ शकतात. सत्र अनियमितपणे संपल्यास, समेट धोरणाने ते कसे बंद करायचे हे ठरवायला हवे, आणि तो निर्णय रचनेत असतो, महिन्यातून एकदा केल्या जाणाऱ्या हाताने डेटाबेस संपादनात नाही.

PAM कुठे बसते आणि कुठे नाही

OpenVPN चे प्रमाणीकरण प्लगइन PAM चे प्रमाणीकरण आणि खाते व्यवस्थापन टप्पे कॉल करते. खाते टप्पा पात्रता तपासतो; त्याच्या नावाचा अर्थ वापर अकाउंटिंग नाही, आणि प्लगइन PAM चे सत्र उघडण्याचे व बंद करण्याचे हुक चालवत नाही.

काही PAM RADIUS मॉड्यूल त्या सत्र हुकांद्वारे अकाउंटिंग नोंदी पाठवू शकतात, आणि ते तेव्हाच चालते जेव्हा अनुप्रयोग त्यांना खरोखर कॉल करतो.

म्हणून असे मॉड्यूल प्रमाणीकरण स्टॅकमध्ये जोडल्याने डिस्कनेक्ट घटना तयार होत नाहीत. तुम्हाला पूर्ण जीवनचक्र हवे असल्यास त्याचे मालकीचे एकत्रीकरण निवडा: कनेक्शनची स्थिती बदलताना Start, Interim-Update आणि Stop उत्सर्जित करणारे प्लगइन किंवा समर्थित बिल्ड. त्याची देखभाल स्थिती आणि प्राप्तकर्ता उपलब्ध नसताना त्याचे नोंदवलेले वर्तन तपासा, कारण नोंदी गुपचूप टाकून देणारे प्लगइन त्या कधीच न पाठवणाऱ्यासारखेच दिसते. अकाउंटिंग तपशील एकत्रीकरणाने पाळावयाची नोंदींची अर्थशास्त्र व्याख्या करतो.

करार सिद्ध करणारी स्वीकृती चाचणी

सामान्य कनेक्ट आणि डिस्कनेक्ट तपासा, नंतर त्याच खात्याखाली पुन्हा कनेक्ट, नंतर डिस्कनेक्ट न करता गायब होणारा क्लायंट.

एक सत्र ओळखकर्ता निर्मितीपासून स्वीकृतीतून साठवणीपर्यंत पुढे न्या, आणि काउंटरची दिशा, एकके आणि इंटरफेस तपासा. लेबल नसलेली बाइट गणना नंतर ऑडिट करणे अशक्य आहे.

शेवटी, सर्व्हरला कालमर्यादेमुळे बंद करावे लागलेले सत्र अहवाल समजतो त्या स्वरूपात दर्शवले आहे याची खात्री करा. केवळ सभ्य डिस्कनेक्ट व्यापणारा करार असा करार आहे जो तुम्हाला सर्वात जास्त गरज असेल त्या दिवशी अपयशी ठरतो.