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

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

अवरोधको समय, फेरि जोडिएको समय र पुरानो तथा नयाँ अनुरोधबीचको फरक नोट गर्नुहोस्। त्यो नोटले अस्पष्ट गुनासोलाई कसैले काम गर्न सक्ने प्रतिवेदनमा बदल्छ।