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

रहदारी न हलणारे स्थापित सॉकेट हेच शोधायचे लक्षण आहे, आणि स्थिती कोड परत देणारी नवीन विनंती मार्ग जिवंत असल्याचे दाखवते। जोडणी तक्ता प्रवाह अजूनही काही मॅप करते का याचे उत्तर देतो, आणि तोच भाग क्लायंटला दिसत नाही। रिझॉल्व्हरची चौकशी पान लोडचा दुसरा अर्धा भाग व्यापते, कारण नावाचा बिघाड आणि अडकलेले जोडणे ब्राउझरमध्ये सारखेच दिसतात। एकत्रितपणे, ते चार आउटपुट जुने सत्र तुटलेल्या बोगद्यापासून वेगळे करतात।

अडथळ्याची वेळ, पुन्हा जोडण्याची वेळ आणि जुन्या व नव्या विनंतीमधील फरक नोंदवा। ती नोंद अस्पष्ट तक्रारीचा कोणी कार्य करू शकेल असा अहवाल बनवते।