OpenVPN क्लाइन्ट ब्लक नियम FORWARD सम्म किन कहिल्यै पुग्दैन

एउटै OpenVPN सर्भरका दुई क्लाइन्टले आफ्नो पूलका लागि DROP नियम थपेपछि पनि एकअर्कासम्म पुग्न सक्छन्। नियम FORWARD शृंखलामा बसेको छ, ट्राफिक स्पष्ट रूपमा बगिरहेको छ, र त्यो नियमको काउन्टर शून्यमै रहन्छ। स्वाभाविक निष्कर्ष के हो भने फायरवाल बिग्रिएको छ। प्रायः प्याकेट शृंखलामै आएको हुँदैन।

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

पियर प्याकेट जान सक्ने दुई बाटो

आन्तरिक फर्वार्डिङ विकल्प बन्द हुँदा, क्लाइन्ट A को प्याकेट टनेल इन्टरफेसमा आउँछ र त्यसको गन्तव्य क्लाइन्ट B लाई दिइएको ठेगानाभित्र हुन्छ। सर्भरको राउटिङ तालिकाले त्यसलाई उही टनेल इन्टरफेसबाट फर्काएर पठाउँछ, किनकि B को ठेगानासम्मको बाटो सर्भरको हो। यो होस्टबाट भित्र-बाहिर जाने प्रवाह हो, र IPv4 फर्वार्डिङ बाटोले यसको मूल्याङ्कन गर्छ।

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

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

काउन्टर कहिल्यै नसर्दा

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

तेस्रो स्थान हो। शृंखलामा अघिल्लो नियमले तपाईंको DROP मूल्याङ्कन हुनुअघि नै प्रवाह स्वीकार गर्न सक्छ, र पछिल्लो नियम नतिजा साँच्चै निर्धारण गर्ने हुन सक्छ। काउन्टर देखिने गरी शृंखला क्रममा पढ्नुहोस्, त्यसपछि परीक्षण दोहोर्याउँदा कुन नियमको गणना बढ्छ जाँच्नुहोस्।

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

फिल्टर गर्न सक्ने सीमा छान्नु

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

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

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

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

नियममा भरोसा गर्नुको सट्टा अलगाव परीक्षण गर्नु

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

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

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