एक tc शेपर अपने आप हर VPN क्लाइंट को सीमित नहीं करता
प्रति क्लाइंट सीमा के लिए गणना पहचान, दो दिशाएँ और एक वर्गीकरण बिंदु चाहिए। टनल पर एक शेपर हर उपयोगकर्ता के लिए एक कोटा नहीं है।
निर्देश पूरा लगता है: हर VPN क्लाइंट को 20 Mbit/s तक सीमित करो। यह पूरा नहीं है, और टनल इंटरफ़ेस पर एक ही कतार-अनुशासन इसे नहीं देगा। «प्रति क्लाइंट» का अर्थ प्रति टनल पता, प्रति डिवाइस या प्रति खाता हो सकता है, और हर चुनाव पैकेटों को अलग तरह से वर्गीकृत करता है। कोई भी नियम लिखने से पहले तय करें कि आवश्यकता वास्तव में किसे नाम देती है।
नीचे सब कुछ उस वाक्य और काम करने वाली किसी चीज़ के बीच की दूरी के बारे में है।
«प्रति क्लाइंट» का पहले क्या अर्थ होना चाहिए
टनल पता वर्गीकृत करना आसान है और दोबारा उपयोग करना भी आसान है। डिवाइस कठिन है, क्योंकि एक खाता कई डिवाइस रख सकता है, और एक डिवाइस कई पते रख सकता है, खासकर IPv6 के साथ। निष्पक्षता नीति के लिए खाता सबसे अर्थपूर्ण इकाई है, और पैकेट हेडर में सबसे कठिनाई से दिखती है। हर परिभाषा अपनी गणना कुंजी लेकर आती है, इसलिए उनके बीच भटकने वाली नीति वह नहीं करेगी जो विवरण दावा करता है।
दिशा दूसरा गुम शब्द है। अपलोड, डाउनलोड और संयुक्त तीन अलग आवश्यकताएँ हैं, और एक इंटरफ़ेस पर एक ही आउटगोइंग नियम शायद ही दोनों रास्ते ढकता है।
ऐसा बिंदु चुनें जहाँ क्लाइंट अभी दिखाई देता है
हर दिशा किसी इंटरफ़ेस के सापेक्ष परिभाषित होती है। सर्वर की टनल से दूर के क्लाइंट की ओर जो निकलता है वह उस क्लाइंट के लिए डाउनलोड गिना जाता है; क्लाइंट जो भेजता है वह टनल में प्रवेश करता है और फिर अपने गंतव्य की ओर निकलता है। हर दिशा के लिए एक शेड्यूलिंग बिंदु चुनें और पूछें कि वहाँ कौन-से फ़ील्ड मौजूद हैं। स्रोत NAT से पहले अपलोड अब भी क्लाइंट का आंतरिक पता ले जाता है; अनुवाद के बाद साधारण स्रोत मिलान शायद उसे पहचान न पाए।
एन्क्रिप्टेड पथ पर हेडर VPN परिवहन के हैं, इसलिए आंतरिक पतों से मिलान करने वाले फ़िल्टर के पास मिलाने को कुछ नहीं है। कोई डिज़ाइन पहले वर्गीकृत करके बाद के शेड्यूलर को मार्क सौंप सकता है, पर वह सौंपना जानबूझकर होना चाहिए: पैकेट मार्क, कनेक्शन मार्क और शेड्यूलर वर्ग अलग स्थिति हैं, आगे भेजा जाने वाला एक मान नहीं।
बाल्टियाँ अपने आप नहीं आतीं
इंटरफ़ेस से जुड़ी टोकन बाल्टी उसका उपयोग करने वाले किसी भी ट्रैफ़िक को ढालती है; वह हर स्रोत पते के लिए नई बाल्टी नहीं बनाती। वर्ग-आधारित डिज़ाइन इसके बजाय चुने गए ट्रैफ़िक को वर्गों में क्रमबद्ध करता है, फ़िल्टर सदस्यता तय करते हैं, और HTB पुस्तिका किसी वर्ग की दर को उसकी सीमा से अलग करती है जब मूल के पास अतिरिक्त बैंडविड्थ हो। यदि इरादा कठोर सीमा है, तो सीमा तय करें और उधार व्यवहार जानबूझकर तय करें; हर दर-संख्या को पूर्ण अधिकतम न मानें।
जब आवश्यकता प्रति क्लाइंट हो, तो एक साथ चल रहे दो स्थानांतरणों को एक ही कोटा बाँटना चाहिए। हर प्रवाह को पूरी दर देना अलग नीति है, और वह किसी भी ऐसी परीक्षा में टिक जाती है जो केवल एक डाउनलोड देखती है।
दो डिवाइस, एक खाता, एक कोटा?
दो डिवाइस पतों को अलग-अलग सीमित करना कभी भी खाता-व्यापी एक कोटा नहीं बनता, चाहे दोनों डिवाइस एक ही व्यक्ति के रूप में लॉग इन करें। यही बात पूरे LAN पर लागू होती है जो एक पीयर के पीछे अनूदित होता है, या उन अतिरिक्त IPv6 पतों पर जिनकी वर्गीकरणकर्ता ने कभी अपेक्षा नहीं की। पता-पहचान संबंध अद्यतन रखें, और याद रखें कि स्थिर पता नक्शे को सरल बनाता है पर उसके स्वामी को प्रमाणित नहीं करता।
बर्स्ट और कतार व्यवहार भी परिभाषित करें। टोकन बाल्टियाँ औसत से ऊपर छोटे बर्स्ट की अनुमति देती हैं, और बफ़रिंग विलंब जोड़ती है; अधिकता को पुलिस करना और उसे बाद के लिए कतार में डालना अलग निर्णय हैं जिनके अलग लक्षण हैं।
सत्यापन के लिए एक क्लाइंट से दो स्थानांतरण चलाएँ, दूसरा क्लाइंट जोड़ें, और हर दिशा में वर्ग काउंटर पढ़ें।