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 सेटिंगमध्ये कॉपी केल्याने विश्वासार्ह दिसणारी पण उपयुक्त काहीही न करणारी फाइल तयार होते. दुहेरी-स्टॅक गेटवेला दोन्ही संच जाणीवपूर्वक कॉन्फिगर करावे लागतात.

शेवटची तपासणी: मूल्ये जुळल्यानंतर टनेलचा राउट गंतव्यासाठी निवडला जातो आणि परतीचा मार्ग अस्तित्वात आहे याची खात्री करा. राउट नसलेल्या इंटरफेसवर सुरू असलेले फॉर्वर्डिंग तरीही काळे भोक आहे, आणि ते अपयश क्लायंटच्या बाजूने सारखेच दिसते.