OpenVPN में persist-tun और persist-key वास्तव में क्या बचाते हैं
दोनों विकल्प एक जीवित प्रक्रिया के भीतर नरम रीस्टार्ट को कवर करते हैं। वे रोकने के बाद इंटरफ़ेस नहीं रखते, और वे ट्रैफ़िक रोकने की नीति नहीं हैं।
सेवा रोकने से persist-tun सेट होने पर भी इंटरफ़ेस हट जाता है। यह विकल्प दस्तावेज़ के अनुसार काम कर रहा है, विफल नहीं हो रहा। विकल्प चल रही प्रक्रिया के भीतर एक रीस्टार्ट पथ का वर्णन करता है, और systemctl stop वह पथ नहीं है।
दोनों नाम साथ पढ़ें और डिज़ाइन स्पष्ट हो जाता है। एक डिस्क्रिप्टर रखता है, दूसरा कुंजी सामग्री रखता है, और दोनों इसलिए मौजूद हैं कि विशेषाधिकार छोड़ने के बाद क्या होता है।
दो संसाधन और वह रीसेट जिसके वे हैं
OpenVPN दो सामान्य स्थितियों में अपने रीस्टार्ट का संकेत देता है। स्पष्ट SIGUSR1 ऐसा करता है, और मृत साथी द्वारा ट्रिगर किया गया ping-restart भी वही करता है। दोनों प्रक्रिया को जीवित रखते हैं और कनेक्शन सेटअप फिर से चलाते हैं, और यहीं विकल्प अपनी जगह कमाते हैं।
| Event | TUN/TAP device | Key and auth files | Addresses and routes | up/down hooks |
|---|---|---|---|---|
Soft reset, from SIGUSR1 or from a ping-restart the daemon sends itself | survives only with persist-tun | survive only with persist-key | survive with the device, otherwise rebuilt | run again only when restart hooks are enabled |
Configuration reload, SIGHUP | recreated | re-read from disk | rebuilt once the device returns | run again |
| Service stop | lost | re-read at the next start | removed | run at the next start |
केवल नरम-रीसेट पंक्ति ही वह चीज़ है जो ये दो विकल्प बदलते हैं, और जो काम वे छोड़ देते हैं वह व्यस्त लिंक पर महँगा हिस्सा है। डिवाइस को फिर से खोलने से उससे जुड़े पते और रूट टूट जाते हैं, और उन्हें फिर से बनाने पर वे पैकेट गिर सकते हैं जो रीस्टार्ट शुरू होने पर रास्ते में थे। रोकना उन्हीं ऑब्जेक्ट को बचाने के किसी विकल्प के बिना नष्ट कर देता है।
ये विकल्प आखिर मौजूद क्यों हैं
सख्त किया गया OpenVPN सर्वर आमतौर पर root के रूप में शुरू होता है, अपनी कुंजियाँ और अपना डिवाइस खोलता है, फिर बिना विशेषाधिकार वाले उपयोगकर्ता पर आ जाता है। उस बदलाव के बाद कुछ क्रियाएँ बस चली जाती हैं। मोड 0600 वाली कुंजी फ़ाइल पढ़ना, नेटवर्क इंटरफ़ेस बनाना या रूट बदलना सब अस्वीकार हो सकते हैं।
persist विकल्पों के बिना, ping-restart ट्रिगर करने के लिए पर्याप्त देर चुप रहने वाला साथी ठीक उन्हीं क्रियाओं को बाध्य करता। कॉन्फ़िगरेशन में कुछ न बदले होने पर भी पुनः कनेक्शन विफल हो जाता। प्रक्रिया बिना कारण मरती दिखती, और लॉग नेटवर्क त्रुटि के बजाय अनुमति त्रुटि दिखाता।
इनके साथ, नरम रीस्टार्ट वही दोबारा उपयोग करता है जो विशेषाधिकार प्राप्त चरण पहले ही प्राप्त कर चुका है। कोई जादू नहीं है और प्रक्रिया कुछ भी नहीं बचाती। संसाधनों का अधिग्रहण बस टाल दिया जाता है।
पहली त्रुटि पढ़ें, आखिरी नहीं
जब कोई रीस्टार्ट विफल हो, तो आखिरी के बजाय पहली त्रुटि पढ़ें। एक सुरक्षित कुंजी, एक auth फ़ाइल, एक इंटरफ़ेस ioctl और एक बाहरी हुक चार अलग संसाधन हैं। एक को बनाए रखना बाकी तक पहुँच के बारे में कुछ नहीं कहता। फ़ायरवॉल टूल को कॉल करने वाले हुक को अभी भी वही विशेषाधिकार चाहिए जो वह टूल मांगता है।
हुक का अपना स्विच होता है। OpenVPN मैनुअल persist विकल्पों को up-restart के साथ जोड़ता है, जो तय करता है कि रीस्टार्ट के बाद up और down स्क्रिप्ट फिर चलेंगी या नहीं। इसलिए ऊपर टिका इंटरफ़ेस आपको इस बारे में कुछ नहीं बताता कि आपका रिज़ॉल्वर एकीकरण ताज़ा हुआ या नहीं।
# which restart path just happened?
journalctl -u openvpn-client@office --since '10 min ago' | grep -E 'SIGUSR1|ping-restart|Restart pause|NOTE:'
# did the interface survive, and do its routes still exist?
ip -brief link show tun0
ip route show dev tun0ये दो कमांड दोनों विफलता विधियों को सेकंडों में अलग कर देते हैं। मौजूद पर रूट गायब वाला इंटरफ़ेस हुक या रूट की समस्या है। गायब हो गया इंटरफ़ेस इसका मतलब है कि प्रक्रिया वास्तव में समाप्त हो गई।
रखा गया इंटरफ़ेस kill switch नहीं है
अगर आवश्यकता यह है कि ट्रैफ़िक कभी सुरंग से बाहर न जाए, तो रखा गया डिवाइस वह नहीं देता। दूसरे पता परिवार के रूट, दूसरा डिफ़ॉल्ट रूट, और वह स्थिति जब प्रक्रिया पूरी तरह बाहर निकल जाए, सब विकल्प के दायरे से बाहर रहते हैं।
दोनों आवश्यकताओं को अलग-अलग संभालें। पुनः कनेक्शनों के बीच सुरंग ऑब्जेक्ट रखना डेमॉन के लिए सुविधा है। सुरंग बंद होने पर बाहर जाना रोकना अपने नियमों और अपनी परीक्षा वाली फ़ायरवॉल नीति है। इन्हें मिलाने से ऐसा कॉन्फ़िग बनता है जो रक्षात्मक दिखता है और सर्वोत्तम-प्रयास पुनः कनेक्शन की तरह व्यवहार करता है।
निदान से पहले घटना का नाम लें। नरम रीस्टार्ट, विफल कनेक्शन प्रयास और सेवा रोकना तीन व्यवहारों वाली तीन घटनाएँ हैं, और केवल पहली ही वह है जिसका वर्णन ये विकल्प करते हैं।