VPN गेटवे के पुनः आरंभ के बाद भी IPv4 फ़ॉरवर्डिंग बनी रहे

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

गेटवे तक पहुँचना फ़ॉरवर्डिंग के बराबर नहीं है

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

लिखें कि क्लाइंट पैकेट किस इंटरफ़ेस पर आता है और आगे का रास्ता किस इंटरफ़ेस से निकलता है। दोनों एक ही नेमस्पेस के हैं, और उसी नेमस्पेस में वह सेटिंग है जो मायने रखती है।

मान वहीं पढ़ें जहाँ पैकेट वास्तव में हैं

होस्ट नेमस्पेस में रूट करने वाले गेटवे पर, एक ही कमांड सवाल का जवाब देती है: sysctl net.ipv4.ip_forward। जब इनग्रेस और आगे का रास्ता किसी नामित नेमस्पेस में रहते हैं, तो उस नेमस्पेस से पूछें: ip netns exec vpn-gw sysctl net.ipv4.ip_forward। होस्ट का मान नेमस्पेस के मान का विकल्प नहीं है, और होस्ट पर एक होना किसी चीज़ का सबूत नहीं है।

हर रूटिंग संदर्भ में ऐसा लेबल नहीं होता जिसे आप ip netns को दे सकें। कंटेनर रनटाइम और सेवाएँ ऐसे नेमस्पेस बनाते हैं जो कभी मित्रवत नाम से पंजीकृत नहीं होते, और उनके लिए आप रनटाइम के निरीक्षण उपकरण इस्तेमाल करते हैं। vpn-gw की जगह असली नाम या उसी संदर्भ तक पहुँचने वाला रनटाइम तंत्र रखें, और होस्ट स्तर पर अनुमान लगाना बंद करें।

सेटिंग को एक ही मालिक दें

पारंपरिक systemd होस्ट गेटवे पर, टिकाऊ रूप एडमिनिस्ट्रेटर द्वारा चुने गए नाम वाली drop-in फ़ाइल है, जैसे /etc/sysctl.d/60-vpn-forwarding.conf, जिसमें net.ipv4.ip_forward = 1 होता है। फ़ाइल लिखें, फिर उसी विशेष फ़ाइल को लोड करें ताकि जीवंत स्थिति भी बदले: sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, और उसके बाद वापस पढ़कर जाँचें। फ़ाइल का नाम एक उदाहरण है, आरक्षित VPN पथ नहीं, और शुरुआती संख्या मायने रखती है क्योंकि बाद में क्रमबद्ध होने वाली फ़ाइलें जीतती हैं।

प्राथमिकता वह जगह है जहाँ टिकाऊपन चुपचाप टूटता है। वितरण लोडर के साथ-साथ अपनी drop-in भी जाँचें, क्योंकि procps sysctl --system अंत में /etc/sysctl.conf भी पढ़ता है, जबकि systemd का sysctl.d क्रम पूरी तरह अलग अनुक्रम है। बाद का आवंटन उसी कुंजी को तुरंत वापस सेट कर सकता है, जिससे आपकी फ़ाइल सही और प्रभावी मान गलत रह जाता है। उस बहस को जीतने के लिए मौजूदा एडमिनिस्ट्रेटर फ़ाइल को अधिलेखित न करें; मालिक खोजें और वहीं बदलें।

बूट के बाद बनाया गया नेमस्पेस होस्ट drop-in से बिल्कुल नियंत्रित नहीं होता। उसकी सेटिंग उसी की होती है जो उसे बनाता है, चाहे कंटेनर रनटाइम हो या नेमस्पेस की प्रोविज़निंग यूनिट। सवाल से बचने के लिए कंटेनर को व्यापक होस्ट विशेषाधिकार देना सही मालिक पहचानने में दस मिनट लगाने से बुरा सौदा है।

स्विच पलटने से पहले जानें कि उसकी क़ीमत क्या है

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

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

टिकाऊपन साबित करें, फिर बाकी रास्ता जाँचें

चार पलों पर मान वापस पढ़ें: बदलाव के ठीक बाद, VPN इंटरफ़ेस आने के बाद, दोबारा कनेक्ट होने के बाद, और नियोजित पुनः आरंभ के बाद। इनमें से किसी भी बिंदु पर लौटने वाले मान का दूसरा मालिक है, और एक और एकबारगी लेखन उसे अगले रीबूट तक ही छिपाता है।

फ़ॉरवर्डिंग सक्षम होने पर भी तीन चीज़ें जाँचनी बाकी रहती हैं। क्लाइंट को गंतव्य तक मार्ग चाहिए, गेटवे को आगे का मार्ग और उसे इस्तेमाल करने की अनुमति चाहिए, और गंतव्य को क्लाइंट के टनल पते तक वापसी रास्ता चाहिए। निजी रूट किया गया LAN अपने आप NAT नहीं माँगता, इसलिए तीनों में से कौन-सा गायब है यह जानने से पहले masquerading न जोड़ें, और गेटवे से नहीं बल्कि इच्छित क्लाइंट से जाँचें, क्योंकि गेटवे पर शुरू हुआ अनुरोध उस फ़ॉरवर्डिंग रास्ते को कभी नहीं छूता जिसे आपने अभी सक्षम किया है। IPv6 की अपनी फ़ॉरवर्डिंग और रूटिंग नीति है, इसलिए काम करने वाला IPv4 परीक्षण उसके बारे में कुछ नहीं कहता।

drop-in पथ, नेमस्पेस का मालिक और वापस पढ़ने वाली कमांड को runbook में साथ रखें। अगली बार इसे उठाने वाले को मान पढ़ना, यह देखना कि उसका मालिक कौन है, और एक मिनट में तय करना आना चाहिए कि समस्या टिकाऊपन की है या बाकी रास्ते की।