کیوں ایک OpenVPN پروفائل گھر میں کام کرتی ہے مگر ہوٹل میں ناکام ہو جاتی ہے

دفتر کا Wi-Fi اور ہوٹل کا کمرہ ایک ہی لیپ ٹاپ کو دو بالکل مختلف نیٹ ورک دے سکتے ہیں، اور درمیان والی پروفائل کو اس کا کچھ علم نہیں ہوتا۔ گھر میں جو کام کرتا ہے وہ کھلے اپ لنک، کام کرنے والے نام کی تحلیل اور ایسے مقامی سب نیٹ کا مفروضہ رکھتا ہے جو ٹنل کی لے جانے والی کسی چیز سے نہ ٹکرائے۔ ان میں سے ہر مفروضہ الگ الگ ناکام ہو سکتا ہے۔

اسے ڈی بگ کرنے کا مفید طریقہ یہ ہے کہ نیٹ ورک کو چار الگ حقائق کے طور پر لیں اور پھر انہیں ترتیب سے جانچیں۔ پہلے پروفائل پر اندازہ لگانا عام طور پر ایسی تبدیلی لاتا ہے جو کچھ درست نہیں کرتی اور شواہد چھپا دیتی ہے۔

چار نیٹ ورک حقائق مقامات کے درمیان بدلتے ہیں

پہلی حقیقت یہ ہے کہ مقامی نیٹ ورک آپ کو باہر جانے دیتا ہے یا نہیں۔ کیپٹو پورٹل آلے کو لاگ ان صفحے پر لاتا ہے اور وہ صفحہ مکمل ہونے تک باقی سب کچھ روک دیتا ہے، یعنی پروفائل کتنی ہی درست ہو ٹنل شروع نہیں ہو سکتی۔

دوسری نام کی تحلیل ہے۔ DNS کو روکنے والا پورٹل ہر سوال کا جواب اپنے پتے سے دیتا ہے، اس لیے VPN کا ہوسٹ نام پورٹل پر حل ہو جاتا ہے اور کلائنٹ ویب صفحے تک ٹنل بنانے کی کوشش کرتا ہے۔

تیسری نقل و حمل کی فلٹرنگ ہے۔ جو نیٹ ورک صرف براؤزنگ کی اجازت دینا چاہتے ہیں وہ TCP 443 کو کسی بھی منزل تک جانے دیتے ہیں اور UDP سمیت تقریباً باقی سب کچھ گرا دیتے ہیں۔

چوتھی پتہ بندی ہے۔ مقامی سب نیٹ ٹنل کے پیچھے والے نیٹ ورک سے اوورلیپ ہو سکتا ہے، یا اپ لنک کوئی قابل استعمال IPv4 راستہ فراہم نہیں کرتا۔

نام کی تحلیل اور کیپٹو پورٹل

پروفائل میں ہوسٹ نام کو سرور کے عددی پتے سے بدلیں اور دوبارہ کوشش کریں۔ اگر IP جڑ جائے مگر نام نہ جڑے تو قصور نام کی تحلیل کا ہے، اور پروفائل بذات خود ٹھیک ہے۔

VPN کو چھونے سے پہلے براؤزر کھولیں اور ایک عام HTTP صفحہ کھولنے کی کوشش کریں۔ لاگ ان صفحے پر ری ڈائریکٹ ہونا یعنی پورٹل ابھی باقی ہے؛ اسے مکمل کریں، پھر دوبارہ جڑیں۔ بہت سے ہوٹل کچھ گھنٹوں بعد سیشن بھی ختم کر دیتے ہیں، جو لاگ ان مسئلے کے بجائے دوپہر کے وقفے جیسا لگتا ہے۔

اگر عددی پتہ بھی ناکام ہو تو نام کی تحلیل وضاحت نہیں ہے، اس لیے نقل و حمل کی طرف بڑھیں۔ جو پتہ آپ نے جانچا اسے رکھیں، کیونکہ یہ اگلی جانچ کو بتاتا ہے کہ پیکٹ مشین سے نکلے بھی یا نہیں۔

نقل و حمل کی فلٹرنگ: پہلے UDP، بیک اپ کے طور پر TCP 443

UDP 1194 پر OpenVPN کا بہاؤ ہوٹل فائر وال کی پہچان والی کسی چیز جیسا نہیں لگتا، اس لیے بغیر خرابی کے گرا دیا جاتا ہے۔ کلائنٹ اپنی مہلت ختم ہونے تک دوبارہ کوشش کرتا ہے، اور صارف انکار کے بجائے ایسا کنکشن دیکھتا ہے جو کبھی قائم نہیں ہوتا۔ ایسا رویہ رکھنے والے فائر وال شاذ و نادر ہی گرانے کا ریکارڈ کہیں ایسی جگہ رکھتے ہیں جہاں آپ دیکھ سکیں۔ انکار کا نہ ہونا بذات خود سراغ ہے۔

TCP 443 قابل اعتماد بیک اپ ہے کیونکہ نیٹ ورک اسے عام HTTPS سے الگ نہیں کر سکتا۔ آپریٹر کی TCP پروفائل موجود ہو تو وہی استعمال کریں، کیونکہ سرور کو بھی اسی نقل و حمل اور پورٹ پر سننا پڑتا ہے؛ صرف کلائنٹ بدلنا دوسری قسم کی ناکامی پیدا کرتا ہے۔ اگر TCP پروفائل نہ ہو تو پورٹ میں ترمیم کر کے نئی ایجاد کرنے کے بجائے آپریٹر سے پوچھیں۔ سرور کی طرف بھی اتفاق ضروری ہے، اور عدم مطابقت پھر فائر وال مسئلے جیسی لگتی ہے۔

کارکردگی کی قیمت کی توقع رکھیں۔ TCP کے اندر TCP نقصان والی لنک پر دوبارہ ترسیل بڑھاتا ہے، اس لیے کام کرنے والی TCP ٹنل بھی بھیڑ والے ہوٹل نیٹ ورک پر سست محسوس ہو سکتی ہے۔ یہ رسائی کے لیے سودا ہے، پیچھا کرنے والا نقص نہیں۔

پتوں کا ٹکراؤ اور IPv4 کے بغیر اپ لنک

ٹنل قائم ہو کر بھی کچھ نہیں ڈھو سکتی۔ جب مقامی LAN اور دور کا نیٹ ورک 192.168.1.0/24 جیسا سابقہ ساجھا کریں، کلائنٹ دور کے میزبان کو براہ راست جڑا سمجھتا ہے اور پیکٹ کو ٹنل کے بجائے مقامی لنک پر بھیجتا ہے۔ علامت ایک ناقابل رسائی سب نیٹ کے ساتھ کامیاب کنکشن ہے، جسے سرور کی طرف کے روٹ مسئلے کے طور پر غلط پڑھنا آسان ہے۔

مستقل حل یہ ہے کہ دور کے LAN کو غیر معمولی نجی رینج میں منتقل کیا جائے۔ ایسی رینج چننا جو گھر میں کوئی استعمال نہ کرتا ہو، مثلاً 10.42.0.0/24، مسئلے کو ایک کے بجائے ہر آئندہ مقام کے لیے روکتا ہے۔ مقامی وقتی حل اُس ہوٹل، ہاٹ اسپاٹ یا راؤٹر سے بچنا ہے، جو حل ہی نہیں۔

موبائل اپ لنک دو قسمیں شامل کرتے ہیں۔ کیریئر درجے کا NAT یعنی آنے والے کنکشن نہیں پہنچتے، جو سرور ہوسٹ کرنے پر اہم ہے مگر باہر جانے والے کلائنٹ کے لیے نہیں۔ NAT64 ترجمے کے ساتھ صرف IPv6 کے طور پر ترتیب دیا گیا APN ایسے کلائنٹ کو ناکام کر سکتا ہے جو حقیقی IPv4 راستے پر اصرار کرتا ہے، اور معمول کا علاج APN پروٹوکول کو IPv4 یا دوہرے اسٹیک میں بدلنا ہے۔

ٹنل اٹھنے کے بعد کی علامات

جڑ کر پھر خاموش ہو جانے والی ٹنل عام طور پر keepalive یا MTU مسئلہ ہے، بند پورٹ نہیں۔ مقررہ منٹوں بعد گرنے والا کنکشن keepalive یا دوبارہ مذاکرات کے ٹائمر کی طرف اشارہ کرتا ہے۔ کلائنٹ کو اس کے ساتھی کی جانچ اور جواب رکنے پر دوبارہ شروع کرنے پر سیٹ کریں، اور اگر ping کامیاب ہوں مگر بڑی منتقلیاں رکیں تو چھوٹا ٹنل MTU جانچیں۔

مدد مانگنے سے پہلے تین چیزیں لکھیں: جو پتہ آپ نے آزمایا اور اس نے جواب دیا یا نہیں، جو نقل و حمل اور پورٹ آپ نے استعمال کیے، اور جو نیٹ ورک ناکام ہوا اس کا مقامی سب نیٹ۔ مل کر یہ نام کی تحلیل کو نقل و حمل فلٹرنگ اور پتہ ٹکراؤ سے الگ کرتے ہیں، اور شواہد کے سامنے ٹکنے والی وجوہات یہی ہیں۔