हार्डवेअर 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 हे पोहोचण्यायोग्य राहिले पाहिजे अशा खाजगी गंतव्यस्थानाची पुष्टी करते. तोच संच प्रवेग बंद करून आणि नंतर सुरू करून चालवा, आणि वेळेची नाही, परिणामांची तुलना करा.

मागील सेटिंग नोंदवा जेणेकरून प्रयोग उलटण्यायोग्य राहील. सर्वत्र ऑफलोड बंद करण्याची सर्वसाधारण सूचना तात्पुरता उपाय मानली जाते, शोध नाही.