nftables ला OpenVPN च्या क्लायंटमधील ट्रॅफिक का दिसत नाही

एकाच सर्व्हरवरील दोन क्लायंट फाइलींची देवाणघेवाण करतात, हस्तांतरण यशस्वी होते, आणि टनेलकडे निर्देशिल प्रत्येक फॉर्वर्ड नियम शून्य पॅकेट नोंदवतो। नियम तुटलेले नाहीत आणि साखळी चुकीच्या ठिकाणी नाही। पीअर-टू-पीअर फॉर्वर्डिंग सुरू असताना पॅकेट सर्व्हर प्रक्रियेच्या आतच पोहोचवले जाते आणि होस्ट स्टॅक कधीच राउटर बनत नाही, त्यामुळे कर्नेल फायरवॉलला मोजण्यासाठी काहीच उरत नाही। हे विभाजन समजून घेणे ठरवते की तुम्ही शॉर्टकट ठेवता की कर्नेलमार्गे मार्ग पुन्हा बांधता।

सर्व्हरमधून एक पॅकेट मागे लागा

राउटेड टनेलमध्ये डिमन प्रत्येक क्लायंटचे डिक्रिप्ट केलेले पॅकेट टनेल उपकरणाला देतो। तिथून होस्ट ते राउट करतो, फॉर्वर्ड हुक चालतो, आणि टनेल उपकरणाशी जुळणारा नियम ट्रॅफिक मोजू किंवा टाकाऊ शकतो। बहुतेक फायरवॉल उदाहरणे हा मार्ग गृहीत धरतात।

शॉर्टकट होस्टला मधून काढून टाकतो। एका सत्राचे डिक्रिप्ट केलेले पॅकेट डिमनच्या आत दुसऱ्या सत्राला दिले जाते, आणि आतील पॅकेट कधीच टनेल उपकरणावर जारी होत नाही किंवा होस्ट त्याला राउट करत नाही। एन्कॅप्स्युलेटेड ट्रॅफिक तरीही भौतिक इंटरफेस ओलांडते, त्यामुळे बाहेरील कॅप्चर व्यस्त दिसते तर आतील नियम शांत राहतात। टनेल उपकरणावर घेतलेले कॅप्चर काहीच दाखवत नाही, ज्यामुळे तिथे हस्तांतरण पाहण्याची अपेक्षा करणारा कोणीही थक्क होतो। ही विषमताच डिमनच्या बाहेरून शॉर्टकट ओळखण्याचा सर्वात जलद मार्ग आहे।

कोणता मार्ग गेला हे ठरवणारी काउंटर चाचणी

लागू व्हायला हव्या त्या नियमाला काउंटर जोडा, त्या नियमाने अडवायला हव्या अशा दोन क्लायंटमध्ये हस्तांतरण चालवा, आणि नंतर काउंटर वाचा।

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

हस्तांतरण यशस्वी झाले आणि काउंटर शून्यावरच राहिले, तर कर्नेलने ती पॅकेट कधीच हाताळली नाहीत, आणि नियम कितीही संपादित केले तरी ते बदलणार नाही। तीच चाचणी सर्व्हरवरील सेवेविरुद्ध पुन्हा करा, कारण तो प्रवाह होस्ट स्टॅकमधून जातो आणि त्याचा काउंटर हलतो। दोन्ही निकालांची तुलना केल्यावरच उत्तर मिळते।

दोन तपशील चुकीचे वाचन टाळतात। साखळीच्या लेबलात लिहिलेले इंटरफेस नाव स्वतः काहीच फिल्टर करत नाही, कारण जुळणी नियमांच्या आतील इंटरफेस फील्डवर होते। आणि ब्रिज केलेली स्तर-2 रचना पुन्हा वेगळी वागते: तिथे क्लायंट एकच प्रसारन क्षेत्र वाटून घेतात, त्यामुळे पीअर शोधणे अपेक्षित आहे, राउटिंग दोष नाही।

स्विच म्हणजे प्रवेश सूची नाही

हा तो भाग आहे जो अर्धा दिवस खातो। पीअर फॉर्वर्डिंग हा एकच चालू-बंद सेटिंग आहे, आणि तो चालू असताना डिमन हाच एकमेव फॉर्वर्डिंग बिंदू आहे। होस्ट फायरवॉल कोण कोणापर्यंत पोहोचू शकतो हे सांगू शकत नाही, आणि प्रत्येक क्लायंटच्या फाइली स्विचला धोरण मॅट्रिक्स बनवत नाहीत।

तुम्हाला प्रत्येक पीअरसाठी नियम हवे असतील, तर निवड शॉर्टकट सोडणे आणि नियंत्रण म्हणून होस्ट फायरवॉल सोडणे यांत आहे। तो बंद केल्यास कर्नेल फॉर्वर्डिंग परत येते, ज्यासाठी सर्व्हरवर IP फॉर्वर्डिंग सुरू आणि हव्या त्या प्रवाहांसाठी स्पष्ट नियम लागतात। तो चालू ठेवल्यास धोरण डिमनच्या संरचनेत राहते, जे प्रत्यक्षात सर्व पीअर किंवा एकही पीअर नाही।

स्वतःच्या पत्ता पूल आणि पोर्ट असलेल्या वेगळ्या सर्व्हर प्रक्रिया हा व्यवहार्य मधला मार्ग आहे। प्रत्येक प्रक्रिया नेमका एक प्रवेश निर्णय बाळगते, त्यामुळे दोन गट धोरण मॅट्रिक्सशिवाय वेगवेगळे नियम ठेवू शकतात। होस्टला हवे असल्यास पूलांमध्ये राउट करता येते, आणि मग फायरवॉल ते प्रवाह पाहतो कारण ते होस्ट ओलांडतात। किंमत म्हणजे जादा पोर्ट, जादा प्रमाणपत्रे आणि प्रत्येक गटासाठी एक प्रोफाइल।

फॉर्वर्डिंग बिंदू निवडणे

फायरवॉल हे धोरणाचे इंजिन असेल, प्रत्येक प्रवाहासाठी नोंद हवी असेल, किंवा हिशोब महत्त्वाचा असेल तेव्हा कर्नेल फॉर्वर्डिंग निवडा। किंमत म्हणजे होस्ट स्टॅकमधून मिळणारा थ्रूपुट आणि सांभाळायचे जास्त नियम। फायदा असा की काउंटरपासून प्रवाह निर्यातकांपर्यंत प्रत्येक विद्यमान साधन पुन्हा ट्रॅफिकचे वर्णन करते। छोट्या सर्व्हरवर ही किंमत अदृश्य असते; व्यस्त रिलेवर ती नसते।

पीअरमधील ट्रॅफिक एकतर पूर्णपणे परवानगीचे किंवा पूर्णपणे प्रतिबंधित असेल आणि सर्व्हर त्यासाठी मोजलेला असेल तेव्हा प्रक्रियेतील फॉर्वर्डिंग निवडा। किंमत ही की काउंटर, रांगेचे नियम आणि कनेक्शन ट्रॅकिंग आता आतील प्रवाहांचे वर्णन करत नाहीत; नंतर कोणीही त्यांवर अवलंबून नसेल तरच हे स्वीकार्य आहे।

तुम्ही काहीही निवडा, ते फायरवॉल नियमांशेजारी लिहून ठेवा। पीअरमधील ट्रॅफिकला परवानगी देत असल्यासारखा दिसणारा, पण प्रत्यक्षात डिमन ठरवणारा नियमसंच पुढच्या त्या व्यक्तीला दिशाभूल करतो जो अयशस्वी हस्तांतरण डीबग करेल। फक्त नियम वाचणारा कोणीही कर्नेलच दरवाजा आहे असे गृहीत धरेल।

नियम बदलण्यापूर्वी काय तपासावे

सर्व्हरने प्रत्यक्षात लोड केलेली संरचना वाचा, तुम्हाला संपादित केल्याचे आठवणारी फाइल नाही, आणि पीअर पर्याय आहे का ते तपासा। तो बदलला असेल, तर सेवा पुन्हा लोड झाली आहे, केवळ डिस्कवरील फाइल पुन्हा लिहिली गेली नाही याची खात्री करा।

नंतर नियम अजिबात जुळतो हे सिद्ध करण्यासाठी क्लायंटकडून सर्व्हरकडे जाणाऱ्या प्रवाहाने चाचणी पुन्हा करा, आणि पाठवलेले मार्ग तपासा, कारण गहाळ मार्ग क्लायंटच्या बाजूने अगदी फायरवॉल अडवण्यासारखा दिसतो। कोणता फॉर्वर्डिंग बिंदू निर्णयाचा मालक आहे हे कळल्यावरच नियमांचा क्रम बदला।