क्या हार्डवेयर NAT ऑफ़लोड आपके VPN रूटिंग नियम तोड़ता है?

हार्डवेयर 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 किसी निजी गंतव्य की पुष्टि करता है जो पहुँच योग्य रहना चाहिए। वही सेट त्वरण बंद करके और फिर चालू करके चलाएँ, और समय नहीं, परिणामों की तुलना करें।

पिछली सेटिंग दर्ज करें ताकि प्रयोग उलटा जा सके। हर जगह ऑफ़लोड बंद करने का सामान्य निर्देश एक अस्थायी उपाय माना जाता है, कोई निष्कर्ष नहीं।