TLS त्रुटिपछि OpenVPN बारम्बार पुनः प्रयास गरिरहन्छ: कसरी रोक्ने

क्लाइन्ट जडान हुन्छ, TLS वार्ताको क्रममा असफल हुन्छ, पर्खन्छ र त्यही नतिजासहित त्यही सर्भर फेरि प्रयास गर्छ। असफल प्रक्रियालाई पुनः सुरु गर्ने सुपरभाइजरको अधीनमा ती प्रयासहरू जर्नलमा अन्तहीन लूप बन्छन्, र पहिलो निदान लाइन पहुँचबाहिर जान्छ। OpenVPN त्यो वार्ता असफलतालाई अर्को प्रयासको सट्टा देखिने बाहिरी निकासमा बदल्ने विकल्प दिन्छ। यो निदान र निगरानीको सेटिङ हो, मर्मत होइन, त्यसैले प्रक्रियालाई साँच्चै तल रहन दिने नीतिसँग यसलाई जोड्नुहोस्।

पहिलो त्रुटि लुकाउने चक्र

तपाईंले देख्नुहुने एक असफलता होइन, दोहोरिने ब्लक हो: जडान प्रयास, TLS त्रुटि, विराम र त्यसपछि त्यही क्रम। हरेक पुनरावृत्तिले मूल लाइनलाई जर्नलमा अझ माथि धकेल्छ। युनिट असफलतामा पुनः सुरु भयो भने, कसैले कारण नपढी चक्र घण्टौं चल्न सक्छ। लक्षण लूप हो, यद्यपि मूल दोष एउटै वार्ता समस्या हो।

अन्तरक्रियात्मक सत्रहरूले यो सहन्छन् किनभने क्षणिक असफलता अर्को प्रयासमा हट्न सक्छ। स्वचालित जडानहरूले त्यस्तै आशावाद बोक्न सक्दैनन्: मानिस वा मोनिटरले स्थिति देख्न प्रक्रिया रोकिनुपर्छ।

केही बदल्नु अघि एउटा पूरा चक्र कैद गर्नुहोस्। टाढाको ठेगाना, त्रुटिमा उल्लेख गरिएको TLS चरण र प्रक्रिया बाहिर निस्कन्छ कि निस्कँदैन लेख्नुहोस्।

लूपपछाडिको पुनः प्रयास संयन्त्र

पुनः प्रयास पूर्वनिर्धारित हो किनभने धेरै असम्बन्धित टाइमआउटले एउटै संयन्त्र साझा गर्छन्। connect-retry ले जडान प्रयासबीचको अन्तराल तोक्छ, connect-retry-max ले प्रत्येक टाढाको प्रविष्टि कति पटक परीक्षण गर्ने सीमित गर्न सक्छ, र resolv-retry ले दोहोरिने नाम खोज नियन्त्रण गर्छ। TLS वार्ता असफलता यातायात घटनाका रूपमा त्यो संयन्त्रसम्म पुग्छ, त्यसैले क्लाइन्टले रिपोर्ट गर्नुको सट्टा अर्को प्रयास तालिका बनाउँछ। पूर्वनिर्धारित मान अस्थिर लिङ्कमा उपयोगी र निको हुन नसक्ने दोषमा हानिकारक हुन्छ।

--tls-exit विकल्पले वार्ताको अवस्था मात्र बदल्छ। पुस्तिकाले यसलाई TLS वार्ता असफलतामा बाहिर निस्कने भनी वर्णन गर्छ, जुन हरेक त्रुटिमा बाहिर निस्कनेभन्दा साँघुरो हो। टाइमआउट, रिजोल्भर असफलता र प्रमाणीकरण अस्वीकृतिले आफ्नै व्यवहार कायम राख्छन्।

TLS असफलतामा क्लाइन्टलाई बाहिर निस्कन दिने

क्लाइन्टले साँच्चै लोड गर्ने प्रोफाइलमा tls-exit राख्नुहोस्, वा सुरु गर्दा --tls-exit दिनुहोस्, र एक पटक अग्रभागमा चलाउनुहोस्। निकास स्थिति र अन्तिम लग लाइन पढ्नुहोस्, किनभने सुपरभाइजरले स्थितिमै काम गर्छ। वार्ता असफलतापछि शून्य नभएको निकास नै इच्छित नतिजा हो। प्रक्रिया सकिनुको सट्टा पुनः प्रयास गरिरहेको छ भने, विकल्प क्लाइन्टले साँच्चै लोड गर्ने प्रोफाइलमा छैन।

त्यो निकास देखिने हो कि होइन सुपरभाइजरले निर्णय गर्छ। Restart=always वा Restart=on-failure भएको systemd युनिटले क्लाइन्ट पुनः सुरु गर्छ, त्यसैले लूप चलिरहन्छ र विकल्पले केही नगरेजस्तो देखिन्छ। क्लाइन्टलाई दोष दिनुअघि नीति जाँच्नुहोस्:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no ले प्रक्रियालाई तल रहन दिन्छ, र Restart=on-failure ले शून्य नभएको स्थितिपछि पनि पुनः सुरु गर्छ। असफलता देखिने तर सेवा असम्बन्धित क्र्यासबाट सुधारिने चाहनुहुन्छ भने Restart=on-failure सेट गर्नुहोस् र पुनः सुरुको आँधी रोक्न StartLimitBurst र StartLimitIntervalSec प्रयोग गर्नुहोस्। त्यसपछि अन्तिम निकास कोड पुष्टि गर्न युनिटको स्थिति पढ्नुहोस्: systemctl status ले त्यो रिपोर्ट गर्छ, र जर्नलले पहिलो त्रुटि पुनः सुरुहरूमाथि राख्छ।

निर्णय युनिटमा वा प्रोफाइल नोटमा लेख्नुहोस्। TLS असफलतामा बाहिर निस्कने प्रोफाइल, कारण अभिलेख नगरिएसम्म अर्को व्यक्तिलाई दुर्घटनाजस्तो देखिन्छ। कुन असफलताले प्रक्रिया रोक्नुपर्छ र कुन पुनः प्रयास गर्नुपर्छ भन्नुहोस्।

एक पटक प्रयोग हुने एन्डपोइन्टले प्रमाणित गर्नुहोस्

व्यवहारमा भरोसा गर्नुअघि हेर्न, प्रोफाइल प्रतिलिपि गर्नुहोस् र प्रतिलिपिलाई TCP जडान स्वीकार गर्ने तर कहिल्यै OpenVPN नबोल्ने एन्डपोइन्टतर्फ देखाउनुहोस्। जवाफ दिएर पछि चुप बस्ने श्रोता पर्याप्त हुन्छ। tls-exit सँग, ह्यान्डशेक असफल हुँदा क्लाइन्ट सकिनुपर्छ; त्यो बिना त्यही प्रोफाइल घुमिरहनुपर्छ। प्रतिलिपि प्रयोग गर्नुहोस्, कहिल्यै काम गरिरहेको प्रोफाइल होइन।

दुई रनलाई निकास स्थिति र पहिलो त्रुटि लाइनले तुलना गर्नुहोस्, प्रत्येक कति बेर चल्यो भन्नेले होइन। स्थितिले विकल्प चल्यो कि भन्छ, र पहिलो लाइनले कुन चरण असफल भयो भन्छ।

काम सकिएपछि परीक्षण प्रोफाइल हटाउनुहोस्। जानाजानी गलत एन्डपोइन्ट भएको प्रतिलिपि पछि डाइरेक्टरीका सबै प्रोफाइल सुरु गर्ने जोकोहीका लागि जाल हो।

यो विकल्प कहिल्यै नपुग्ने चरणहरू

प्रमाणीकरण अस्वीकृति पछिको चरण हो। सर्भरले खाता मूल्याङ्कन गरी अस्वीकार गर्‍यो भने TLS पहिले नै वार्ता भइसकेको हुन्छ, त्यसैले tls-exit चल्दैन। प्रमाणीकरणको पुनः प्रयास सेटिङ हेर्ने अर्को ठाउँ हो, र सर्भरको कारण क्लाइन्टको अन्तिम लाइनभन्दा महत्त्वपूर्ण छ। गलत पासवर्ड र हराएको प्रमाणपत्रले क्लाइन्टतर्फ समान सन्देश उत्पन्न गर्न सक्छ।

हराएको मार्ग, गलत रिजोल्भर वा पुग्न नसकिने गेटवे पनि विकल्पबाहिर छन्, किनभने ती वार्ता असफलता होइनन्। मौन प्याकेट हानि सबैभन्दा अस्पष्ट अवस्था हो: आदानप्रदान कति अगाडि बढ्यो भन्ने आधारमा, क्लाइन्टले वार्ता असफलता रिपोर्ट गर्न सक्छ वा समय सकिन सक्छ।

आफ्नो नोटमा यो भिन्नता राख्नुहोस्। सेटिङ मर्मतभन्दा निदान र निगरानीका लागि हो, त्यसैले यसले साइफर अमिलता, प्रमाणपत्र समस्या वा गलत पोर्ट ठीक गर्दैन। पहिले असफल वार्ताको कारण सुधार्नुहोस्, त्यसपछि तत्काल बाहिर निस्कने कुरा परिनियोजनका लागि अझै उपयुक्त छ कि छैन निर्णय गर्नुहोस्।