RADIUS लेखा र सफल लगइन: प्रत्येकले के प्रमाणित गर्छ

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

दुई फरक प्रश्न

प्रमाणीकरणले जडान सुरु हुन सक्छ कि भनी निर्णय गर्छ, र यसले ठेगाना पूल वा समूह जस्ता विशेषतासहित फैसला फर्काउँछ. लेखाले त्यसपछि आएको सेवालाई एउटै सत्रसँग बाँधिएका घटनाहरूको क्रमका रूपमा अभिलेख गर्छ।

तिनीहरू एउटै प्रोटोकलमा र सामान्यतया एउटै सर्भरमा जान्छन्, र त्यसैले मानिसहरू एउटले अर्कोलाई जनाउँछ भनी ठान्छन्।

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

तीन रेकर्ड प्रकारले के दिन्छन्

Start रेकर्डले सत्र खोल्छ, Interim-Update ले खुला रहेसम्म गतिविधि जनाउँछ, र Stop ले बन्द गर्छ। तीनैले सत्र पहिचानकर्ता बोक्छन् ताकि प्राप्तकर्ताले तिनीहरूलाई एउटै सेवा घटनासँग जोड्न सकोस्।

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

रेकर्ड स्वीकार गर्नु र त्यसलाई राम्ररी भण्डारण गर्नु फरक कुरा हो। रेकर्ड लेख्न नसकिएको बेला लेखा विशिष्टताले स्वीकृतिमा रोक लगाउँछ, त्यसैले प्रतिक्रियाले प्राप्तकर्ताले जिम्मेवारी लिएको बताउँछ। तर पछिको प्रतिवेदन काम, ड्यासबोर्ड वा बिलिङ निर्यातले त्यसलाई सही रूपमा उपभोग गर्‍यो भनी भन्दैन।

किन प्रयोगकर्तानाम सत्र होइन

एक व्यक्ति बिहान ल्यापटपबाट र दिउँसो फोनबाट जडान हुन्छ, र दुवै सत्रले एउटै खाता नाम बोक्छन्। मिल्ने Stop बिना आउने Start, नाम खोजेर सबैभन्दा पुरानो खुला पङ्क्ति छानेर बन्द गर्न सकिँदैन।

त्यही छोटो बाटोले प्रयोग प्रतिवेदनमा असम्भव अवधि आउँछ।

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

PAM कहाँ मिल्छ र कहाँ मिल्दैन

OpenVPN को प्रमाणीकरण प्लगइनले PAM का प्रमाणीकरण र खाता व्यवस्थापन चरणहरू बोलाउँछ। खाता चरणले योग्यता जाँच्छ; त्यसको नामले प्रयोग लेखा जनाउँदैन, र प्लगइनले PAM का सत्र खोल्ने र बन्द गर्ने हुक चलाउँदैन।

केही PAM RADIUS मोड्युलले ती सत्र हुकमार्फत लेखा रेकर्ड पठाउन सक्छन्, र त्यो अनुप्रयोगले तिनीहरूलाई साँच्चै बोलाएको बेला मात्र काम गर्छ।

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

करार प्रमाणित गर्ने स्वीकृति परीक्षण

सामान्य जडान र विच्छेद परीक्षण गर्नुहोस्, त्यसपछि एउटै खातामुनि पुनः जडान, त्यसपछि नटुटाई हराउने क्लाइन्ट।

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

अन्तमा, सर्भरले समयसीमा सकिएर बन्द गर्नुपरेको सत्र प्रतिवेदनले बुझ्ने रूपमा प्रस्तुत भएको निश्चित गर्नुहोस्। केवल शिष्ट विच्छेद समेट्ने करार त्यस्तो करार हो जुन तपाईंलाई सबैभन्दा आवश्यक परेका दिनहरूमा असफल हुन्छ।