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 सेटिङमा प्रतिलिपि गर्दा विश्वसनीय देखिने तर उपयोगी केही नगर्ने फाइल बन्छ। दोहोरो-स्ट्याक गेटवेले दुवै सेट जानाजान कन्फिगर गर्नुपर्छ।

अन्तिम जाँच: मानहरू मिलेपछि टनेलको रुट गन्तव्यका लागि छानिएको छ र फर्किने मार्ग अवस्थित छ भनी पुष्टि गर्नुहोस्। रुट नभएको इन्टरफेसमा सक्रिय फर्वार्डिङ अझै कालो प्वाल हो, र त्यो असफलता क्लाइन्टको तर्फबाट उस्तै देखिन्छ।