एकच tc शेपर प्रत्येक VPN क्लायंटला स्वतः मर्यादित करत नाही

सूचना पूर्ण वाटते: प्रत्येक VPN क्लायंटला 20 Mbit/s पर्यंत मर्यादित करा। पण ती पूर्ण नाही, आणि टनेल इंटरफेसवरील एकच रांग-शिस्त ते देणार नाही। «प्रत्येक क्लायंट» म्हणजे प्रत्येक टनेल पत्ता, प्रत्येक उपकरण किंवा प्रत्येक खाते असू शकते, आणि प्रत्येक निवड पॅकेटचे वेगळ्या प्रकारे वर्गीकरण करते। कोणताही नियम लिहिण्यापूर्वी गरज नेमके कशाला नाव देते ते ठरवा।

खालील सर्व काही त्या वाक्य आणि काम करणाऱ्या गोष्टीमधील अंतराबद्दल आहे।

«प्रत्येक क्लायंट» चा आधी काय अर्थ असला पाहिजे

टनेल पत्ता वर्गीकृत करणे सोपे आणि पुनर्वापर करणेही सोपे। उपकरण अधिक कठीण, कारण एका खात्याकडे अनेक असू शकतात, आणि एका उपकरणाकडे अनेक पत्ते असू शकतात, विशेषतः IPv6 सह। न्यायाच्या धोरणासाठी खाते हे सर्वात अर्थपूर्ण एकक आहे, आणि पॅकेट हेडरमध्ये सर्वात कठीण दिसणारे। प्रत्येक व्याख्या स्वतःची मोजणीची किल्ली सूचित करते, म्हणून त्यांच्यात भरकटणारे धोरण वर्णनात म्हटल्याप्रमाणे करणार नाही।

दिशा हा दुसरा गहाळ शब्द आहे। अपलोड, डाउनलोड आणि एकत्रित या तीन वेगळ्या गरजा आहेत, आणि एका इंटरफेसवरील एकच बहिर्गामी नियम दोन्ही मार्ग क्वचितच व्यापतो।

क्लायंट अजून दिसतो अशी जागा निवडा

प्रत्येक दिशा एका इंटरफेसच्या संदर्भात परिभाषित होते। सर्व्हरच्या टनेलमधून दूरच्या क्लायंटकडे जाणारे त्या क्लायंटसाठी डाउनलोड मानले जाते; क्लायंट पाठवतो ते टनेलमध्ये प्रवेश करते आणि नंतर आपल्या गंतव्याकडे बाहेर पडते। प्रत्येक दिशेसाठी नियोजन बिंदू निवडा आणि तिथे कोणती क्षेत्रे आहेत ते विचारा। स्रोत NAT च्या आधी अपलोड अजूनही क्लायंटचा अंतर्गत पत्ता वाहतो; भाषांतरानंतर साधे स्रोत जुळणी कदाचित तो ओळखू शकणार नाही।

एन्क्रिप्टेड मार्गावर हेडर VPN वाहतुकीचे आहेत, म्हणून अंतर्गत पत्ते जुळवणाऱ्या फिल्टरला जुळवण्यासाठी काहीच नसते। रचना आधी वर्गीकृत करून नंतरच्या शेड्यूलरला गुण देऊ शकते, पण ते सुपूर्द करणे जाणीवपूर्वक असले पाहिजे: पॅकेट गुण, कनेक्शन गुण आणि शेड्यूलर वर्ग या वेगळ्या स्थिती आहेत, पुढे दिला जाणारा एकच मूल्य नाही।

बकेट स्वतःहून येत नाहीत

इंटरफेसला जोडलेली टोकन बकेट ती वापरणाऱ्या कोणत्याही रहदारीला आकार देते; ती प्रत्येक स्रोत पत्त्यासाठी नवीन बकेट तयार करत नाही। वर्ग-आधारित रचना त्याऐवजी निवडलेली रहदारी वर्गांमध्ये लावते, फिल्टर सदस्यत्व ठरवतात, आणि HTB पुस्तिका पालकाकडे अतिरिक्त बँडविड्थ असताना वर्गाचा दर त्याच्या कमाल मर्यादेपासून वेगळा करते। हेतू कठोर मर्यादा असेल तर मर्यादा ठेवा आणि कर्ज घेण्याचे वर्तन जाणीवपूर्वक ठरवा; प्रत्येक दर-आकडा निरपेक्ष कमाल मानू नका।

गरज प्रत्येक क्लायंटसाठी असेल तर एकाच वेळी चालणाऱ्या दोन हस्तांतरणांनी एकच कोटा वाटून घ्यावा। प्रत्येक प्रवाहाला पूर्ण दर देणे हे वेगळे धोरण आहे, आणि फक्त एकच डाउनलोड पाहणाऱ्या कोणत्याही चाचणीत ते टिकते।

दोन उपकरणे, एक खाते, एक कोटा?

दोन उपकरण पत्ते वेगवेगळे मर्यादित करणे कधीही खाते-व्यापी एका कोट्यात बेरीज होत नाही, दोन्ही उपकरणे एकाच व्यक्ती म्हणून लॉग इन केली तरी। हेच संपूर्ण LAN ला लागू होते जे एका पीअरच्या मागे भाषांतरित होते, किंवा वर्गीकरणकर्त्याने कधीही अपेक्षा न केलेल्या अतिरिक्त IPv6 पत्त्यांना। पत्ता आणि ओळख यांचा संबंध अद्ययावत ठेवा, आणि स्थिर पत्ता नकाशा सोपा करतो पण त्याच्या मालकाची प्रमाणित करत नाही हे लक्षात ठेवा।

बर्स्ट आणि रांगेचे वर्तनही परिभाषित करा। टोकन बकेट सरासरीपेक्षा जास्त लहान बर्स्टना परवानगी देतात, आणि बफरिंग विलंब वाढवते; अधिकता पोलिसिंग करणे आणि ती नंतरसाठी रांगेत ठेवणे हे वेगळे लक्षणे असलेले वेगळे निर्णय आहेत।

पडताळणीसाठी एका क्लायंटकडून दोन हस्तांतरणे चालवा, दुसरा क्लायंट जोडा, आणि प्रत्येक दिशेने वर्ग काउंटर वाचा।