OpenConnect ने तुटलेल्या VPN ला किती वेळ पुन्हा जोडण्याचा प्रयत्न करावा?

--reconnect-timeout एका अरुंद प्रश्नाचे उत्तर देते: बोगदा पडल्यानंतर ही क्लायंट प्रक्रिया हार मानून बाहेर पडण्यापूर्वी किती वेळ प्रयत्न करत राहते. OpenConnect मॅन्युअल पृष्ठ ती पर्याय हरवलेल्या दुव्यानंतर किंवा उत्तर देणे थांबवलेल्या पीअरनंतरच्या पुनःप्रयत्नांसाठी 300 सेकंदांच्या दस्तऐवजीकृत डीफॉल्टसह नोंदवते, आणि ही संख्या एका चालू क्लायंटसाठी अंतिम मुदत आहे, VPN पोहोचण्यायोग्य राहते याचा पुरावा नाही. हे प्रक्रिया जिवंत ठेवण्याचे धोरणही नाही, आणि बहुतेक गोंधळ येथूनच सुरू होतो.

वर दुसरी यंत्रणा बसली की गोंधळ वाढतो. क्लायंट पुन्हा सुरू करणारा पर्यवेक्षक, गेटवेला पिंग करणारा तपासक आणि अंगभूत पुनःप्रयत्न खिडकी या सर्व एकाच बिघाडाला प्रतिसाद देऊ शकतात, आणि मग घटना अशा तीन कालरेषा देते ज्या कोणीही जुळवू शकत नाही.

पुनर्जोडणी खिडकी प्रत्यक्षात काय मर्यादित करते

प्रवेश नेटवर्क काही सेकंदांसाठी अदृश्य होते अशी कल्पना करा. क्लायंट दुवा तुटताना पाहतो, किंवा मृत पीअरची उत्तरे ऐकणे थांबवतो, आणि जितकी स्थिती ठेवता येईल तितकी धरून सत्र पुन्हा उभारू लागतो. गेटवे पुन्हा स्वीकारेपर्यंत किंवा खिडकी संपेपर्यंत प्रयत्न चालू राहतात, आणि संपलेली खिडकी शून्येतर निर्गमाने संपते. तेच निर्गम, कालमर्यादेचे मूल्य नाही, जिथे जीवनचक्राची मालकी प्रक्रियेवर देखरेख करणाऱ्याकडे जाते.

खिडकी तपासक किती वेळा चालतो याबद्दल काहीही सांगत नाही, आणि ती प्रमाणीकरण वाढवू शकत नाही. गेटवेने सत्र रद्द केले असेल, किंवा खाते आता नवीन दुसरा घटक मागत असेल, तर जास्त प्रतीक्षा जुने सत्र पुन्हा वैध करणार नाही. पुनःप्रयत्न तेव्हाच यशस्वी होतो जेव्हा मार्ग परत येतो, गेटवे सत्र अजूनही ओळखतो, आणि मागितलेली ओळखपत्रे वापरण्यायोग्य राहतात, म्हणून ही संख्या जिवंतपणाचा अंतराल नाही तर अंतिम मुदत म्हणून वाचा.

खिडकी चालू असताना अनुप्रयोग काय करतात हेही ती नियंत्रित करत नाही. प्लॅटफॉर्म आणि बिघाड किती पुढे गेला यावर अवलंबून, क्लायंट मार्ग अजून स्थापित असताना किंवा ते काढल्यानंतर पुन्हा जोडला जाऊ शकतो. म्हणूनच व्यत्ययाच्या मध्यात पाठवलेली विनंती झटपट अयशस्वी होण्याऐवजी कालमर्यादेपर्यंत लटकत राहते.

पर्यवेक्षकाची पुनर्सुरुवात आणि क्लायंटचे पुनःप्रयत्न दोन स्तर आहेत

चालू क्लायंटला त्याची स्वतःची खिडकी खर्च करू द्या, आणि सेवा व्यवस्थापकाने निर्गमावर प्रतिसाद द्यावा. systemd अंतर्गत पुनर्सुरुवात धोरण असलेला अग्रभागातील क्लायंट नेमकी ती विभागणी देतो: मर्यादित कालावधीसाठी प्रयत्न, मग एक पुनर्सुरुवात निर्णय. परिणाम एकच कालरेषा आहे जी नंतरही पुनर्रचित करता येते.

पार्श्वभूमीतील क्लायंट आणि इंटरफेस दिसत नसल्यास दुसरी प्रत सुरू करणारा स्वतंत्र पोलर हा चुकीचा जाणारा नमुना आहे. मग दोन्ही प्रक्रिया एकाच उपकरण नोड, मार्ग आणि रिझॉल्व्हर सेटिंग्जसाठी स्पर्धा करतात. खरोखर डीमन हवा असेल, तर पर्याय क्लायंट प्रत्यक्षात सुरू होणाऱ्या कमांड लाइनवर ठेवा:

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

त्या ओळीत दोन तपशील वजनाचे आहेत. --background प्रक्रिया वेगळी करते, म्हणून pid फाइल त्यावरील एकमेव विश्वासार्ह हँडल बनते, आणि कालमर्यादा तीच प्रक्रिया जिवंत असेपर्यंतच खर्च होते; ती मारणारा पर्यवेक्षक पुढे चालू ठेवण्यासाठी अर्थसंकल्प ठेवत नाही.

जाणीवपूर्वक केलेल्या डिस्कनेक्टला स्वतःचा संकेत हवा. नियोजित विराम आणि खरा व्यत्यय भोळ्या निरीक्षकाला सारखेच दिसतात, दोन्ही «जोडलेले नाही» असे वाचले जातात. विराम पर्यवेक्षकाच्या थांबवण्याच्या क्रियेद्वारे किंवा रॅपरला समजणाऱ्या खुणेद्वारे चालवा, जेणेकरून जाणीवपूर्वक थांबणे कोणीही न मागितलेली पुनर्सुरुवात घडवणार नाही.

हस्तांतरण पुनःप्रयत्न लूपशी स्पर्धा करू न देणे

देखरेख नसलेली पुनर्प्राप्ती विना-व्यक्ती नूतनीकरण होणाऱ्या ओळखपत्रांवर अवलंबून असते. फक्त परस्परसंवादी डेस्कटॉप सत्रात उघडणारी कीरिंग किंवा नेहमी टाइप केलेला कोड मागणारे टोकन मार्ग परत आल्यावर क्लायंटला प्रमाणीकरण टप्प्यात अडकवेल. खिडकी लांबवण्यापूर्वी तो कार्यप्रवाह सोडवा, कारण लांब खिडकी त्याच अडवलेल्या सूचनेला अयशस्वी होण्यासाठी जास्त वेळ देते.

सूचना कमी करण्यासाठी सर्व्हर पडताळणी सैल करू नये. गेटवेची पडताळणी करणारा पिन किंवा विश्वास अँकर हाच स्वयंचलित पुनर्जोडणी सुरक्षित करतो, आणि प्रमाणपत्राच्या प्रश्नाला टाळण्यासाठी तो बंद करणे दिसणारा व्यत्यय न दिसणाऱ्या व्यत्ययाशी बदलते. पडताळलेली ओळख ठेवा आणि त्याऐवजी सूचना दुरुस्त करा; कोणत्याही गेटवेला जोडण्यास तयार क्लायंट थांबून वाट पाहणाऱ्यापेक्षा वाईट आहे.

इंटरफेस असणेही आरोग्याचे संकेत नाही. बोगदा उपकरण त्यामागे मृत सत्रासह असू शकते, आणि सुरुवातीची प्रक्रिया अजिबात बोगद्याशिवाय असू शकते. या निरीक्षणांपैकी कोणतेही खऱ्या विनंतीसमोर टिकत नाही. आरोग्य तेथून आले पाहिजे जे वापरकर्त्याला हवे आहे, उदाहरणार्थ बोगद्यातून ज्ञात अंतर्गत सेवेकडे जाणारी विनंती.

व्यत्ययादरम्यान आणि नंतर काय पडताळावे

चार घटना स्वतंत्र चाचण्या म्हणून चालवा: खिडकीपेक्षा लहान व्यत्यय, त्यापेक्षा मोठा व्यत्यय, प्रमाणीकरण अयशस्वी आणि जाणीवपूर्वक थांबवणे. प्रत्येकाने वेगळ्या, अंदाजे स्थितीत संपले पाहिजे, आणि पहिल्या दोनमधील सीमाच मूल्य निवडण्याचे संपूर्ण कारण आहे.

तपासण्या बाहेरच्या दिशेने ठेवा, कारण प्रक्रिया तक्ता स्वतःच फार कमी सिद्ध करतो. लहान व्यत्ययादरम्यान pid स्थिर राहतो का पहा, मग मोठ्यानंतर ते गेले आणि एकदा बदलले गेले याची खात्री करा:

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

लहान व्यत्ययादरम्यान क्लायंटने खरोखर पुन्हा प्रयत्न केला, लवकर बाहेर पडला नाही, आणि मार्ग व रिझॉल्व्हर नोंदी नकलांशिवाय परत आल्या याची खात्री करा. मोठ्या व्यत्ययासाठी स्वच्छ निर्गम आणि त्यानंतर नेमकी एक पुनर्सुरुवात झाली याची खात्री करा. प्रमाणीकरण अयशस्वीसाठी क्लायंट आपल्याला नाकारत राहणाऱ्या गेटवेसमोर फिरत नाही याची खात्री करा. pid साचत नाही तर एकाच मूल्यावर परत येतो ही तपासणी जोडा.

जाणीवपूर्वक थांबवण्यासाठी आरोग्य URL पोहोचण्याबाहेर राहिले पाहिजे आणि प्रक्रिया बंद राहिली पाहिजे. मग अनुप्रयोगाच्या बाजूने लूप बंद करा: तीच विनंती बोगदा नसताना अयशस्वी व्हायला हवी आणि परत आल्यावर तुमचे धोरण अपेक्षित असलेल्या स्रोत पत्त्यावरून यशस्वी व्हायला हवी. हिरवे बोगदा चिन्ह पुरावा नाही, पण पूर्ण झालेली विनंती पुरावा आहे.