हार्डवेयर NAT गति बढाउने सुविधा सक्रिय गर्दा VPN सेटअप छिटो हुन सक्छ, र यसले कुनै पनि त्रुटि नदेखाई केही प्याकेटमा राउटिङ नीति लागू हुन छोड्न पनि सक्छ। यीमध्ये कुन हुन्छ भन्ने कुरा छिटो मार्गले के छोड्छ भन्नेमा निर्भर गर्छ, र त्यो फर्मवेयर, कर्नेल संस्करण र प्रयोग भइरहेको गति बढाउने प्रकारअनुसार फरक पर्छ। सेटिङ मेनुले तपाईंले भर्खरै कुन सक्रिय गर्नुभयो भनेर विरलै बताउँछ।

गति बढाउने उपकरणलाई दोष दिनु अघि दुई दाबीलाई अलग गर्नुपर्छ: एउटा नियम लागू हुन छोड्यो, र एउटा काउन्टर अद्यावधिक हुन छोड्यो। यी एउटै अवलोकन होइनन्।

तीन फरक गति वृद्धि एकै ठाउँमा मिसिएका छन्

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

Linux flowtable हरू पढ्न सबैभन्दा योग्य अभिलेखित केस हुन्, किनकि स्थापित फ्लोहरू छिटो मार्गमा सुम्पिन सकिन्छ। त्यसपछि तिनको हिसाब र अवस्था व्यवस्थापन क्लासिक फर्वार्डिङभन्दा फरक हुन्छ, र त्यही कारण काउन्टरहरू अनौठो देखिन थाल्छन्।

चल्न छोडेको काउन्टरले थोरै मात्र प्रमाणित गर्छ

नियमका काउन्टरहरूले नियमबाट जाने प्याकेट गन्छन्, र अफलोड भएको फ्लो पहिलो प्याकेटपछि फेरि कहिल्यै त्यसबाट नजान सक्छ। यसले ट्राफिक चलिरहँदा जम्ने काउन्टर बनाउँछ, र तपाईंले संख्यामा विश्वास गर्नुभयो भने त्यो ठ्याक्कै बाइपासजस्तै देखिन्छ। काउन्टर हेर्नु अझै पनि फ्लो गनिएको मार्गबाट बाहिर गयो भन्ने सङ्केतका रूपमा उपयोगी छ। बाँकी निदान प्याकेट साँच्चै कहाँ जान्छ भन्नेबाट आउनुपर्छ।

उल्टो अनुमान पनि त्यत्तिकै नराम्रोसँग असफल हुन्छ। छिटो डाउनलोडले तपाईंका अपवाद नियम र असफलता व्यवस्थापन अझै लागू छन् भनी देखाउँदैन, किनकि यसले एउटा फ्लो मात्र परीक्षण गर्छ, नीति होइन।

तीन सर्तले अफलोडले नीति तोड्छ कि तोड्दैन भन्ने तय गर्छ

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

तपाईंले चलाइरहेको संयोजनका लागि विक्रेताको कागजात पढ्नुहोस्, सामान्य राउटर मोडेलका लागि होइन। फर्मवेयर संस्करणहरूले यी उत्तरहरू चुपचाप बदल्छन्।

नीतिको परीक्षण गर्नुहोस्, थ्रुपुटको होइन

नीति कति छिटो चल्छ भन्ने नाप्नु अघि यसले के ग्यारेन्टी गर्नुपर्छ त्यो नाप्नुहोस्। तलका आदेशहरूले flowtable स्थापित छ कि छैन, कनेक्सन ट्र्याकिङले के देख्छ, र ग्राहक कुन ठेगानाबाट बाहिर जान्छ देखाउँछन्। परिवर्तनपछि नयाँ कनेक्सन तुलना गर्नुहोस्, किनकि स्थापित कनेक्सनले पुरानै मार्ग राख्न सक्छ।

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

टनेल ट्राफिक समेट्ने flowtable प्रविष्टिले छिटो मार्ग खेलमा छ भनी बताउँछ, र कनेक्सन तालिकाले फ्लो तपाईंले अपेक्षा गरेअनुसार ट्र्याक भइरहेको छ कि छैन देखाउँछ। ठेगाना जाँचले नीति इन्टरनेट निर्गमनसँग सम्बन्धित हुँदा बाहिर निस्कने बाटो पुष्टि गर्छ, जबकि ping ले पहुँचयोग्य रहनुपर्ने निजी गन्तव्य पुष्टि गर्छ। उही सेट गति वृद्धि बन्द र त्यसपछि सक्रिय गरेर चलाउनुहोस्, र समयको होइन, नतिजाको तुलना गर्नुहोस्।

अघिल्लो सेटिङ लेखिराख्नुहोस् ताकि प्रयोग उल्टाउन सकिने रहोस्। जताततै अफलोड बन्द गर्ने सामान्य निर्देशन कामचलाउ उपाय मानिन्छ, खोज होइन।

सम्बन्धित लेखहरू