आपका VPN इंटरफ़ेस बार-बार अपना firewalld ज़ोन क्यों छोड़ देता है

आप tun0 को सही ज़ोन में जोड़ते हैं, एप्लिकेशन काम करने लगता है, और अगले पुनःकनेक्शन पर सुधार भाप बनकर उड़ जाता है। वही कमांड फिर से चलाने पर काम करता है, जिससे लगता है कि firewalld भूल गया। वह भूला नहीं; उस इंटरफ़ेस पर अधिक मज़बूत दावा रखने वाली कोई चीज़ ने उसे फिर से सौंप दिया।

ज़ोन तब तक टिकता है जब तक इंटरफ़ेस फिर से न बने

किसी इंटरफ़ेस के लिए firewalld ज़ोन का आवंटन एक बाइंडिंग है, और बाइंडिंग इंटरफ़ेस ऑब्जेक्ट से जुड़ी होती हैं जैसा वह अभी मौजूद है। जो VPN क्लाइंट डिवाइस को तोड़कर फिर बनाता है वह नया ऑब्जेक्ट पैदा करता है, और नया वहीं से शुरू होता है जो आवंटन करने वाला घटक कहता है। इसी कारण लक्षण हर पैकेट पर नहीं, हर पुनःकनेक्शन पर दोहराता है।

यही तर्क रीबूट के व्यवहार को समझाता है: रनटाइम बाइंडिंग रीस्टार्ट के बाद नहीं टिकतीं, और स्थायी बाइंडिंग केवल उन्हीं डिवाइसों पर लागू होती हैं जिन्हें firewalld अपना मानता है।

कुछ भी बदलने से पहले पता करें कि ज़ोन कौन सा घटक आवंटित करता है।

कुछ भी बदलने से पहले तीन चीज़ें पढ़ें

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

हर चरण पर डिवाइस का असली नाम भी दर्ज करें, क्योंकि आज tun0 पर उतरने वाली टनल कल tun1 पर उतर सकती है।

किसी सामान्य नाम पर सहेजी गई बाइंडिंग पहचान की जाँच नहीं है, और दो मिनट का रिकॉर्ड एक घंटे का अनुमान बचाता है।

जब NetworkManager कनेक्शन का मालिक हो

यदि NetworkManager VPN कनेक्शन प्रबंधित करता है, तो उसकी प्रोफ़ाइल ज़ोन रखती है और कनेक्शन सक्रिय होने पर उसे firewalld को देती है। तब उसी डिवाइस के लिए firewalld की स्थायी इंटरफ़ेस बाइंडिंग को अनदेखा किया जा सकता है, क्योंकि मालिक NetworkManager है। ज़ोन को कनेक्शन पर सेट करें, और पुष्टि करें कि आप VPN प्रोफ़ाइल संपादित कर रहे हैं, कोई असंबंधित भौतिक कनेक्शन या अस्थायी रिकॉर्ड नहीं।

उस गुण को बदलने से सक्रिय कनेक्शन पर तुरंत असर पड़ सकता है।

प्रबंधन का एक मार्ग उपलब्ध रखें और लागू करने से पहले गंतव्य ज़ोन की नीति पढ़ें। ifcfg फ़ाइल के ZONE फ़ील्ड को संपादित करना केवल वहीं सही है जहाँ वह फ़ाइल अभी भी कॉन्फ़िगरेशन का स्रोत है।

जब firewalld बाइंडिंग का मालिक हो

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

यदि इंटरफ़ेस का नाम गतिशील है, तो नाम पहले हड़पने वाली टनल से दौड़ लगाने के बजाय कनेक्शन के जीवनचक्र भर आवंटन बनाए रखें।

केवल एप्लिकेशन चलाने के लिए इंटरफ़ेस को trusted में मत गिराइए।

रीलोड, पुनःकनेक्शन और रीबूट की जाँच करें

बदलाव तभी पूरा होता है जब वह तीनों झेल जाए।

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

यदि ज़ोन सही है और एप्लिकेशन फिर भी विफल होता है, तो समस्या सदस्यता में नहीं, ज़ोन के नियमों या स्रोत-आधारित वर्गीकरण में है। कनेक्शन और इंटरफ़ेस पर firewalld का दस्तावेज़ इस बात का संदर्भ है कि स्वामित्व कैसे काम करना चाहिए।

मालिक, मान और अपेक्षित परिणाम रनबुक में लिखें, और अगला पुनःआवंटन व्याख्या योग्य होगा।