RADIUS अकाउंटिंग बनाम सफल लॉगिन: हर एक क्या साबित करता है

हर VPN बिलिंग चर्चा में दो सवाल आपस में मिल जाते हैं: क्या इस उपयोगकर्ता को कनेक्ट करने की अनुमति थी, और उसने वास्तव में क्या किया। पहले का जवाब प्रमाणीकरण देता है। दूसरे के लिए ऐसे अकाउंटिंग रिकॉर्ड चाहिए जो शुरू हों, अपडेट हों और खत्म हों। सफल लॉगिन पहले को साबित करता है और दूसरे के बारे में कुछ नहीं कहता, इसलिए काम कर रहा RADIUS प्रमाणीकरण सेटअप फिर भी खाली उपयोग रिपोर्ट बना सकता है।

दो अलग सवाल

प्रमाणीकरण तय करता है कि कनेक्शन शुरू हो सकता है या नहीं, और यह पता पूल या समूह जैसे एट्रिब्यूट के साथ फैसला लौटाता है। अकाउंटिंग उस सेवा को दर्ज करती है जो उसके बाद आई, एक सत्र से जुड़ी घटनाओं के क्रम के रूप में।

वे एक ही प्रोटोकॉल पर और आमतौर पर एक ही सर्वर तक जाते हैं, और ठीक इसी कारण लोग मान लेते हैं कि एक दूसरे का अर्थ है।

एक्सेस अनुरोध में कुछ भी सत्र की अवधि नहीं रखता, और Stop रिकॉर्ड में कुछ भी यह दोबारा तय नहीं करता कि उपयोगकर्ता को स्वीकार किया जाना चाहिए था या नहीं। इन्हें अलग अनुबंध मानने से इंटीग्रेशन का काम दिखाई देता है: एक रास्ते को फैसला चाहिए, दूसरे को शुरुआत, मध्य और अंत वाला जीवनचक्र चाहिए।

तीनों रिकॉर्ड प्रकार आपको क्या देते हैं

Start रिकॉर्ड सत्र खोलता है, Interim-Update खुला रहने के दौरान गतिविधि बताता है, और Stop उसे बंद करता है। तीनों सत्र पहचानकर्ता रखते हैं ताकि प्राप्तकर्ता उन्हें एक ही सेवा घटना से जोड़ सके।

वही पहचानकर्ता उनके बीच एकमात्र भरोसेमंद कड़ी है, क्योंकि एक ही उपयोगकर्तानाम के पास क्रम में या समानांतर में कई सत्र हो सकते हैं। भंडारण को खाता नाम के बजाय उसी के इर्द-गिर्द डिज़ाइन करें।

रिकॉर्ड स्वीकार करना उसे अच्छी तरह संग्रहीत करने से अलग बात है। अकाउंटिंग विनिर्देश स्वीकृति पर रोक लगाता है जब रिकॉर्ड लिखा नहीं जा सका, इसलिए प्रतिक्रिया आपको बताती है कि प्राप्तकर्ता ने ज़िम्मेदारी ली। यह नहीं बताती कि बाद वाला रिपोर्टिंग कार्य, डैशबोर्ड या बिलिंग निर्यात उसे सही ढंग से इस्तेमाल कर पाए।

क्यों उपयोगकर्तानाम सत्र नहीं है

एक व्यक्ति सुबह लैपटॉप से और दोपहर में फोन से कनेक्ट होता है, और दोनों सत्र एक ही खाता नाम रखते हैं। मेल खाते Stop के बिना आया Start, नाम खोजकर सबसे पुरानी खुली पंक्ति चुनकर बंद नहीं किया जा सकता।

यही शॉर्टकट है जिससे उपयोग रिपोर्टों को असंभव अवधियाँ मिलती हैं।

नेटवर्क एक्सेस सर्वर की पहचान सत्र पहचानकर्ता के साथ रखें, क्योंकि दो सर्वर अलग संदर्भों में एक ही मान असाइन कर सकते हैं और केवल पहचानकर्ता पर विलय असंबंधित सत्र जोड़ सकता है। जब सत्र अशिष्टता से समाप्त हो, तो समाधान नीति को तय करना होता है कि उसे कैसे बंद किया जाए, और वह निर्णय डिज़ाइन में होना चाहिए, महीने में एक बार किए जाने वाले हाथ से डेटाबेस संपादन में नहीं।

PAM कहाँ फिट होता है और कहाँ नहीं

OpenVPN का प्रमाणीकरण प्लगइन PAM के प्रमाणीकरण और खाता-प्रबंधन चरणों को कॉल करता है। खाता चरण पात्रता जाँचता है; उसके नाम का अर्थ उपयोग अकाउंटिंग नहीं है, और प्लगइन PAM के सत्र खोलने और बंद करने के हुक नहीं चलाता।

कुछ PAM RADIUS मॉड्यूल उन सत्र हुक के ज़रिए अकाउंटिंग रिकॉर्ड भेज सकते हैं, और यह तभी काम करता है जब एप्लिकेशन वास्तव में उन्हें कॉल करे।

इसलिए ऐसा मॉड्यूल प्रमाणीकरण स्टैक में जोड़ने से डिस्कनेक्ट घटनाएँ नहीं बनतीं। यदि आपको पूरा जीवनचक्र चाहिए, तो ऐसा इंटीग्रेशन चुनें जो उसका मालिक हो: एक प्लगइन या समर्थित बिल्ड जो कनेक्शन की स्थिति बदलने पर Start, Interim-Update और Stop निकालता है। उसकी रखरखाव स्थिति और प्राप्तकर्ता के अनुपलब्ध होने पर उसका प्रलेखित व्यवहार जाँचें, क्योंकि रिकॉर्ड चुपचाप गिराने वाला प्लगइन उसी तरह दिखता है जिसने उन्हें कभी भेजा ही न हो। अकाउंटिंग विनिर्देश उन रिकॉर्डों की अर्थ-व्यवस्था परिभाषित करता है जिनका इंटीग्रेशन को पालन करना होता है।

एक स्वीकृति रन जो अनुबंध साबित करता है

एक सामान्य कनेक्ट और डिस्कनेक्ट जाँचें, फिर उसी खाते के अंतर्गत पुनः कनेक्ट, फिर ऐसा क्लाइंट जो डिस्कनेक्ट किए बिना गायब हो जाता है।

एक सत्र पहचानकर्ता को निर्माण से स्वीकृति होते हुए भंडारण तक अनुसरण करें, और काउंटरों की दिशा, इकाइयाँ और इंटरफ़ेस जाँचें। बिना लेबल वाली बाइट गिनती को बाद में ऑडिट करना असंभव है।

अंत में पुष्टि करें कि जिस सत्र को सर्वर ने समय-सीमा के कारण समाप्त करना पड़ा, वह रिपोर्ट की समझ में आने वाले रूप में दर्शाया गया है। केवल शिष्ट डिस्कनेक्ट कवर करने वाला अनुबंध ऐसा अनुबंध है जो उन दिनों विफल होता है जब आपको उसकी सबसे अधिक आवश्यकता होती है।