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 देखें। अगर दूसरा रोकना साफ़ कर देता है, तो पहले की समस्या कॉन्फ़िगरेशन नहीं, ज़बरदस्ती निकास थी।