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 मा सँगै राख्नुहोस्। अब यो लिनेले मान पढ्न, कसको मालिक हो देख्न, र समस्या टिकाउपनको हो कि बाटोको बाँकी भागको हो एक मिनेटभित्र निर्णय गर्न सक्नुपर्छ।