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 चालू करते हैं, तो नियंत्रक ही प्रमाणक बन जाता है और सत्र स्थिति का विश्लेषण करके समाप्त या अवैध टोकन खुद अस्वीकार करने का दायित्व विरासत में लेता है।

नमूनाकरण जो अतिक्रमण बनाता है उसे स्वीकारें

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

असली कठोर ऊपरी सीमा एक अलग इंजीनियरिंग समस्या है: अग्रेषण पथ के भीतर प्रवर्तन, सत्रों में उसी खाते से बँधा। काउंटर तेज़ी से पढ़ना वही बात नहीं है, और यह ऐसे क्लाइंट के सामने नहीं टिकता जो बस और टनल खोलता है।

परिनियोजन से पहले वे स्वीकृति मामले चलाएँ जो भोले कार्यान्वयन तोड़ते हैं: बार-बार पुनः कनेक्शन, एक साथ दो डिवाइस, नियंत्रक और गेटवे के पुनः आरंभ, खोई डिस्कनेक्ट घटना, सत्र के बीच अवधि का पलटना, और कोटा खत्म होने के ठीक बाद टोकन से पुनः कनेक्शन का प्रयास। फिर लेखा-जोखा बाधाओं के लिए विफलता का तरीका तय करें। टिकाऊ बहीखाता आपके दर्ज उपयोग की रक्षा करता है; जो अवलोकन कभी पहुँचे ही नहीं उन्हें वह पुनर्जीवित नहीं कर सकता, और ग्राहक यह जानने का हकदार है कि वह इन दो स्थितियों में से किसमें है।