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

गहाळ मार्ग, चुकीचा रिझोल्व्हर किंवा अगम्य गेटवेही पर्यायाबाहेर आहेत, कारण ते वाटाघाटी अपयश नाहीत। शांत पॅकेट हानी ही सर्वात अस्पष्ट बाब आहे: देवाणघेवाण किती पुढे गेली यावर अवलंबून, क्लायंट वाटाघाटी अपयश नोंदवू शकतो किंवा फक्त वेळ संपू शकतो।

तुमच्या नोट्समध्ये हा फरक ठेवा। सेटिंग दुरुस्तीऐवजी निदान आणि देखरेखीसाठी आहे, त्यामुळे ते साइफर विसंगती, प्रमाणपत्र समस्या किंवा चुकीचा पोर्ट दुरुस्त करत नाही। आधी अपयशी वाटाघाटीचे कारण दुरुस्त करा, नंतर तात्काळ बाहेर पडणे तैनातीसाठी अजूनही योग्य आहे का ते ठरवा।