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 हेर्नुहोस्। यदि दोस्रो रोकावटले सफा गर्यो भने, अघिल्लो समस्या कन्फिगरेसन होइन, जबरजस्ती निस्कासन थियो।