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

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

नियतकालिक निरीक्षण आणि डिस्कनेक्ट तुम्हाला ज्ञात सहनशीलतेसह नमुनाबद्ध कोटा देतात। क्लायंट अंदाजे एक अहवाल मध्यांतर आणि नियंत्रकाला कार्य करण्यास लागणारा वेळ येवढा जास्त जाऊ शकतो, आणि एका खात्यावरील समवर्ती सत्रे ती खिडकी अनेक पट करतात। तुम्ही देऊ शकत नाही अशा शेवटच्या बाइटवरील अचूक कटऑफची जाहिरात करण्याऐवजी ते इंटरफेसमध्ये सांगा।

खरा कठोर वरचा घटक ही दुसरी अभियांत्रिकी समस्या आहे: अग्रेषण मार्गाच्या आत अंमलबजावणी, सत्रांमध्ये त्याच खात्याशी बांधलेली। काउंटर वेगाने वाचणे तेच नाही, आणि फक्त अधिक टनेल उघडणाऱ्या क्लायंटसमोर ते टिकत नाही।

तैनातीपूर्वी साध्या अंमलबजावणी तोडणारी स्वीकृती प्रकरणे चालवा: वारंवार पुनर्संयोजन, एकाच वेळी दोन उपकरणे, नियंत्रक आणि गेटवे पुन्हा सुरू होणे, गमावलेली डिस्कनेक्ट घटना, सत्राच्या मध्यात कालावधी बदलणे, आणि कोटा संपल्यानंतर लगेच टोकनने पुनर्संयोजनाचा प्रयत्न। त्यानंतर लेखा अडथळ्यांसाठी अपयशाची पद्धत ठरवा। टिकाऊ खातेवही तुम्ही नोंदवलेला वापर संरक्षित करते; कधीही न आलेल्या निरीक्षणांना ती पुनरुज्जीवित करू शकत नाही, आणि ग्राहकाला तो या दोन परिस्थितींपैकी कोणत्या आहे हे जाणून घेण्याचा हक्क आहे।