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 पहुँचबाहिर रहनुपर्छ र प्रक्रिया बन्द रहनुपर्छ। त्यसपछि अनुप्रयोगको तर्फबाट लूप बन्द गर्नुहोस्: त्यही अनुरोध सुरुङ नहुँदा असफल हुनुपर्छ र फर्किएपछि तपाईंको नीतिले अपेक्षा गर्ने स्रोत ठेगानाबाट सफल हुनुपर्छ। हरियो सुरुङ चिन्ह प्रमाण होइन, तर पूरा भएको अनुरोध प्रमाण हो।