एउटा tc आकारकर्ताले प्रत्येक VPN ग्राहकलाई आफैं सीमित गर्दैन

निर्देशन पूरा सुनिन्छ: प्रत्येक VPN ग्राहकलाई 20 Mbit/s मा सीमित गर। तर यो पूरा छैन, र टनेल इन्टरफेसमा एउटै लामो अनुशासनले यो दिँदैन। «प्रत्येक ग्राहक» भन्नाले प्रत्येक टनेल ठेगाना, प्रत्येक उपकरण वा प्रत्येक खाता हुन सक्छ, र प्रत्येक छनोटले प्याकेटलाई फरक तरिकाले वर्गीकृत गर्छ। कुनै पनि नियम लेख्नुअघि आवश्यकताले वास्तवमा कुनलाई नाम दिन्छ त्यो निर्धारण गर।

तलको सबै कुरा त्यो वाक्य र काम गर्ने कुनै कुराबीचको दूरीसँग सम्बन्धित छ।

«प्रत्येक ग्राहक» ले पहिले के अर्थ दिनुपर्छ

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

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

ग्राहक अझै देखिने बिन्दु छान

प्रत्येक दिशा एउटा इन्टरफेसको सापेक्ष परिभाषित हुन्छ। सर्भरको टनेलबाट टाढाको ग्राहकतर्फ जाने कुरा त्यो ग्राहकका लागि डाउनलोड मानिन्छ; ग्राहकले पठाउने कुरा टनेलमा प्रवेश गर्छ र त्यसपछि आफ्नो गन्तव्यतर्फ निस्कन्छ। प्रत्येक दिशाका लागि एउटा तालिका बिन्दु छान र त्यहाँ कुन क्षेत्रहरू छन् भनी सोध। स्रोत NAT अघि अपलोडले अझै ग्राहकको आन्तरिक ठेगाना बोक्छ; अनुवादपछि साधारण स्रोत मिलानले त्यो चिन्न नसक्न सक्छ।

इन्क्रिप्टेड मार्गमा हेडरहरू VPN यातायातका हुन्, त्यसैले आन्तरिक ठेगाना मिलाउने फिल्टरसँग मिलाउन केही हुँदैन। डिजाइनले पहिले वर्गीकृत गरी पछिको तालिकाकर्तालाई चिन्ह सुम्पन सक्छ, तर त्यो सुम्पाइ जानाजानी हुनुपर्छ: प्याकेट चिन्ह, जडान चिन्ह र तालिकाकर्ता वर्ग फरक अवस्था हुन्, अगाडि पठाइने एउटै मान होइन।

बाल्टीहरू आफैं देखिँदैनन्

इन्टरफेसमा जोडिएको टोकन बाल्टीले त्यसलाई प्रयोग गर्ने जुनसुकै ट्राफिकलाई आकार दिन्छ; यसले प्रत्येक स्रोत ठेगानाका लागि नयाँ बाल्टी बनाउँदैन। वर्ग-आधारित डिजाइनले बरु छानिएको ट्राफिकलाई वर्गहरूमा क्रमबद्ध गर्छ, फिल्टरहरूले सदस्यता निर्धारण गर्छन्, र HTB पुस्तिकाले अभिभावकसँग बढी ब्यान्डविथ हुँदा वर्गको दरलाई यसको सीमाबाट अलग गर्छ। यदि उद्देश्य कडा सीमा हो भने सीमा तोक र ऋण लिने व्यवहार जानाजानी निर्धारण गर; प्रत्येक दर-अंकलाई निरपेक्ष अधिकतम नमान।

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

दुई उपकरण, एउटा खाता, एउटा कोटा?

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

बर्स्ट र लामो व्यवहार पनि परिभाषित गर। टोकन बाल्टीहरूले औसतभन्दा माथिका छोटा बर्स्टहरूलाई अनुमति दिन्छन्, र बफरिङले ढिलाइ थप्छ; अधिकतालाई पुलिस गर्नु र त्यसलाई पछिका लागि लाममा राख्नु फरक लक्षण भएका फरक निर्णय हुन्।

प्रमाणित गर्न एउटा ग्राहकबाट दुई स्थानान्तरण चलाऊ, दोस्रो ग्राहक थप, र प्रत्येक दिशामा वर्ग काउन्टर पढ।