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 ٹوٹ گیا اور کچھ اب بھی جڑا ہوا ہے» جیسی رپورٹ میں واقعی جو ہوتا ہے اس کا بیشتر حصہ ڈھانپ لیتے ہیں۔