ہوٹل کا Wi-Fi: VPN سرور تک پہنچنے سے پہلے ہی ناکام ہو جاتا ہے
ٹنل ناکام ہوتا ہے کیونکہ کیپٹو پورٹل نے آپ کو ابھی اجازت نہیں دی۔ ہوٹل کے نیٹ ورک میں سائن ان کریں، تصدیق کریں کہ عام HTTPS کام کرتا ہے، پھر VPN جوڑیں۔
VPN کلائنٹ گھومتا رہتا ہے، پھر بتاتا ہے کہ سرور تک نہیں پہنچ سکتا، اور سب سمجھتے ہیں کہ ہوٹل VPN بلاک کرتا ہے۔ عام طور پر اتنا ڈرامائی کچھ نہیں ہوا: نیٹ ورک نے آپ کو ابھی باہر جانے نہیں دیا۔ کیپٹو پورٹل ہر کنکشن کو روکتا ہے جب تک آپ سائن ان نہ کریں، اور ٹنل مکمل نہیں ہو سکتا جب لاگ ان صفحہ اس کے پیکٹ پکڑ رہا ہو۔ ٹنل کو قصوروار ٹھہرانے سے پہلے سائن ان مکمل کریں۔
داستان: ہوٹل VPN بلاک کرتا ہے
زیادہ تر ہوٹل نیٹ ورک ٹنل کو خاص طور پر فلٹر نہیں کرتے۔ وہ ویب ٹریفک کو تب تک پکڑتے ہیں جب تک مہمان تصدیق نہ ہو، اور ڈیوائسز محدود کر سکتے ہیں، سیشن ختم کر سکتے ہیں یا رفتار کم کر سکتے ہیں۔ ان میں سے ہر ایک ایسی ناکامی پیدا کرتا ہے جو VPN کلائنٹ کے اندر سے بلاک جیسی لگتی ہے۔
یہاں ٹنل کمزور تشخیصی آلہ ہے، کیونکہ پورٹل کے مجاز نہ ہونے تک یقینی طور پر ناکام ہونے والی یہ واحد ایپلیکیشن ہے۔ عام ویب رسائی بہتر اشارہ ہے، کیونکہ یہ آپ کو لاگ ان صفحہ خود دکھا سکتی ہے۔
یہ ترتیب ایک اور وجہ سے بھی اہم ہے: کِل سوئچ یا ہمیشہ آن موڈ والا کلائنٹ پورٹل لوڈ کرنے سے انکار کر دے گا، اور صارف سمجھے گا کہ نیٹ ورک خراب ہے، سیٹنگ نہیں۔ دونوں حقائق بیک وقت سچ ہیں، اور ہوٹل میں صرف ایک بدلا جا سکتا ہے۔ کلائنٹ کے اپنے کنٹرول سے تحفظ بند کریں، سائن ان کریں اور پھر دوبارہ چالو کریں۔ باقی سب اصل ترتیب چھپانے والا راستہ ہے۔
پہلے پورٹل مکمل کریں، پھر عام HTTPS جانچیں
عملے سے سرکاری نیٹ ورک نام اور سائن ان کا طریقہ پوچھیں۔ قابل اعتماد SSID ملکیت کا ثبوت نہیں، اور ملتے جلتے نام کا دوسرا نیٹ ورک عوامی مقامات پر عام چال ہے۔ جہاں دستیاب ہو وہاں آپریٹنگ سسٹم کا اپنا سائن ان اشارہ استعمال کریں، یا ہوٹل کا دستاویزی صفحہ۔
curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/پہلی درخواست سادہ HTTP کے ذریعے ایک معروف کیپٹو پورٹل شناختی نقطہ پوچھتی ہے؛ ری ڈائریکٹ یا غیر متوقع مواد کا مطلب ہے کہ آپ اب بھی پورٹل کے پیچھے ہیں۔ دوسری عام HTTPS سائٹ جانچتی ہے۔ اگر پہلی رکاوٹ دکھائے اور دوسری ناکام ہو، تو سائن ان نامکمل ہے اور VPN کا اس سے کوئی تعلق نہیں۔
ذاتی ڈیوائس پر پورٹل لوڈ ہونے کے لیے کِل سوئچ یا ہمیشہ آن VPN کو کلائنٹ کے معاون کنٹرول سے بند کرنا پڑ سکتا ہے۔ اس دورانیے میں حساس ایپلیکیشنز بند رکھیں اور فوراً بعد تحفظ دوبارہ چالو کریں۔ منظم ڈیوائس پر خود پالیسی ہٹانے کے بجائے منتظم کی منظور شدہ طریقہ کار پر عمل کریں۔
آن لائن آنے کے لیے کبھی سرٹیفکیٹ انتباہ کو نظرانداز نہ کریں اور نہ ہی نامعلوم سرٹیفکیٹ یا معاون ایپلیکیشن انسٹال کریں۔ اگر پورٹل کچھ غیر متوقع مانگے، تو عملے سے تصدیق کریں، اور اگر ڈیوائس آجر کی ہے تو منتظم سے۔
اصل پروفائل اور اس کی خرابی محفوظ رکھیں
عام رسائی کام کرنے پر اصل پروفائل جوڑیں اور درست خرابی درج کریں۔ تصدیق سے انکار اکاؤنٹ کا مسئلہ ہے، گفت و شنید کے دوران وقت کا ختم ہونا راستے کا مسئلہ ہے، اور قائم ہو کر کچھ نہ لے جانے والا ٹنل روٹنگ یا پالیسی کا مسئلہ ہے۔
ان تینوں کو مختلف اگلے قدم درکار ہیں، اور خرابی کا اسکرین شاٹ تفصیل سے زیادہ قیمتی ہے۔ وقت بھی لکھیں، کیونکہ ہوٹل سیشن کی حد ایک گھنٹے میں ختم ہو سکتی ہے اور ایسی ناکامی پیدا کر سکتی ہے جو بےترتیب لگے۔ اگر کلائنٹ لاگ دیتا ہے، تو پوری فائل کے بجائے پہلی ناکامی کے ارد گرد کا حصہ رکھیں۔ وہ اقتباس عام طور پر پروفائل کے مالک کے لیے مرحلہ پہچاننے کے لیے کافی ہوتا ہے۔
اگر عام رسائی کام کرتی ہے اور گفت و شنید اب بھی وقت ختم کرتی ہے، تو ہوٹل سے پوچھیں کہ کیا یہ اس ٹریفک کی تائید کرتا ہے، اور ڈیوائس اور پروفائل کو مستقل رکھتے ہوئے کسی قابل اعتماد ہاٹ اسپاٹ سے موازنہ کریں۔ ہاٹ اسپاٹ پر کام کرنا پروفائل کے بارے میں کچھ ثابت کیے بغیر توجہ ہوٹل کے راستے پر مرکوز کر دیتا ہے۔
صرف وہی متبادل استعمال کریں جو آپریٹر فراہم کرتا ہے
مطابقت رکھنے والا TCP پروفائل وہاں کامیاب ہو سکتا ہے جہاں دیا گیا UDP راستہ کام نہیں کرتا، لیکن صرف اس صورت میں جب سرور واقعی اس ٹرانسپورٹ اور پورٹ پر سن رہا ہو۔ TCP پورٹ 443 خود بخود عام HTTPS نہیں سمجھا جاتا، اور یہ محدود نیٹ ورک سے گزرنے کی ضمانت نہیں۔
sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4
دیے گئے پروفائل کو زیادہ تفصیل سے چلانا پہلی مفید خرابی کو عام ناکامی کے ڈائلاگ میں دبانے کے بجائے نظر آنے دیتا ہے۔ آپریٹر کی دی ہوئی فائل استعمال کریں، پورٹ یا پروٹوکول خود نہ بدلیں، کیونکہ مقامی تبدیلی دوسری طرف مماثل سننے والا نہیں بنا سکتی۔
اگر ٹنل بار بار ری سیٹ ہو، تو دیکھیں کہ پورٹل دوبارہ ظاہر ہوتا ہے یا مقامی سگنل گرتا ہے، اور ایک ساتھ کئی پروٹوکول بدلنے کے بجائے استحکام کی جانچ پر عمل کریں۔ پھر وہ ایپلیکیشن جانچیں جس کی آپ کو واقعی ضرورت ہے اور عام رازداری کے کنٹرول بحال کریں۔ ایک سائٹ لے جانے والا مگر دوسری نہ لے جانے والا کنکشن پورٹل کا نہیں، روٹنگ یا پالیسی کا سوال ہے۔
آخر میں، لیپ ٹاپ کے سو جانے کے بعد بحالی جانچیں۔ پورٹل کی اجازت ٹنل سے آزاد طور پر ختم ہو سکتی ہے، اس لیے خودکار طور پر دوبارہ جڑنے والا ڈیوائس ایسے نیٹ ورک پر واپس آ سکتا ہے جو اسے بھول چکا ہے۔ پورٹل صفحہ دوبارہ کھولنا عام قدم ہے، VPN کے خراب ہونے کی علامت نہیں۔