OpenVPN खाताअनुसार मासिक डेटा कोटा कहाँ पर्छ

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

कोटा सुरुङमा होइन, खातामा बाँध्नुहोस्

कोटाको विषय नाम दिएर सुरु गर्नुहोस्। एक व्यक्तिसँग तीन यन्त्र प्रमाणपत्र हुन सक्छन्, र ती छुट्टै प्रमाणीकरण गर्छन् भन्ने मात्र कारणले तिनमध्ये कसैले पनि स्वतन्त्र मासिक बजेट पाउनु हुँदैन। पुनःजडान, नयाँ सुरुङ ठेगाना र दोस्रो गेटवेमा सर्ने कुरा सहने स्थिर खाता पहिचानकर्ता नै कोटाले प्रयोग गर्न सक्ने एक मात्र आधार हो। प्रमाणपत्रको सामान्य नाम त्यो कुञ्जीका रूपमा तब मात्र काम गर्छ जब तपाईंको जारी नीतिले प्रत्येक नाममा एक खाता ग्यारेन्टी गर्छ।

तोकिएको सुरुङ ठेगाना कहिल्यै उत्तर होइन। ठेगाना पुनःप्रयोग हुन्छन्, पूल साझा हुन्छन्, र एउटै खाता एउटै मिनेटमा दुई गेटवेमा दुई पटक देखिन सक्छ। यदि खाता ठेगानामा आधारित छ भने ट्याङ्की फेरि भर्न डिस्कनेक्ट गरेर पुनः जोडिनु पर्याप्त हुन्छ।

गणना अडिटयोग्य बनाउन प्रत्येक सत्रमा पर्याप्त लेख्नुहोस्: खाता, बिलिङ अवधि, गेटवे इन्स्ट्यान्स, सत्र पहिचान, अन्तिम अवलोकन गरिएका काउन्टर र प्रतिबद्ध कुल। सत्र पहिचानमा डेमन सुरु हुने पुस्ता समावेश गर्नुहोस्, किनकि पुनः सुरु भएको सर्भरले क्लाइन्ट आईडी पुनः प्रयोग गर्छ र सोझो मिलानले अघिल्लो आधाररेखा उत्तराधिकारमा लिन्थ्यो।

एकाइ, दिशा र रिसेट सीमा निर्धारण गर्नुहोस्

कुनै पनि सङ्कलन सुरु हुनुअघि चार परिभाषा लिखित रूपमा तय गर्नुपर्छ। कोटाले क्लाइन्टले पठाउने बाइट, प्राप्त गर्ने बाइट, वा दुवैको जोड गणना गर्छ? एक गिगाबाइट 10^9 बाइट हो वा 2^30? कुन स्थानीय घडीमा र कुन समय क्षेत्रमा अवधि पल्टिन्छ? र काउन्टरले ठ्याक्कै के नाप्छ, जबकि सुरुङको ओभरहेड र पुनःप्रसारण समावेश छन् तर अनुप्रयोग फाइलको आकार र प्रदायकको बिल छैन?

यीमध्ये कुनै पनि विकल्प गलत होइन, तर कार्यान्वयन र ग्राहकले देख्ने सङ्ख्या मिल्नुपर्छ। एउटै प्रणालीका दुई आधा भाग GiB मा, वा स्थानीय समयको सट्टा UTC मध्यरातमा हुने परिवर्तनमा सहमत नभए सिङ्गो कोटाप्रतिको विश्वास कमजोर पार्ने ठ्याक्कै त्यस्तै टिकट बन्छ।

बाइट कुललाई एक लिइने भिन्नतामा बदल्नुहोस्

व्यवस्थापन इन्टरफेस ले क्लाइन्ट आईडी र प्रत्येक दिशामा सञ्चित बाइट कुल बोक्ने आवधिक BYTECOUNT_CLI लाइनहरू रिपोर्ट गर्छ, र bytecount आदेशले ती कति पटक आउने भन्ने निर्धारण गर्छ। सर्भरको दृष्टिकोणबाट, प्राप्त सङ्ख्याले क्लाइन्टले पठाएका बाइट गणना गर्छ र पठाइएको सङ्ख्याले उसलाई पुर्याइएका बाइट गणना गर्छ। अन्तराललाई खाताले पचाउन सक्ने कुरामा राख्नुहोस्; धेरै छोटो अन्तरालले वास्तवमा नपाइने शुद्धता किन्छ।

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

rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge  = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now

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

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

सकिएपछि प्रवेश अस्वीकार होस्, सुरुङ मात्र नमारियोस्

जब खाता आफ्नो सीमामा पुग्छ, दुई कुरा हुनुपर्छ: विद्यमान सत्र अन्त्य हुन्छन् र नयाँ अस्वीकार हुन्छन्। व्यवस्थापन प्रोटोकलले क्लाइन्ट आईडीअनुसार client-kill दिन्छ, जसले पहिलो आधा सम्हाल्छ यदि तपाईंले खाताको हरेक जीवित सत्र गन्नुभयो भने, आँखामा परेको एउटै ठेगाना मार्नुको सट्टा।

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

टोकनमा आधारित पुनःजडान आफ्नै परीक्षाको योग्य छ। OpenVPN 2.6 ले auth-gen-token सँग सत्र टोकन आन्तरिक रूपमा प्रमाणित गर्न सक्छ, तपाईंको नियन्त्रकले सीमा लागू गर्न प्रयोग गर्ने बाह्य प्रमाणीकरण कल छोडेर। त्यसैले अझै वैध टोकनले पहिचान प्रमाणित गर्छ, बाँकी कोटा होइन, र हरेक नयाँ क्लाइन्ट इन्स्ट्यान्सले अझै खातासँग परामर्श गर्नुपर्छ। सट्टा management-client-auth सक्षम गर्नुभयो भने नियन्त्रक नै प्रमाणक बन्छ र सत्र अवस्था विश्लेषण गरी म्याद सकिएका वा अवैध टोकन आफै अस्वीकार गर्ने दायित्व उत्तराधिकारमा लिन्छ।

नमुनाले सिर्जना गर्ने अतिक्रमण स्वीकार गर्नुहोस्

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

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

तैनाथीअघि सोझा कार्यान्वयन तोड्ने स्वीकृति केसहरू चलाउनुहोस्: बारम्बार पुनःजडान, एकै समयमा दुई यन्त्र, नियन्त्रक र गेटवे पुनः सुरु, हराएको डिस्कनेक्ट घटना, सत्रको बीचमा अवधि परिवर्तन, र कोटा सकिएलगत्तै टोकन पुनःजडानको प्रयास। त्यसपछि लेखा अवरोधका लागि असफलताको ढाँचा तय गर्नुहोस्। टिकाउ खाताले तपाईंले अभिलेख गरेको प्रयोग जोगाउँछ; कहिल्यै नआएका अवलोकनलाई यसले पुनर्जीवित गर्न सक्दैन, र ग्राहकले आफू ती दुई अवस्थामध्ये कुनमा छ भन्ने जान्न योग्य छ।