ہوٹل کے وائی فائی پر OpenVPN کنیکٹ نہیں ہوتا؟ TCP 443 آزمائیں

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

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

کلائنٹ سے شروع کریں: اسٹیٹس لائن پڑھیں

اسٹیٹس لائن بتاتی ہے کہ کون سا مرحلہ ناکام ہوا۔ کنیکٹ ہو رہا ہے پر پھنسا کلائنٹ ابھی ہوسٹ حل کر رہا ہے یا بیرونی ساکٹ کھول رہا ہے؛ سرور کا انتظار ہے تک پہنچنے والے کے پاس راستہ ہے مگر جواب نہیں؛ جو تصدیق کر کے بعد میں گر جاتا ہے اس کا مسئلہ بالکل الگ ہے۔ کلائنٹ لاگ اور پروفائل کے اپنے remote اور proto فیلڈز بتاتے ہیں کہ کلائنٹ کیا کرنے کی کوشش کر رہا ہے، اور کمانڈ لائن کلائنٹ پر --verb 4 وہی تفصیل چھاپتا ہے۔ اسی کا آپ کے سامنے کے نیٹ ورک سے موازنہ ہی 'VPN بلاک ہے' کو ٹھوس دعوے میں بدلتا ہے۔

پھر اپنے پاس پہلے سے موجود اوزاروں سے نیٹ ورک جانچیں۔ nc -vzu 203.0.113.10 1194 ایک UDP ڈیٹاگرام بھیجتا ہے، curl -v telnet://203.0.113.10:443 بتاتا ہے کہ TCP ہینڈ شیک مکمل ہوتا ہے یا نہیں، اور HTTPS صفحہ لوڈ کرنے والا براؤزر صرف یہ ثابت کرتا ہے کہ باہر جانے والا 443 اسی ایک ہوسٹ تک پہنچتا ہے۔ چھوٹی جانچیں وہ جواب دیتی ہیں جو VPN کلائنٹ نہیں دے سکتا: کون سا پورٹ اور کون سا پروٹوکول اس نیٹ ورک سے باہر نکلتا ہے۔

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

لسنر اور پروفائل کو ساتھ منتقل کریں

سرور کی طرف، لسنر کو اسی پر رکھیں جس کی نیٹ ورک اجازت دیتا ہے: سرور کنفیگریشن میں port 443 اور proto tcp، پھر سروس دوبارہ شروع کریں اور ss -lntp سے ساکٹ کی تصدیق کریں۔ کلائنٹ کی طرف پروفائل کو متفق ہونا پڑے گا، کیونکہ ٹرانسپورٹ اور پورٹ ٹنل سے باہر ہیں: .ovpn میں proto tcp اور port 443، یا ایپ کی سیٹنگ اسکرین میں متعلقہ فیلڈز۔ اب بھی UDP 1194 کی طرف نشانہ پروفائل بالکل پہلے کی طرح ناکام ہوتا ہے، اور پہلے ہی درست کیے گئے فائر وال کو مورد الزام ٹھہرانے کا دل کرتا ہے۔ اگر وہی ہوسٹ 443 پر HTTPS کا بھی جواب دیتا ہے، تو دونوں لسنر وہ پتہ اور پروٹوکول شیئر نہیں کر سکتے؛ VPN کو دوسرا پتہ دیں یا آگے ڈیملٹی پلیکسر رکھیں۔

دونوں سروں پر tcpdump -ni any port 443 کے ساتھ پہلا کنکشن دیکھیں۔ وہ پیکٹ جو کلائنٹ سے نکل کر کبھی نہیں پہنچتے، اس کا مطلب ہے کہ نیٹ ورک پھر بھی فلٹر کر رہا ہے، یا پروفائل کا پتہ وہ نہیں جو آپ سمجھ رہے ہیں۔ بغیر جواب پہنچنے والے پیکٹ آپ کو سرور لاگ کی طرف واپس بھیجتے ہیں، جہاں پروٹوکول کی عدم مطابقت فوراً مسترد شدہ پیکٹ کے طور پر ظاہر ہوتی ہے۔

جب نیٹ ورک سے صرف پراکسی باہر نکلے

کچھ مہمان نیٹ ورک HTTP پراکسی کے سوا کچھ نہیں دیتے، جو بند پورٹ سے مختلف پابندی ہے اور OpenVPN سے زیادہ کو باہر رکھتی ہے۔ صرف PPTP، L2TP/IPsec یا ننگے IPsec بولنے والے کلائنٹس کے لیے اس میں سے گزرنے کا کوئی راستہ نہیں، کیونکہ وہ ڈیزائن مانتے ہیں کہ ان کا بیرونی پروٹوکول سیدھا سرور تک پہنچے گا۔ OpenVPN کر سکتا ہے، کلائنٹ پروفائل میں http-proxy proxy.example.net 8080 کے ساتھ، بشرطیکہ پراکسی آپ کے پورٹ تک CONNECT طریقہ کی اجازت دے۔ SOCKS پراکسی اور بھی آسان ہے، کیونکہ اندر کیا ہے اس کی پروا کیے بغیر اسٹریم آگے بھیجتی ہے۔

جہاں کلائنٹ میں پراکسی سپورٹ نہیں، وہاں 443 پر SSH ٹنل عام طور پر باقی رہتی ہے۔ یہ دوسری تہہ شامل کرتی ہے، اور نیٹ ورک کا منتظم اس بارے میں رائے رکھ سکتا ہے، اس لیے اسے ایک سفر کا پل سمجھیں، فن تعمیر نہیں۔

رکھنے سے پہلے متبادل راستے کی قیمت جانیں

TCP کے اندر TCP کی معلوم قیمت ہے۔ جب بیرونی کنکشن TCP ہو اور پے لوڈ بھی TCP، تو کھویا ہوا سیگمنٹ دونوں تہوں پر دوبارہ ترسیل پیدا کرتا ہے، اور اندرونی کنکشن ایسے نقصان سے پیچھے ہٹتا ہے جو اسے نظر نہیں آتا۔ براؤزنگ یہ سہہ جاتی ہے؛ متعامل سیشنز اور کالز اسے محسوس کرتے ہیں۔ TCP 443 لسنر کو ان نیٹ ورکس کے لیے متبادل راستہ رکھیں جو اس کا مطالبہ کرتے ہیں، اور UDP کو ان سب کے لیے طے شدہ رہنے دیں جو اب بھی اسے گزرنے دیتے ہیں۔

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