किन 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 फर्वार्डिङ सक्रिय र चाहिएका प्रवाहका लागि स्पष्ट नियम आवश्यक हुन्छ। यसलाई अन राख्नु भनेको नीति डिमनको कन्फिगरेसनमा बस्छ, जुन व्यवहारमा सबै पीयर वा कुनै पीयर होइन।

आफ्नै ठेगाना पूल र पोर्ट भएका छुट्टै सर्भर प्रक्रियाहरू काम लाग्ने मध्यम मार्ग हुन्। प्रत्येक प्रक्रियाले ठ्याक्कै एउटा पहुँच निर्णय बोक्छ, त्यसैले दुई समूहले नीति म्याट्रिक्सबिना फरक नियम राख्न सक्छन्। होस्टले चाहिएमा पूलबीच राउट गर्न सक्छ, र त्यसपछि फायरवालले ती प्रवाह देख्छ किनकि ती होस्ट पार गर्छन्। लागत भनेको थप पोर्ट, थप प्रमाणपत्र र प्रत्येक समूहका लागि एउटा प्रोफाइल।

फर्वार्डिङ बिन्दु छनोट गर्ने

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

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

तपाईंले जे छान्नुभए पनि फायरवाल नियमको छेउमा लेख्नुहोस्। पीयरबीचको ट्राफिकलाई अनुमति दिएको जस्तो देखिने तर वास्तवमा डिमनले निर्णय गर्ने नियमसमूहले असफल स्थानान्तरण डिबग गर्ने अर्को व्यक्तिलाई भ्रममा पार्छ। केवल नियम पढ्ने जोकोहीले कर्नेल नै ढोका हो भन्ने ठान्छ।

नियम बदल्नुअघि के जाँच्ने

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

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