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 मध्ये एकत्र ठेवा। पुढे हे घेणाऱ्याला मूल्य वाचता आले पाहिजे, त्याचा मालक कोण आहे हे दिसले पाहिजे, आणि समस्या टिकाऊपणाची आहे की मार्गाच्या उर्वरित भागाची हे एका मिनिटात ठरवता आले पाहिजे।