کیپٹو پورٹل آپ کے VPN کو کیوں روکتا ہے اور دوبارہ سائن اِن کیسے کریں
عوامی Wi-Fi آپ کے آلے کی منظوری اس سے ایک پیکٹ نکلنے سے پہلے ہی دے دیتا ہے۔ پورٹل کیا پھینکتا ہے، آپ کا VPN اسے کیوں غلط رپورٹ کرتا ہے اور کون سی ترتیب آپ کو دوبارہ جوڑتی ہے۔
کھلے نیٹ ورک میں آپ کا ایکسیس پوائنٹ پیکٹوں کو انٹرنیٹ کے حوالے محض نہیں کر دیتا۔ اوپر ایک پالیسی پوائنٹ جانچتا ہے کہ آپ کے آلے کی منظوری ہو چکی ہے یا نہیں، اور جب تک نہ ہو، تقریباً سب کچھ پھینک دیا جاتا ہے۔ آپ کا VPN کلائنٹ اس خاموشی کو مردہ سرور سمجھتا ہے۔ یہ یہ بات شاذ و نادر ہی کہتا ہے: WireGuard خالی جگہ میں ہینڈ شیک دہراتا ہے، OpenVPN کنکشن کے وقت کے خاتمے کی اطلاع دیتا ہے، اور IKEv2 جواب نہ دینے والے دور دراز سرور کے بارے میں خرابی 809 کے ساتھ لوٹتا ہے۔
پورٹل دراصل کیا کنٹرول کرتا ہے
کیپٹو پورٹل دو چیزیں ہیں جو ایک دوسرے سے چپکی ہوئی ہیں: پالیسی فیصلے کا نقطہ اور ری ڈائریکٹر۔ جب آپ کا آلہ جڑتا ہے اور DHCP لیز لیتا ہے، نیٹ ورک آپ کو منظوری سے پہلے کی حالت میں رکھتا ہے۔
وہ حالت فائر وال قواعد کا ایک مجموعہ ہے۔ عام طور پر یہ DNS کی اجازت دیتا ہے اور پورٹل ہوسٹوں کی مختصر فہرست تک HTTP یا HTTPS کی اجازت دیتا ہے، اور باقی سب پھینک دیتا ہے۔ اجازت یافتہ فہرست دیواروں سے گھرا باغ ہے، اور اس میں تقریباً کبھی VPN اینڈ پوائنٹ شامل نہیں ہوتا۔
ان پھینکنے میں سے کوئی بھی شائستہ نہیں ہے۔ VPN سرور کی طرف بھیجے گئے پیکٹ مسترد کرنے کے بجائے پھینک دیے جاتے ہیں، اس لیے کلائنٹ کو نہ ICMP unreachable ملتا ہے نہ TCP reset، صرف جواب کی عدم موجودگی ملتی ہے۔ بنانے والے کے مطابق ری ڈائریکٹر پورٹ 80 پر سائن اِن صفحے کی طرف ری ڈائریکٹ کے ساتھ جواب دے سکتا ہے، جبکہ پورٹ 443 پھینک دیا جاتا ہے یا روک لیا جاتا ہے۔ ری ڈائریکٹ آسانی سے پہچانے جاتے ہیں کیونکہ وہ سادہ HTTP جواب لے کر جاتے ہیں؛ 443 پر روک کے لیے وہ سرٹیفکیٹ درکار ہے جس پر آپ کا براؤزر بھروسہ کرنے سے انکار کرے گا۔
منظوری خود عام طور پر آلے کے MAC پتے سے بندھی ہوتی ہے، کبھی لیز پر لیے گئے IP سے، اور یہ ٹائمر والی سیشن جدول میں رہتی ہے۔ سائن اِن ایک اندراج بناتا ہے۔ آپ کی ٹریفک گزارنے والا فائر وال قاعدہ صرف اس وقت تک موجود رہتا ہے جب تک وہ اندراج موجود ہے، اور اسی لیے آپ کی طرف کچھ بدلے بغیر پورا مسئلہ بعد میں واپس آ جاتا ہے۔
VPN ہینڈ شیک شروع ہونے سے پہلے کیوں مر جاتا ہے
ہر پروٹوکول کی اپنی ترسیل ہوتی ہے، اور منظوری سے پہلے کا فائر وال ہر ایک کو الگ انداز میں توڑتا ہے۔ Windows اور iOS پر IKEv2 UDP 500 اور UDP 4500 پر چلتا ہے؛ ان پورٹوں پر پھینکنا 809 کے طور پر، یا مرحلوں کو الگ رپورٹ کرنے والے کلائنٹس پر نام حل کرنے جیسی ناکامی کے طور پر ظاہر ہوتا ہے۔ UDP 1194 پر OpenVPN اپنا وقت ختم ہونے تک جڑنے کی حالت میں رہتا ہے۔ TCP 443 پر OpenVPN دلچسپ صورت ہے، کیونکہ پورٹل TCP ہینڈ شیک مکمل کر کے پھر اپنے ری ڈائریکٹ صفحے کے ساتھ جواب دے سکتا ہے، اس لیے وقت ختم ہونے کے بجائے TLS خرابی نظر آتی ہے۔
WireGuard یہ طریقہ سب سے واضح دکھاتا ہے۔ یہ ڈیزائن کے مطابق صرف UDP ہے، TCP متبادل نہیں، اس لیے نامعلوم UDP پھینکنے والا فائر وال ترسیل کو مکمل طور پر ہٹا دیتا ہے۔ کلائنٹ بڑھتے وقفے کے ساتھ ہینڈ شیک کی شروعات بھیجتا رہتا ہے اور ایسے ہینڈ شیک کی اطلاع دیتا ہے جو کبھی مکمل نہیں ہوتا۔ اس پیغام میں کہیں Wi-Fi کا ذکر نہیں، اور اس میں کچھ بھی براؤزر کھولنے کا اشارہ نہیں دیتا۔
پلیٹ فارم آپ کے VPN سے پہلے حالت کو بھانپنے کی کوشش کرتے ہیں۔ Windows سائن اِن اطلاع دکھانی ہے یا نہیں یہ طے کرنے کے لیے معلوم URL لاتا ہے، Android ایسا اینڈ پوائنٹ مانگتا ہے جسے 204 No Content کا جواب دینا چاہیے، اور Apple آلات ایک چھوٹی کیپٹو نیٹ ورک ونڈو کھولتے ہیں۔ وہ جانچیں کام کرتی ہیں کیونکہ پورٹل متوقع باڈی کے بجائے ری ڈائریکٹ کے ساتھ جواب دیتا ہے۔ یہی رویہ بتاتا ہے کہ پورٹل مکمل صحت مند کیسے دکھ سکتا ہے جبکہ آپ کا ٹنل مردہ ہے: جانچ اور ٹنل مختلف قواعد سے پرکھے جاتے ہیں۔
سیشن کی میعاد ختم ہونا دراصل کیا ری سیٹ کرتا ہے
مقامات آپ کے VPN اکاؤنٹ سے غیر متعلق وجوہات کی بنا پر سیشن ختم کرتے ہیں: غیر فعالیت کا وقت، سیشن کی زیادہ سے زیادہ لمبائی، نیا DHCP لیز، یا کسی دوسرے ایکسیس پوائنٹ سے دوبارہ جڑنا۔ جب ٹائمر بجتا ہے، سیشن جدول کا اندراج غائب ہو جاتا ہے اور منظوری سے پہلے کا قاعدہ مجموعہ بالکل ویسے ہی لوٹ آتا ہے جیسے چیک اِن کے وقت تھا۔
قائم شدہ ٹنل اکثر اتنی دیر زندہ رہتا ہے کہ صحت مند دکھے۔ زندگی برقرار رکھنے والے پیغامات باہر جاتے رہتے ہیں، اور کلائنٹ اسے محسوس کرتا ہے یا نہیں یہ اس پر منحصر ہے کہ وہ بے جواب ٹریفک سے کیسے نمٹتا ہے، اس لیے راستہ جانے کے بعد بھی حالت کی روشنی کچھ دیر سبز رہ سکتی ہے۔ پھر ٹنل گر جاتا ہے اور دوبارہ جڑنے کی ہر کوشش انہی بند پورٹوں پر ناکام ہوتی ہے۔
اس لمحے کلائنٹ کی خرابی بتاتی ہے کہ آپ کس مرحلے پر ہیں، اگر غور سے پڑھیں:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
ایک تفصیل لوگوں کو گمراہ کرتی ہے: جب سیشن MAC پتے سے بندھا ہو، سائن اِن صفحہ دوبارہ لوڈ کرنا مدد نہ کر سکتا ہے۔ آپ کو رابطہ چھوڑ کر دوبارہ جڑنا ہوگا، تاکہ پورٹل ختم شدہ کوشش کے بجائے نئی منظوری کی کوشش دیکھے۔
پہلے سائن اِن کریں، پھر ٹنل اٹھائیں
جو ترتیب کام کرتی ہے وہ یہ ہے: آلے کی منظوری دیں، راستہ ثابت کریں، VPN شروع کریں، ٹنل ثابت کریں، اور پھر اپنی معمول کی روک بحال کریں۔ وہ آخری قدم اہم ہے کیونکہ پورٹل تک پہنچنے کے لیے درکار عارضی حالت وہی حالت ہے جسے ایمرجنسی سوئچ روکنے کے لیے موجود ہے۔
ٹنل سے باہر روکنے کا اختیار رکھنے والے ڈیسک ٹاپ کلائنٹ کو پورٹل صفحہ لوڈ ہونے کے لیے روکنا پڑتا ہے، اور اس ٹنل سے باہر کی ونڈو میں حساس ایپس بند رکھنی چاہئیں؛ مقامی ٹریفک بغیر تحفظ کے باہر جانے کا یہی واحد وقفہ ہے۔ منظم اور ہمیشہ آن رہنے والے آلے کو چاہیے کہ آپ کی پالیسی ہٹانے کے بجائے اس کے مالک کی شائع کردہ طریقہ کار استعمال کرے۔ اگر پورٹل سرٹیفکیٹ کی وارننگ دکھائے تو رک جائیں: اسے قبول کرنا آپ کا سیشن مقام کے روکنے والے پراکسی سے گزارتا ہے، اور وہ پراکسی آپ کی بھیجی ہر چیز پڑھ سکتی ہے۔ Android پر ہمیشہ آن VPN کے نیچے لاک ڈاؤن ٹنل اٹھنے سے پہلے ٹریفک روکتا ہے، اور کچھ بلڈز پورٹل کے بہاؤ کو مستثنیٰ نہیں کر سکتے؛ اگر آپ کا نہیں کر سکتا تو لاک ڈاؤن بند چھوڑنے کے بجائے مقام کی متبادل رسائی یا دوسرا آلہ استعمال کریں۔ Apple کے آن ڈیمانڈ قواعد ایسے لکھے جا سکتے ہیں کہ جانچ کامیاب ہونے تک ٹنل سے انکار کریں، اور ہوٹل نیٹ ورکس میں آپ یہی رویہ چاہتے ہیں۔
اپنے موجودہ اوزاروں سے ترتیب وار تصدیق کریں۔ ٹنل سے پہلے جانچ ایسے چلائیں کہ ہیڈر اور باڈی دونوں نظر آئیں، اور دیکھیں کہ آپ کی VPN ترسیل کو کوئی جواب ملتا ہے یا نہیں:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'منظوری سے پہلے عام پورٹل دو میں سے ایک جواب دیتا ہے: 302 جس کا Location سائن اِن صفحے کی طرف اشارہ کرتا ہے، یا 200 جس کا HTML باڈی پورٹل صفحہ ہے۔ لکھیں کہ کون سا ملا۔ سائن اِن سے پہلے ری ڈائریکٹ ناکامی نہیں ہے؛ پورٹل بتا رہا ہے کہ کہاں جانا ہے۔ پورٹل کی کامیابی کی اطلاع کے بعد حکم دہرائیں اور ایسے 200 کی توقع کریں جس کا باڈی لفظی طور پر Success کا لفظ ہو۔ وہی سٹرنگ جانچ کو بامعنی بناتی ہے۔ اگر آپ کے کبھی سائن اِن کرنے سے پہلے ہوسٹ عام طور پر جواب دے، تو اس نیٹ ورک میں کوئی روکنے والا پورٹل نہیں۔ ریکارڈنگ میں منظوری سے پہلے پھینکنا وہ باہر جانے والے پیکٹ ہیں جن سے کچھ واپس نہیں آتا، جبکہ کام کرنے والا راستہ اسی بہاؤ کو تقریباً ایک سیکنڈ میں جواب دکھاتا ہے۔ جڑیں، پھر ریکارڈنگ دہرائیں۔
اگر پورٹل ہاں کہنے کے بعد بھی ٹنل ناکام رہے
سائن اِن کی کامیابی اجازت یافتہ ترسیل کے برابر نہیں۔ بہت سے مقامات پورٹل اور عام براؤزنگ کی اجازت دیتے ہیں مگر UDP مکمل طور پر بند کر دیتے ہیں، جس سے WireGuard اور UDP OpenVPN ٹوٹے رہتے ہیں اور TCP 443 کام کرتا ہے۔ اگر TCP 443 گزرے اور UDP نہ گزرے، تو یہ آپ کا غلط کنفیگر کیا ہوا کلائنٹ نہیں بلکہ مقام کی پالیسی ہے، اس لیے ترسیل بدلیں یا حد قبول کر کے آگے بڑھیں۔ اس کے بعد بھی دوبارہ جڑنا ناکام رہے تو درست خرابی محفوظ رکھیں؛ یہ بتاتی ہے کہ آپ کہاں پھنسے ہیں۔
دوسری ناکامیاں آلے میں رہتی ہیں۔ پرانے MAC سے اب بھی بندھا سیشن، اپنی لیز والا دوسرا Wi-Fi اڈاپٹر، یا پورٹل کے سرٹیفکیٹ استثنا کو کیش کرنے والا کلائنٹ — یہ ہر ایک صاف دوبارہ منظوری کے بعد بھی ناکام ہوتا رہ سکتا ہے۔ رابطہ چھوڑیں، دوبارہ منظوری دیں، اور کلائنٹ کی ترتیبات چھونے سے پہلے ایک بار کوشش کریں۔ اگر آپ ان اجزاء کے پیچھے کا ڈھانچہ چاہتے ہیں جن کی آپ نگرانی کر رہے ہیں تو RFC 8952 پڑھنے کے قابل ہے۔
اگر پورٹل خود منظوری دینے سے انکار کرے، تو مسئلہ اکاؤنٹ یا آلے کی تقسیم میں ہے اور کوئی VPN ترتیب اسے درست نہیں کرے گی۔ VPN کا خارجی ملک بدلنا مقام کی مقامی رسائی کی حالت ری سیٹ نہیں کرتا؛ وہ جدول آپ کے آلے سے بندھی ہے، آپ کے منتخب سرور سے نہیں۔ مقام کے آپریٹر سے پوچھیں اور وقت دیں، کیونکہ وہ سیشن جدول ہی دیکھے گا۔
اگلے سفر سے پہلے تین چیزیں لکھیں: صفر قدم کے طور پر پورٹل صفحہ، آپ کے ساتھ لے جانے والے ہر آلے کے لیے روک روکنے کا قدم، اور ایک متبادل ترسیل جسے آپ نے واقعی جانچا ہو۔ جب دس منٹ پہلے کام کرنے والا ٹنل دوبارہ رکے، تو اسے ختم شدہ منظوری سمجھیں اور VPN پروفائل چھونے سے پہلے پورٹل دوبارہ جانچیں۔