VPN पृष्ठको बीचमा गयो: पृष्ठभूमि अनुरोधहरू अझै बाहिर जाँदै छन्?

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

पृष्ठले तपाईंबिना सुरु गर्ने काम

चार संयन्त्रले लोड भएको कागजातलाई व्यस्त राख्छन्। दोहोरिने टाइमरले हरेक केही सेकेन्डमा स्थिति कल फेरि चलाउन सक्छ। तपाईं फर्केपछि ट्याब फेरि देखिन थालेपछि fetch सक्रिय हुन सक्छ। WebSocket वा सर्भरले पठाएका घटनामा बनेको प्रत्यक्ष च्यानलले आफ्नै ब्याकअफ तालिकाअनुसार फेरि जडान हुन प्रयास गर्न सक्छ। साइटले दर्ता गरेको सर्भिस वर्कर तपाईंको अगाडि कुनै ट्याब नभए पनि कतारमा रहेको सिङ्कका लागि जाग्न सक्छ।

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

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

पहिलेको पृष्ठ लोडले मार्ग किन राख्दैन

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

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

असफलता नीति कहाँ अवतरण हुन्छ

क्लाइन्टको ब्लक पृष्ठ ल्याइँदा होइन, जडान प्रयास गरिँदा मूल्याङ्कन गरिन्छ। यदि सामान्य पहुँच अझै अनुमति छ भने, पुनः प्रयास भौतिक लिङ्कबाट खुला रूपमा बाहिर जान सक्छ। यदि नीतिले त्यो ट्राफिक टनेल फर्केसम्म रोकेर राख्छ भने, प्रयास जडानको क्षणमै असफल हुन्छ र पृष्ठले केही सेकेन्डपछि फेरि प्रयास गर्न सकिने त्रुटि देखाउँछ।

तपाईंले यीमध्ये कुन पाउनुहुन्छ दुई विवरणले निर्धारण गर्छन्। पहिलो हो क्लाइन्टले समर्थन गर्ने प्रवर्तन-दायरा: पूरै उपकरणको ब्लक, टनेल एडाप्टरसम्म सीमित ब्लक, वा अपवादसहितको नियम समूह। दोस्रो हो गन्तव्य तपाईंले पहिले स्थानीय प्रिन्टर, क्याप्टिभ पोर्टल वा स्ट्रिमिङ सेवाका लागि थपेको अपवादभित्र पर्छ कि पर्दैन।

अनुप्रयोग-स्तरीय इन्क्रिप्शनले यसमध्ये केही बदल्दैन। HTTPS ब्राउजर र सर्भरबीचका बाइटहरूको रक्षा गर्छ; कुन इन्टरफेसले तिनीहरू बोक्छ भनेर केही भन्दैन। पृष्ठ पूर्ण रूपमा इन्क्रिप्टेड भए पनि गलत बाटोबाट बाहिर जान सक्छ, र साँघुरो ब्लकले ठ्याक्कै त्यही अनुमति दिन्छ।

फाल्न मिल्ने पृष्ठसँग नियन्त्रित जाँच

तपाईंले नियन्त्रण गर्नुहुने होस्ट र यसलाई बोलाउनुबाहेक अरू केही नगर्ने पृष्ठ प्रयोग गर्नुहोस्, ताकि कुनै वास्तविक डेटा खेलमा नहोस्। टर्मिनलबाट विच्छेदअघि र पछि बाटोको नमुना लिनुहोस्:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

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

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

सर्भर पक्षका प्रमाणहरू ब्राउजरले देखाउने जुनसुकैभन्दा बलियो हुन्छन्। समय-छाप र स्रोत ठेगानासहितको अनुरोध लगले प्याकेट पुगेको प्रमाणित गर्छ। ब्राउजर प्रविष्टिले कुकी, टोकन र पूरा URL बोक्न सक्छन्, त्यसैले तपाईंको प्रश्नलाई चाहिने फिल्ड मात्र राख्नुहोस् र बाँकी कतै टाँस्नुअघि लुकाउनुहोस्।

जवाफको के गर्ने

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

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