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 पहुँच से बाहर रहना चाहिए और प्रक्रिया बंद रहनी चाहिए। फिर एप्लिकेशन की ओर से लूप बंद करें: वही अनुरोध सुरंग न होने पर विफल होना चाहिए और लौटने के बाद उस स्रोत पते से सफल होना चाहिए जिसकी अपेक्षा आपकी नीति करती है। हरा सुरंग चिह्न सबूत नहीं है, लेकिन पूरा हुआ अनुरोध सबूत है।