ल्यापटप जागेपछि 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 समस्या हो, हुकको समस्या होइन।

जर्नलमा चरण, युनिटको नाम र नतिजा लेखेर हुकको निर्णय देखिने बनाउनुहोस्। मेसिनका नोटमा तपाईंले कुन जाग्ने परीक्षण चलाउनुभयो लेख्नुहोस्, ताकि काम गर्ने पुनःस्थापनालाई भाग्यमानीबाट छुट्याउन सकियोस्। सेवा फर्काउने सबैभन्दा कम अवरोध गर्ने कार्य छान्नुहोस्, र आफैँ सुधारिने क्लाइन्टलाई त्यो गर्न दिनुहोस्। पूर्ण पुनः सुरुले चलिरहेका सत्र फ्याँक्छ, जुन दिनमा धेरै पटक जाग्ने ल्यापटपमा वास्तविक लागत हो।