Linux VPN का जवाफ हराउँदै छन्? rp_filter र मार्ग जाँच्नुहोस्

अनुरोधहरू मेसिनबाट बाहिरिन्छन्, VPN सहकर्मी जवाफ दिन्छ, र जवाफ कहिल्यै सकेटसम्म पुग्दैन। टनेल सक्रिय छ, सहकर्मीका लगहरूले प्याकेट पठाइएको देखाउँछन्, र अनुप्रयोगमा यो मौनता व्याख्या गर्ने केही छैन। Linux मा सामान्य शंकास्पदमध्ये एक उल्टो मार्गको फिल्टरिङ हो: आउने IPv4 प्याकेट अस्वीकार गर्न सकिन्छ जब स्रोत प्रमाणीकरण कर्नेलले त्यो स्रोतका लागि अपेक्षा गर्ने मार्गसँग मिल्दैन। यसलाई क्रममा हेर्दा यो कारण हो वा संयोग भन्ने थाहा हुन्छ। यसले तपाईंलाई हराएको मार्ग सुधार्न सुरक्षा नियन्त्रण बन्द गर्नबाट पनि रोक्छ।

स्रोत प्रमाणीकरणले के निर्णय गर्छ

कर्नेलले प्याकेटको स्रोत ठेगाना त्यो आएको इन्टरफेसका लागि विश्वसनीय छ कि छैन भनी जाँच्छ, त्यो स्रोततर्फ फर्किने मार्गका लागि राउटिङ तालिका हेरेर। यदि उल्टो मार्ग अरू कतै देखाउँछ भने, कुनै फायरवाल नियम वा अनुप्रयोग सकेटले देख्नु अघि नै प्याकेट फ्याँकिन सक्छ। यो जाँच केही स्पुफिङ ढाँचाहरू कठिन बनाउनका लागि छ, र त्यसैले असममित र नीति-राउटेड डिजाइनहरू यसमा अल्झिन्छन्, जबकि एउटै सञ्जालका हरेक सामान्य क्लाइन्ट राम्ररी चल्छ। सामान्य क्लाइन्टसँग सममित राउटिङ हुन्छ, र जाँचले ठ्याक्कै त्यही मान्दछ।

महत्त्वपूर्ण शब्द विश्वसनीय हो। प्याकेट पूर्ण रूपमा वैध हुँदाहुँदै पनि जाँचमा असफल हुन सक्छ, किनकि वैधता जाँचिँदैन।

प्रभावकारी मोड पढ्नुहोस्, एउटा फिल्ड होइन

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

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

तेस्रो पङ्क्तिको मार्ग खोज नै मानिसहरूले छोड्ने भाग हो। यसले कर्नेल स्रोतबारे के सोच्छ भन्ने बताउँछ, र त्यही जाँचको इनपुट हो।

जाँच बदल्नु अघि असमझदारी भेट्नुहोस्

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

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

पहिलो प्रतिक्रियाका रूपमा स्रोत जाँचहरू विश्वव्यापी रूपमा बन्द नगर्नुहोस्। त्यसले ठोस निदानको सट्टा पछि सम्झनुपर्ने फराकिलो व्यवहार परिवर्तन दिन्छ।

तपाईंले समर्थन गर्न सक्ने छनोट समायोजन

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

अझै अस्वीकार हुनुपर्ने केस समावेश गर्नुहोस्। यदि त्यो केस अहिले सफल हुन्छ भने, समायोजनले तपाईंले सुधार्न चाहेको एक मार्गभन्दा बढी कमजोर बनायो।

IPv4 र IPv6 अलग राख्नुहोस्

चिनजानको देखिने sysctl हरेक ठेगाना-परिवारका लागि नीति होइन। IPv6 को आफ्नै व्यवहार र आफ्नै सेटिङ छ, र एउटा मेसिन एक परिवारमा कडा र अर्कोमा उदार हुन सक्छ, कुनै निश्चित गन्तव्य असफल नहुँदासम्म कसैले थाहा नपाउने। कार्यभार दुवै प्रयोग गर्छ भने दुवै जाँच्नुहोस्।

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