net.ipv4.conf.default.forwarding tun0 को क्यों अछूता छोड़ता है

आपने net.ipv4.conf.default.forwarding=1 सेट किया, VPN फिर से चलाया, और टनल अब भी वे पैकेट गिरा रही है जिन्हें गेटवे को रूट करना चाहिए। फ़ाइल में सेटिंग सही दिखती है, और इंटरफ़ेस अब भी बताता है कि फ़ॉरवर्डिंग बंद है। कुछ टूटा नहीं है: आपने वह मान बदला है जो भविष्य के इंटरफ़ेस विरासत में लेते हैं, वह नहीं जो जीवित टनल इस्तेमाल कर रही है।

इसे उस होस्ट पर देखें जो टनल का मालिक है, उस नेटवर्क namespace में जहाँ टनल वास्तव में मौजूद है। कोई कंटेनर या नेटवर्क namespace इंटरफ़ेस रख सकता है जबकि होस्ट कुछ और संख्याएँ दिखाता है।

तीनों मान एक साथ पढ़ें

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

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

आम परिणाम होता है ip_forward = 0, default.forwarding = 1 और tun0.forwarding = 0। पहले दो होस्ट की भूमिका पर सहमत नहीं हैं, और तीसरा दिखाता है कि इंटरफ़ेस वास्तव में क्या कर रहा है। यह संयोजन ऐसे होस्ट से मेल खाता है जिसे कभी राउटर के रूप में कॉन्फ़िगर नहीं किया गया, बस टेम्पलेट मान मिला। तीनों संख्याएँ एक-दूसरे का विरोध नहीं करतीं; वे तीन अलग सवालों के जवाब देती हैं। टेम्पलेट मान लिखना भी होस्ट की भूमिका तय नहीं करता।

क्यों ग्लोबल स्विच ही हिलता है

net.ipv4.ip_forward गेटवे-व्यापी नियंत्रण है। इसे बदलने से उसी क्रिया के हिस्से के रूप में प्रति-इंटरफ़ेस फ़ॉरवर्डिंग सेटिंग्स अपडेट होती हैं, इसलिए एक ही लेख मौजूदा टनल को फ़ॉरवर्ड करना शुरू करा सकता है। default.forwarding केवल उन इंटरफ़ेस को बोता है जो बाद में आरंभ होते हैं, इसलिए पहले से मौजूद टनल वही मान रखती है जिसके साथ वह जन्मी थी।

कर्नेल दस्तावेज़ ip_forward को एक जुड़े कारण से विशेष बताते हैं: इसे बदलने से कई अन्य IPv4 पैरामीटर होस्ट या राउटर डिफ़ॉल्ट पर रीसेट हो जाते हैं। इससे यह एक भद्दा औज़ार बन जाता है। गेटवे भूमिका स्थापित करने के हिस्से के रूप में इसे एक बार सेट करना ठीक है; डिबगिंग की तरकीब के तौर पर बार-बार टॉगल करना उस कॉन्फ़िगरेशन को चुपचाप फिर से लिख सकता है जिसे सही करने में आपने समय लगाया था।

प्रति-इंटरफ़ेस मान भी एक कारण से हैं। जानबूझकर प्रबंधित गेटवे ऐसे इंटरफ़ेस पर फ़ॉरवर्डिंग बंद रख सकता है जिसे कभी रूट नहीं करना चाहिए, तब भी जब होस्ट कहीं और फ़ॉरवर्ड कर रहा हो। इसीलिए जीवित इंटरफ़ेस पढ़ना ज़रूरी है और इसीलिए अकेला ग्लोबल मान पूरा जवाब नहीं है। ऐसे अपवाद को जानबूझकर लिया गया निर्णय मानिए, और लिखिए कि वह इंटरफ़ेस अलग क्यों है। वरना अगला इंजीनियर भलाई से उसे "ठीक" कर देगा।

सेटिंग को सही जगह स्थायी बनाएँ

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

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

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

इसे गलत औज़ार से मत सुधारिए

जब फ़ॉरवर्डिंग टूटी दिखी, तो फ़ायरवॉल फ्लश करने या masquerading जोड़ने का लालच होता है। दोनों में से कोई फ़ॉरवर्डिंग स्विच को संबोधित नहीं करता। फ़ॉरवर्डिंग स्थिति, फ़ॉरवर्ड करने की अनुमति, गंतव्य के लिए रूट और वापसी पथ — ये चार अलग आवश्यकताएँ हैं, और सिर्फ़ पहली ही sysctl है।

सही प्रवाह से भी परखें। गेटवे पर ही की गई माँग फ़ॉरवर्डिंग का ज़रा भी अभ्यास नहीं करती; वह स्थानीय रूप से बना ट्रैफ़िक है। सवाल यह है कि VPN क्लाइंट या LAN होस्ट से आने वाला पैकेट स्वीकार होकर आगे रूट होता है या नहीं, इसलिए परीक्षण गेटवे के पीछे से शुरू होना चाहिए।

IPv6 मामले को अलग रखें

यहाँ सब कुछ IPv4 है। IPv6 फ़ॉरवर्डिंग, राउटर घोषणाओं और accept_ra व्यवहार के अपने नियंत्रण हैं, और ipv4 पथ को ipv6 सेटिंग में कॉपी करने से ऐसी फ़ाइल बनती है जो विश्वसनीय दिखती है और कुछ उपयोगी नहीं करती। दोहरे स्टैक वाले गेटवे को दोनों सेट जानबूझकर कॉन्फ़िगर करने होंगे।

आखिरी जाँच: मान मिल जाने के बाद पुष्टि करें कि टनल का रूट गंतव्य के लिए चुना जा रहा है और वापसी पथ मौजूद है। बिना रूट वाले इंटरफ़ेस पर चालू फ़ॉरवर्डिंग अब भी काला छेद है, और वह विफलता क्लाइंट की तरफ़ से एक जैसी दिखती है।