लॅपटॉप जागल्यानंतर OpenVPN का मरतो?

मशीन सस्पेंड करा, पुन्हा जागे करा, आणि नंतर कोणतेही कॉन्फिगरेशन हाताळण्यापूर्वी याच क्रमाने तीन गोष्टी तपासा: 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 समस्या आहे, हुकची समस्या नाही।

जर्नलमध्ये टप्पा, युनिटचे नाव आणि निकाल लिहून हुकचा निर्णय दृश्य ठेवा। मशीनच्या नोट्समध्ये तुम्ही कोणती जागरण चाचणी चालवली ते लिहा, म्हणजे कार्यरत पुनर्प्राप्ती नशीबवान पुनर्प्राप्तीपासून वेगळी करता येईल। सेवा परत आणणारी सर्वात कमी अडथळा आणणारी क्रिया निवडा, आणि स्वतः सावरणाऱ्या क्लायंटला ते करू द्या। पूर्ण पुन्हा सुरू करणे सुरू असलेली सत्रे पाडते, जो दिवसातून अनेक वेळा जागणाऱ्या लॅपटॉपवर खरा खर्च आहे।