VPN फिर से जुड़ गया, फिर भी ऐप का सत्र विफल रहता है

सुरंग लौट आती है, क्लाइंट कहता है कि जुड़ गया है, और ब्राउज़र अब भी उस पृष्ठ पर घूम रहा है जिसे वह कटाव से पहले लोड कर रहा था। VPN का फिर से जुड़ना एक मार्ग बहाल करता है, और वह उस संबंध-स्थिति को बहाल नहीं करता जो ऐप्स और दूर का पक्ष पुराने मार्ग पर इकट्ठा कर चुके थे। ये सुधारने के लिए दो अलग चीज़ें हैं, और इन्हें मिला देना आपको बिना कारण VPN सेटिंग्स में वापस भेज देता है।

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

फिर से जुड़ने के बाद क्या बचता है और क्या नहीं

सुरंग मार्गों, कुंजियों और पतों का एक समूह है, और फिर से जुड़ना तीनों को बहाल कर सकता है, जबकि हर स्थापित प्रवाह मृत रहता है। ऑपरेटिंग सिस्टम एक सॉकेट खुला रखता है क्योंकि ऐप ने ऐसा माँगा था, और उस सॉकेट की समय-सीमा मिनटों या घंटों दूर हो सकती है। उसके नीचे सहकर्मी प्रवाह भूल चुका है, एक अनुवाद प्रविष्टि समाप्त हो गई है, या मार्ग अब ऐसे अंतिम बिंदु से गुज़रता है जिसने कभी हैंडशेक नहीं देखा। फिर से जुड़ने के क्रम में कुछ भी ऐप के सॉकेटों से गुज़रकर उन्हें ठीक नहीं करता।

कुछ क्लाइंट फिर से जुड़ते समय पुराने संबंध गिराने वाला हुक जोड़ते हैं, और अधिकांश नहीं जोड़ते। यहाँ व्यवहार क्लाइंट, प्लेटफ़ॉर्म और संस्करण के अनुसार बदलता है।

दूर के पक्ष ने आपको भी भुला दिया

दूर का सिरा अपनी स्थिति रखता है: एक TLS सत्र, एक TCP नियंत्रण ब्लॉक, और शायद एक मैपिंग प्रविष्टि जो आपके पते और पोर्ट को प्रवाह से बाँधती है। मार्ग पर लगा अनुवाद उपकरण उस मैपिंग को अंतराल के दौरान समाप्त होने दे सकता है, भले ही सुरंग जल्दी फिर बन जाए। मैपिंग जाते ही पैकेट ऐसे प्रवाह के लिए आते हैं जिसे सर्वर अब नहीं पहचानता, और उत्तर वह रीसेट हो सकता है जो क्लाइंट कभी नहीं दिखाता। ऐप्स इसे त्रुटि के बजाय ठहराव बताते हैं, क्योंकि वे अब भी ऐसे सॉकेट की प्रतीक्षा कर रहे हैं जो कभी उत्तर नहीं देगा।

सर्वर पक्ष की निष्क्रिय समय-सीमाएँ अपने ही कार्यक्रम पर वही करती हैं, इसलिए कोई भी नेटवर्क घटना हुए बिना सत्र मर सकता है। जो संबंध सर्वर की अपेक्षा से अधिक समय निष्क्रिय रहा, वह आपके सुरंग के खिसकने को भाँपने से पहले ही जा चुका है।

नया अनुरोध ही वह परीक्षण है जो इन्हें अलग करता है

पुराना अनुरोध अब भी लटका हो, तब उसी होस्ट पर नया अनुरोध भेजिए और दोनों को देखिए। अगर नया अनुरोध सफल हो, तो सुरंग, मार्ग और नाम-विश्लेषण सब काम कर रहे हैं, और गड़बड़ी पुराने प्रवाह तक सीमित है। अगर नया अनुरोध भी विफल हो, तो आपकी मार्ग में समस्या है और ऐप की सत्र-स्थिति भ्रामक संकेत है।

परीक्षण के दौरान सीधे ट्रैफ़िक का कोई भी अवरोध अपनी जगह रहने दीजिए। किसी आकस्मिक वैकल्पिक मार्ग से सफल होने वाला अनुरोध सुरंग के बारे में कुछ साबित नहीं करता।

पुराने नहीं, नए संबंध से पुष्टि कीजिए

नीचे दिए आदेश अब भी खुले सॉकेट दिखाते हैं, एक नया अनुरोध शुरू करते हैं, और जाँचते हैं कि सत्र तालिका में प्रवाह के लिए अब भी प्रविष्टि है या नहीं। अंतर दिखे इसलिए पहला आदेश फिर से जुड़ने से पहले और बाद में चलाइए। होस्ट और पोर्ट को अपनी सेवा से बदल दीजिए।

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

कोई ट्रैफ़िक न चलता हुआ स्थापित सॉकेट वही पहचान है जिसे खोजना है, और स्थिति कोड लौटाता नया अनुरोध दिखाता है कि मार्ग जीवित है। संबंध तालिका उत्तर देती है कि क्या कुछ अब भी प्रवाह का मैपिंग करता है, और यही वह हिस्सा है जो क्लाइंट नहीं देख सकता। रिज़ॉल्वर क्वेरी पृष्ठ लोड के दूसरे आधे हिस्से को ढकती है, क्योंकि नाम की विफलता और अटका संबंध ब्राउज़र में एक जैसे दिखते हैं। मिलकर, वे चार आउटपुट पुराने सत्र को टूटी सुरंग से अलग करते हैं।

व्यवधान का समय, फिर से जुड़ने का समय और पुराने तथा नए अनुरोध का अंतर दर्ज कीजिए। वही रिकॉर्ड किसी अस्पष्ट शिकायत को ऐसी रिपोर्ट में बदल देता है जिस पर कोई काम कर सके।