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 का अपना व्यवहार और अपनी सेटिंग है, और एक मशीन एक परिवार में सख़्त और दूसरे में ढीली हो सकती है, बिना किसी को पता चले जब तक कोई ख़ास गंतव्य विफल न हो। अगर वर्कलोड दोनों इस्तेमाल करता है तो दोनों जाँचें।

मोड, इंटरफ़ेस, रूट खोज का आउटपुट और बदलाव का कारण एक ही जगह दर्ज करें। अगला व्यक्ति सेटिंग पाएगा और कोई व्याख्या नहीं, और या तो उसे हटा देगा या ऐसी जगह कॉपी करेगा जहाँ वह नहीं होना चाहिए।