एक टाइमआउटपछि तपाईंको OpenVPN क्लाइन्ट किन बन्द रहन्छ

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

मोनिटरिङले दाबी गर्ने कुराबाट होइन, युनिटले वास्तवमा के गर्‍यो त्यसबाट सुरु गर्नुहोस्। systemctl status openvpn-client@office र journalctl -u openvpn-client@office -n 50 बाहिर जाने कारण र क्लाइन्ट जानुअघि लेखेको अन्तिम पङ्क्ति देखाउँछन्।

कसैले देख्नुअघि नै प्रक्रिया बाहिर गयो

त्रुटिबिना हराउने क्लाइन्ट सामान्यतया जानाजान बाहिर गएको हुन्छ। यो व्यवहार प्रोफाइलले तय गर्छ, सेवा प्रबन्धकले होइन: ping-exit सामुन्नेको पक्षले जवाफ दिन छोड्ने बित्तिकै प्रक्रिया अन्त्य गर्छ, जबकि ping-restart प्रक्रिया राख्छ र त्यसभित्र फेरि जोडिन्छ। सत्र सीमा र निष्क्रियता टाइमरले बाहिरबाट उही चित्र बनाउँछन्: टनेल पनि छैन र अलार्म पनि छैन।

दुई ping निर्देशन एउटै प्रोफाइलमा सँगै रहन सक्दैनन्, त्यसैले एउटा छान्नुहोस् र छनोट लेख्नुहोस्। सर्भर पनि हेर्नुहोस्, किनकि यसको आफ्नै ping-exit ले क्लाइन्टले जे मागे पनि सत्र बन्द गर्छ, र त्यो निर्णय कसले लियो भन्ने कुरा सर्भर लगमा मात्र लेखिन्छ।

ping-exit र ping-restart बीचको छनोट

आफैं निको हुनुपर्ने ल्यापटप वा टाढाको साइटका लागि ping-restart छान्नुहोस्, र मृत टनेलले प्रक्रिया रोक्नुपर्ने अवस्थाका लागि ping-exit राख्नुहोस् ताकि अरू कुनै कुराले त्यसमा प्रतिक्रिया दिन सकोस्। सङ्ख्याभन्दा सम्बन्ध बढी महत्त्वपूर्ण छ: ping 10 सँग ping-restart 60 भन्नाले जाँचअघि दश सेकेन्ड मौन र रिस्टार्टअघि साठी सेकेन्ड, जुन हानि हुने मोबाइल लिङ्कमा आक्रामक र तारयुक्तमा उचित हुन्छ। कारण पङ्क्तिको छेउमा लेख्नुहोस्, नत्र अर्को पाठकले डिफल्ट मान जानाजान राखिएको ठान्नेछ।

त्यसपछि बाहिर गएको साँच्चै प्रक्रिया नै हो भनी पुष्टि गर्नुहोस्। टनेल मृत हुँदा सक्रिय भएको जानकारी दिने युनिट अर्को विफलता हो, जसको चर्चा तल छ।

युनिटलाई साँच्चै पुनः सुरु गर्ने निगरानी

systemd होस्टमा सबैभन्दा सानो टिकाउ परिवर्तन एउटा drop-in फाइल हो: Restart=on-failure र RestartSec=10, जो /etc/systemd/system/[email protected]/restart.conf भित्र छन्। drop-in तब मात्र पढिन्छ जब systemd ले आफ्नै परिभाषा पुनः लोड गर्छ, त्यसैले त्यसपछि systemctl daemon-reload चलाउनुहोस्। मान पुग्यो भनी ठान्नुको सट्टा systemctl show -p Restart -p ExecMainStatus openvpn-client@office ले प्रमाणित गर्नुहोस्। फाइल नामको इन्स्ट्यान्स युनिटले साँच्चै लोड गर्ने प्रोफाइल हुनुपर्छ, त्यसैले office का लागि लेखिएको फाइलले openvpn-client@home का लागि केही गर्दैन।

on-failure एउटा अवस्थालाई बेवास्ता गर्छ: शून्य स्थिति भएको सफा बाहिरिने। केही भत्काउने बाटो यसै गरी अन्त्य हुन्छन्, त्यसैले म्यान पेजको शब्दमा भर नपर्ने, दर्ता गरिएको स्थिति पढ्नुहोस्। तपाईंको क्लाइन्ट शून्यसँग हार मान्ने हो भने, तपाईंलाई Restart=always चाहिन्छ, र यसको मूल्य भनेको साँच्चै बिग्रिएको प्रोफाइल सुरु दर सीमा सक्रिय नभएसम्म र जर्नल नभरिएसम्म फेरि फेरि फर्किनु हो।

Restart=always जानाजान रोकेपछि पनि सक्रिय हुन्छ। मर्मतका लागि systemctl stop प्रयोग गर्नुहोस्, र काम गर्दा युनिट बन्द राख्नुपर्ने भए मास्क गर्नुहोस्।

टनेल बन्द हुँदा चुहावट समात्नुहोस्

निगरानीले टनेल फर्काउँछ; टनेल नहुँदा ट्राफिक बाहिर जानबाट यसले रोक्दैन। persist-tun ले पुनः जडानहरूबीच उपकरण र यसका रुटहरू राख्छ, जुन सुविधाजनक छ र एउटा झ्याल खोल्छ। उपकरण रहन्छ, रुटहरू अझै त्यसैतिर छन्, र प्याकेटहरू सुरक्षाविना र रिपोर्टविना बाहिर बग्छन्। यो नीतिको निर्णय हो, तटस्थ डिफल्ट होइन।

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

क्लाइन्ट जानाजान रोकेर यो जाँच्नुहोस्। systemctl stop openvpn-client@office चलाउनुहोस्, त्यसपछि curl -m 5 https://example.com, जुन भौतिक लिङ्कमा सफल हुनुको सट्टा असफल हुनुपर्छ। सफलता भन्नाले फायरवाल नियम छैन वा धेरै अनुमतिप्रद छ।

फेरि जोडिनुहोस्, टनेलले फेरि ट्राफिक बोकेको पुष्टि गर्नुहोस्, र त्यसपछि मात्र जाँच मोनिटरिङमा थप्नुहोस्। cron बाट ip addr tun उपकरणका लागि सोध्नु सबैभन्दा धेरै असफल हुने निगरानी हो, किनकि persist-tun सँग उपकरण सत्रभन्दा लामो बाँच्छ र केही नबोकिँदा पनि जाँचले स्वास्थ्य रिपोर्ट गर्छ।