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 गिर गया और कुछ अब भी जुड़ा है» जैसी रिपोर्ट में असल में जो होता है उसका ज़्यादातर हिस्सा कवर करते हैं।