लैपटॉप जागने के बाद OpenVPN क्यों मर जाता है?

स्लीप OpenVPN सत्र को मार सकता है और tun0 पीछे छोड़ सकता है। टनल जाँचें, फिर डिवाइस नहीं, systemd स्लीप हुक से यूनिट को फिर से शुरू करें।

मशीन को सस्पेंड करें, फिर जगाएँ, और उसके बाद किसी भी कॉन्फ़िगरेशन को छूने से पहले इसी क्रम में तीन चीज़ें जाँचें: क्या tun0 अब भी मौजूद है, क्या किसी आंतरिक पते का रूट अब भी उसे चुनता है, और क्या सर्वर अब भी इस पीयर को सूचीबद्ध करता है। जो डिवाइस स्लीप से बच जाता है जबकि रूट कहीं और इशारा करता है, वह अवशेष है, टनल नहीं। जब रूट सही हो और ट्रैफ़िक फिर भी मर जाए, तो खराबी टनल के ऊपर है और क्लाइंट को फिर से शुरू करने से कुछ नहीं बदलेगा। फिर से शुरू करना स्वचालित करना तभी अर्थपूर्ण है जब हाथ से किया गया परीक्षण दिखा दे कि इन तीन स्थितियों में से आपके पास कौन-सी है।

ip -br address show tun0
ip route get 10.20.0.10
journalctl -u openvpn-client@office -b --no-pager | tail -30

स्वचालित करने से पहले जागने की स्थिति दोहराएँ

सस्पेंड एन्क्रिप्टेड सत्र को डिवाइस हटाने से ज़्यादा बार समाप्त करता है। जो UDP प्रवाह टनल को जीवित रखता था वह रुक जाता है, सर्वर पीयर को गिरा सकता है, और क्लाइंट या तो इसे भाँपकर फिर जुड़ जाता है या ऐसा इंटरफ़ेस रखे रहता है जिसके पीछे कुछ नहीं है। सिर्फ़ इंटरफ़ेस जाँचना बहुत कम साबित करता है, क्योंकि पुराना डिवाइस ठीक वैसा ही दिखता है जैसा चलता हुआ डिवाइस जब तक पैकेट को उसके आर-पार जाना न पड़े। रूट लुकअप चलाएँ और टनल से होकर एक असली अनुरोध करें, फिर जागने के क्षण के आसपास का जर्नल पढ़ें।

अगर क्लाइंट खुद लौट आता है, तो हुक भरोसे की जगह अतिरिक्त झंझट जोड़ता है। अगर वह कभी ठीक नहीं होता, तो स्वचालन ही ईमानदार हल है।

systemd स्लीप हुक असल में कहाँ रहता है

कई पुराने गाइड /etc/pm/sleep.d की ओर इशारा करते हैं, जो pm-utils की मालिकाना डायरेक्टरी है और systemd-आधारित सस्पेंड उससे कभी परामर्श नहीं लेता। systemd हुक /usr/lib/systemd/system-sleep/ और /etc/systemd/system-sleep/ से पढ़ता है, पहले चरण और फिर क्रिया सौंपता है, इसलिए pre और post ही ऐसे मान हैं जिन पर हुक शाखा बनाता है। पैकेज की फ़ाइल संपादित करने के बजाय स्थानीय प्रति /etc के अंतर्गत रखें, और याद रखें कि स्क्रिप्ट संक्रमण के बीच root के रूप में चलती है, इसलिए उसे जल्दी लौटना चाहिए।

#!/bin/sh
case "$1" in
  post)
    systemctl --no-block try-restart [email protected]
    ;;
esac
exit 0

try-restart यूनिट को तभी छूता है जब वह पहले से सक्रिय हो, इसलिए जिस टनल को आपने जानबूझकर बंद किया वह जागने के दौरान भी बंद रहती है। --no-block हुक को क्लाइंट के बातचीत करते समय इंतज़ार करने से रोकता है, जो तब मायने रखता है जब नेटवर्क अभी ऊपर न हो। दोनों फ़्लैग मिलकर ऐसे हुक का अर्थ हैं जो पूरे जागने के क्रम को रोकने के बजाय चुपचाप विफल होता है। जब यूनिट पहले से रुकी हो तो कुछ भी नहीं होता, जो ठीक वही परिणाम है जो वहाँ आप चाहते हैं।

सेवा बहाल करें, tun0 को अकेला छोड़ें

tun0 को हाथ से नीचे करने से डेमन ऐसे इंटरफ़ेस की निगरानी करता रह जाता है जो अब उसका नहीं है, और अगला स्थिति परिवर्तन भ्रमित करने वाली त्रुटियाँ पैदा करता है। इंटरफ़ेस के बजाय सेवा या उसकी कनेक्शन प्रोफ़ाइल को लक्षित करें; पहले यूनिट का सटीक नाम जाँचें, क्योंकि डिस्ट्रिब्यूशन पैकेज, OpenVPN 3 और NetworkManager सभी अलग चुनते हैं। NetworkManager प्रोफ़ाइल तब लौटती है जब वह कनेक्शन फिर से चलाया जाता है, इसलिए systemd यूनिट वहाँ लक्ष्य नहीं है। तंत्र जो भी हो, वह वही क्रिया होनी चाहिए जिसे आपने हाथ से सत्यापित किया।

फिर से शुरू करना उन रूटों को दोबारा स्थापित करता है जिन्हें क्लाइंट ने जुड़ते समय धकेला था। ज़्यादातर जागरण यही चाहते हैं। जिस मशीन में आपने अपने रास्ते जोड़े हैं वह नहीं, इसलिए यह मानने के बजाय कि बहाली ने उन्हें लौटा दिया है, उन्हें फिर से जाँचें, और उन्हें वहाँ लिखें जहाँ अगला जागरण उन्हें पा सके।

जिस समय को आप नियंत्रित नहीं कर सकते उससे निपटें

वायरलेस एसोसिएशन और DHCP अक्सर हुक चलने के बाद पूरे होते हैं, इसलिए सर्वर तक कोई रास्ता न होने पर फिर से शुरू करना विफल हो सकता है। उस पते के लिए थोड़ी देर प्रतीक्षा करें, एक बार फिर कोशिश करें और परिणाम लॉग करें।

नाम विश्लेषण एक अलग दौड़ है, क्योंकि डेस्कटॉप का नेटवर्क स्टैक टनल पहले से ऊपर होने के बाद DNS बहाल कर सकता है। काम करने वाले रूट से अनुमान लगाने के बजाय resolvectl query internal.example के साथ लुकअप अलग से जाँचें। जो टनल सही रूट करती है और कुछ भी हल नहीं करती, वह DNS समस्या है, हुक की समस्या नहीं।

जर्नल में चरण, यूनिट का नाम और परिणाम लिखकर हुक के निर्णय को दृश्य रखें। मशीन के नोट्स में लिखें कि आपने कौन-सा जागरण परीक्षण चलाया, ताकि काम करने वाली बहाली को भाग्यशाली बहाली से अलग पहचाना जा सके। सेवा वापस लाने वाली सबसे कम बाधा डालने वाली क्रिया चुनें, और जो क्लाइंट खुद ठीक हो जाता है उसे ऐसा करने दें। पूरी तरह फिर से शुरू करना चालू सत्र गिरा देता है, जो दिन में कई बार जागने वाले लैपटॉप पर असली लागत है।

संबंधित लेख