तुमचा VPN इंटरफेस वारंवार त्याचा firewalld झोन का सोडतो

तुम्ही tun0 योग्य झोनमध्ये जोडता, अनुप्रयोग काम करू लागतो, आणि पुढील पुनर्जोडणीत दुरुस्ती वाफ होऊन उडते। तीच आज्ञा पुन्हा चालवल्यास काम करते, ज्यामुळे firewalld विसरला असे वाटते। तो विसरला नाही; त्या इंटरफेसवर अधिक जोरदार हक्क असलेल्या एखाद्या गोष्टीने तो पुन्हा नेमला।

इंटरफेस पुन्हा तयार होईपर्यंत झोन टिकतो

इंटरफेससाठी firewalld झोनची नेमणूक ही एक बाइंडिंग आहे, आणि बाइंडिंग आता अस्तित्वात असलेल्या इंटरफेस ऑब्जेक्टशी बांधलेल्या असतात। उपकरण फोडून पुन्हा तयार करणारा VPN क्लायंट नवीन ऑब्जेक्ट निर्माण करतो, आणि नवीन नेमणूक करणारा घटक जे सांगतो तिथून सुरू होतो। लक्षण प्रत्येक पॅकेटला नाही तर प्रत्येक पुनर्जोडणीला पुनरावृत्त होण्याचे कारण हेच।

तेच तर्क रीबूटचे वर्तन स्पष्ट करतात: रनटाइम बाइंडिंग रीस्टार्ट टिकत नाहीत, आणि कायमची बाइंडिंग फक्त firewalld स्वतःची मानतो त्या उपकरणांनाच लागू होतात।

काहीही बदलण्यापूर्वी झोन कोणता घटक नेमतो ते शोधा।

काहीही बदलण्यापूर्वी तीन गोष्टी वाचा

इंटरफेसचा सध्याचा झोन, त्यांच्या इंटरफेससह सक्रिय झोन, आणि तुम्ही हेतू असलेल्या झोनची कायमची इंटरफेस यादी नोंदवा। त्या क्वेरी बदलापूर्वी, एका पुनर्जोडणीनंतर आणि एका रीबूटनंतर चालवा। तीन निकालांची तुलना केल्यास बाइंडिंग बदलली जात आहे, दुर्लक्षिली जात आहे, की फक्त उशिरा लागू होत आहे हे कळते। कायमच्या यादीत उपकरणाचे नाव आधीच असल्यास आणि रनटाइम झोन वेगळे सांगत असल्यास, काहीतरी तुमचा बदल मागे टाकत आहे।

प्रत्येक टप्प्यावर उपकरणाचे खरे नावही नोंदवा, कारण आज tun0 वर उतरणारे टनेल उद्या tun1 वर उतरू शकते।

सामान्य नावावर साठवलेले बाइंडिंग ओळखपरीक्षण नाही, आणि दोन मिनिटांची नोंद एका तासाचा अंदाज वाचवते।

जेव्हा NetworkManager जोडणीचा मालक असतो

जर NetworkManager VPN जोडणी व्यवस्थापित करत असेल, तर त्याची प्रोफाइल झोन वाहते आणि जोडणी सक्रिय होताच तो firewalld ला देते। त्याच उपकरणासाठी firewalld चे कायमचे इंटरफेस बाइंडिंग तेव्हा दुर्लक्षिले जाऊ शकते, कारण मालक NetworkManager आहे। झोन जोडणीवर सेट करा, आणि तुम्ही VPN प्रोफाइल संपादित करत आहात, नाते नसलेली भौतिक जोडणी किंवा तात्पुरती नोंद नाही याची खात्री करा।

तो गुणधर्म बदलल्यास सक्रिय जोडणीवर लगेच परिणाम होऊ शकतो।

व्यवस्थापनाचा मार्ग उपलब्ध ठेवा आणि लागू करण्यापूर्वी लक्ष्य झोनचे धोरण वाचा। ifcfg फाइलचे ZONE क्षेत्र संपादित करणे फक्त तिथेच योग्य आहे जिथे ती फाइल अजूनही संरचनेचा स्रोत आहे।

जेव्हा firewalld बाइंडिंगचा मालक असतो

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

इंटरफेसचे नाव गतिशील असल्यास, नाव आधी हिसकावणाऱ्या टनेलशी शर्यत करण्याऐवजी जोडणीच्या जीवनचक्रात नेमणूक टिकवा।

फक्त अनुप्रयोग चालावा म्हणून इंटरफेस trusted मध्ये टाकू नका।

रीलोड, पुनर्जोडणी आणि रीबूटची चाचणी करा

बदल तिन्ही टिकून राहिल्यावरच पूर्ण होतो।

आधी रीलोड करा, कारण तिथेच फक्त-रनटाइम संपादने नाहीशी होतात। मग टनेल पुन्हा जोडा, कारण तिथेच बदललेला इंटरफेस त्याचे बाइंडिंग गमावतो। मग रीबूट करा, कारण तिथेच मालकाची विसंगती शेवटी दिसते। प्रत्येक टप्प्यावर झोन नोंदवा आणि तुम्ही लिहिलेल्या हेतूशी तुलना करा, आणि कोणत्या पायरीने फरक निर्माण केला ते नोंदवा।

झोन बरोबर असूनही अनुप्रयोग अजूनही अयशस्वी होत असल्यास, समस्या सदस्यत्वात नाही तर झोनच्या नियमांमध्ये किंवा स्रोत-आधारित वर्गीकरणात आहे। जोडण्या आणि इंटरफेसबद्दल firewalld चे दस्तऐवज मालकी कशी काम करायला हवी याचा संदर्भ आहे।

मालक, मूल्य आणि अपेक्षित निकाल रनबुकमध्ये लिहा, आणि पुढील पुनर्नेमणूक स्पष्ट करण्यायोग्य होईल।