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 काम नहीं करता। प्रमाणीकरण की पुनः प्रयास सेटिंग्स देखने का अगला स्थान हैं, और सर्वर का कारण क्लाइंट की अंतिम पंक्ति से अधिक मायने रखता है। गलत पासवर्ड और अनुपस्थित प्रमाणपत्र क्लाइंट पक्ष पर समान संदेश उत्पन्न कर सकते हैं।

अनुपस्थित मार्ग, गलत रिज़ॉल्वर या अगम्य गेटवे भी विकल्प से बाहर हैं, क्योंकि वे बातचीत की विफलताएँ नहीं हैं। मूक पैकेट हानि सबसे कम स्पष्ट मामला है: अदला-बदली कितनी आगे बढ़ी, इस पर निर्भर करता है कि क्लाइंट बातचीत विफलता की रिपोर्ट करे या बस समय-सीमा पार कर जाए।

अपने नोट्स में यह अंतर बनाए रखें। यह सेटिंग मरम्मत के बजाय निदान और निगरानी के लिए है, इसलिए यह सिफ़र बेमेल, प्रमाणपत्र समस्या या गलत पोर्ट ठीक नहीं करती। पहले विफल बातचीत का कारण ठीक करें, फिर तय करें कि तत्काल निकास अभी भी परिनियोजन के लिए उपयुक्त है या नहीं।