SIGKILL नंतर OpenVPN DNS शिल्लक राहते: आधी मालक तपासा

OpenVPN क्लायंट मारल्यानंतर DNS सोडवणे थांबते, आणि पहिली प्रवृत्ती /etc/resolv.conf पुन्हा लिहिण्याची असते. तो बदल चालू असलेला रिझोल्व्हर तोडू शकतो, तर खरी जुनी स्थिती दुसरीकडे असते. आधी ठरवायचा प्रश्न म्हणजे टनेलने बसवलेल्या DNS सेटिंग्जचा मालक कोण आहे, आणि स्वच्छता वगळणारे बाहेर पडणे खरोखर महत्त्वाचे होते का.

तीन अटी दुरुस्ती ठरवतात: प्रक्रिया संपवणारा सिग्नल, सेटिंग्ज घेणारा रिझोल्व्हर घटक, आणि टनेल लिंक अजून आहे का. याच क्रमाने उत्तर द्या आणि दुरुस्ती सहसा कोणतीही जागतिक फाइल न घेता येते.

कोणत्या प्रकारचे बाहेर पडणे झाले ते ठरवा

Community आवृत्तीत OpenVPN मध्ये SIGINT आणि SIGTERM दोन्ही शांत बाहेर पडण्याच्या विनंत्या आहेत. SIGKILL पकडता येत नाही: ते अडवता किंवा हाताळता येत नाही, त्यामुळे कोणत्याही शटडाउन रूटिनला चालण्याची संधी मिळत नाही. समोरच्या टर्मिनलमध्ये सामान्य Ctrl+C SIGINT निर्माण करते, तर वाट पाहणे सोडणारा पर्यवेक्षक सहसा SIGKILL पर्यंत वाढतो. फरक महत्त्वाचा आहे कारण फक्त दुसरेच प्रकरण हुक वगळले गेले याची खात्री देते.

screen किंवा tmux मध्ये चालवल्याने Ctrl+C कोणता सिग्नल पाठवते ते बदलत नाही. टर्मिनल सहसा काय करते त्याऐवजी प्रक्रियेने खरोखर काय घेतले ते तपासा.

जेव्हा सेवा किंवा कनेक्शन मॅनेजर टनेल चालवतो, तेव्हा pid मारण्याऐवजी ते एक कनेक्शन त्याच्या मालकाद्वारे थांबवा. मॅनेजर प्रक्रिया पुन्हा वर आणू शकतो, ज्यामुळे तुमच्याकडे नवीन टनेल आणि गोंधळलेली रिझोल्व्हर स्थिती राहते. स्वतंत्र प्रक्रियेला स्वच्छता चालण्यासाठी फक्त सामान्य थांबवण्याची विनंती पुरते.

रिझोल्व्हर कोणाचे आहे ते ठरवा

systemd-resolved, resolvconf शैलीतील स्क्रिप्ट आणि साधे फाइल पुनर्लेखन हे तीन वेगळे मालक आहेत. पहिले प्रति-लिंक सेटिंग्ज मेमरीत ठेवते आणि इंटरफेस गायब झाल्यावर त्या टाकून देते. दुसरे काही काढेपर्यंत टिकणाऱ्या नोंदी ठेवते. तिसरे फाइल लिहिते आणि पुनर्संचयन ती लिहिणाऱ्यावर सोडते.

दुरुस्तीची आज्ञा निवडण्यापूर्वी मालक ओळखा. यापैकी कोणते वापरात आहे यानुसार त्याच लक्षणाला तीन वेगळी बरोबर उत्तरे आहेत.

NetworkManager ने व्यवस्थापित VPN आधीच रिझोल्व्हर बदलांचे मालक असू शकते. त्यावर दुसरा सहाय्यक जोडल्यास एकाच लिंकसाठी स्पर्धा करणारे दोन मालक तयार होतात, आणि हरलेल्याची स्थिती पुढील पुन्हा जोडणीत पुन्हा दिसते. मॅनेजर जबाबदार असेल, तर सेटिंग स्क्रिप्टमध्ये नाही, मॅनेजरमध्ये दुरुस्त करा.

down हुक काय करू शकते आणि काय करू शकत नाही

स्क्रिप्ट down TUN/TAP उपकरण बंद झाल्यानंतर एकदा चालते. जोडल्यास down-pre तो क्रम उलटतो आणि उपकरण अजून असतानाच स्क्रिप्ट चालवतो, जे जिवंत लिंक आवश्यक असलेल्या सहाय्यकांना लागते.

कोणतेही निर्देश हुक SIGKILL नंतर चालवत नाहीत. अधिकारही down-pre ने पुनर्संचयित होत नाहीत: जर डेमॉन user किंवा group वर उतरला किंवा chroot मध्ये गेला, तर हुक ते जे प्रवेश सोडते त्यासह चालते. बोलावलेला हुक तरीही रिझोल्व्हर अद्ययावत करण्यात अयशस्वी होऊ शकतो. OpenVPN संदर्भ सिग्नल आणि कॉलबॅक जीवनचक्र व्यापतो.

प्रक्रियेच्या निर्गमन स्थितीशेजारी हुकची स्वतःची त्रुटी तपासा. गहाळ स्वच्छता आणि अयशस्वी स्वच्छता रिझोल्व्हरमध्ये सारखी आणि लॉगमध्ये वेगळी दिसते.

खरोखर शिल्लक राहिलेली स्थिती तपासा

systemd-resolved वापरणाऱ्या प्रणालीवर, resolvectl status कोणती लिंक अजूनही VPN चे DNS सर्व्हर किंवा राउटिंग डोमेन वाहते ते दाखवते. ती लिंक गेलेल्या कनेक्शनची असू शकते, किंवा अजून वर असलेल्या दुसऱ्या टनेलची.

नाहीशी होणारा इंटरफेस आपली प्रति-लिंक संरचना सोबत घेऊन जातो, त्यामुळे वगळलेला हुक स्वच्छ DNS सोबत राहू शकतो. जर लिंक अजून नोंदणीकृत असेल आणि फक्त थांबवलेल्या कनेक्शनच्या मालकीची असेल, तर मालक मॅनेजरने ती काढून टाकावी. जर जुन्या स्क्रिप्टने जागतिक रिझोल्व्हर फाइल पुन्हा लिहिली असेल, तर त्याऐवजी त्या स्क्रिप्टचे नोंदवलेले पुनर्संचयन पाऊल शोधा.

दुसरी लिंक चोरल्याशिवाय पुनर्प्राप्त करा

जेव्हा प्रति-लिंक सेटिंग्ज तुमच्या व्यवस्थापनात असतात, resolvectl revert लिंकचे नाव घेते आणि त्या इंटरफेससाठी रनटाइम DNS संरचना पुसते. हे प्रोफाइल संपादन नाही तर रनटाइम क्रिया आहे, त्यामुळे कायमस्वरूपी कनेक्शन संरचना अस्पर्शित राहते. चुकीची लिंक सांगितल्यास चालू असलेल्या टनेलचे DNS पुसाल, म्हणूनच नाव स्थितीच्या आउटपुटमधून येते.

संपादनापूर्वी खात्री करा की /etc/resolv.conf व्यवस्थापित सिम्बॉलिक लिंक आहे, नंतर क्लायंट पुन्हा एकदा सामान्यपणे थांबवा आणि पुन्हा DNS पाहा. जर दुसऱ्या थांबवण्याने स्वच्छ झाले, तर आधीची समस्या संरचना नाही तर सक्तीचे बाहेर पडणे होते.