OpenVPN پورٹ 443 پر اب بھی بند؟ دیکھیں نیٹ ورک کیا جانچتا ہے

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

ہینڈ شیک نمبر سے زیادہ ظاہر کرتا ہے

TCP 443 پر مقامی VPN سننے والا پہلے پیکٹ ہی سے اپنے پروٹوکول میں بولتا ہے۔ ClientHello میں ورژن کا خانہ، بے ترتیب قدر اور توسیعات کی فہرست ہوتی ہے، اور چند سو بائٹ پڑھنے والا آلہ کچھ بھی ڈکرپٹ کیے بغیر فرق دیکھ سکتا ہے۔ پورٹ نمبر پورا کرنا سستا ہے، اور فلٹر واقعی پروٹوکول کی شکل ہی جانچتا ہے۔ قواعد عام طور پر پروٹوکول کے حساب سے بھی لکھے جاتے ہیں، اس لیے TLS جانچنے والی پالیسی UDP کے بارے میں کچھ نہیں کہتی۔

شفاف پراکسی جو درست TLS سیشن کا مطالبہ کرتا ہے، ترتیب کے دوران ہی رابطہ منقطع کر دیتا ہے، اکثر TCP ہینڈ شیک مکمل ہونے کے بعد۔ یہ تفصیل بعد میں اہم ہے، کیونکہ اس کا مطلب ہے کہ ساکٹ بننے کے بعد کلائنٹ لاگ رک جاتا ہے۔

بہاؤ کو لپیٹنے سے دو ناکامی کے مقام بنتے ہیں

stunnel جیسی TLS لپیٹ متوقع شکل واپس لاتی ہے: کلائنٹ مقامی سننے والے سے جڑتا ہے، لپیٹ سرور کے ساتھ 443 پر حقیقی TLS سیشن کھولتی ہے، اور سرور پر دوسری لپیٹ ڈکرپٹ شدہ بائٹ VPN ڈیمن تک بھیجتی ہے۔ بیرونی سیشن اب کسی بھی دوسرے HTTPS رابطے جیسا لگتا ہے۔ سرور پر VPN ڈیمن کو صرف loopback پر سننا چاہیے، کیونکہ لپیٹ سے باہر کسی کو اس تک پہنچنے کی ضرورت نہیں۔

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

لپیٹ تک کا راستہ ہی جال ہے

سرنگ بلند ہوتے ہی ڈیفالٹ راستہ اسی کی طرف اشارہ کرتا ہے، اور بیرونی TLS سیشن کو ایسا راستہ چاہیے جو اس سرنگ میں نہ جائے جسے یہ اٹھائے ہوئے ہے۔ عام VPN کلائنٹ اس پتے کی حفاظت کرتا ہے جسے وہ ڈائل کرتا ہے؛ لپیٹ والا کلائنٹ اپنے ہی loopback کو ڈائل کرتا ہے، اس لیے لپیٹ کا منزل پتہ اس حفاظت کو نظر نہیں آتا۔

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

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

Android پر اس استثنا کا متبادل فی ایپ ترتیب ہے: لپیٹ ایپ کو سرنگ سے باہر رکھیں تاکہ اس کی اپنی ٹریفک موبائل رابطے سے باہر جائے۔ باہر نہ رکھنے پر لپیٹ اسی سرنگ میں بھیج دی جاتی ہے جسے یہ بنانا چاہتی ہے، اور دوبارہ جڑنے کا چکر سرور کی مشکل جیسا لگتا ہے۔

کچھ بدلنے سے پہلے وقت پڑھیں

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

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

دیکھا گیا رویہ لکھیں: سیشن کتنی دیر رہا، ساکٹ کھلا یا نہیں، لپیٹ نے ہینڈ شیک لاگ کیا یا نہیں۔ ان میں سے ہر ایک اگلے امتحان کو تنگ کرتا ہے۔

ایک وقت میں ایک متغیر جانچیں

پہلے UDP جانچیں، کیونکہ کچھ نیٹ ورک اسے مکمل طور پر گرا دیتے ہیں اور UDP ناکامی 443 کے بارے میں کچھ نہیں کہتی۔ پھر لپیٹ کے بغیر TCP 443 آزمائیں، پھر 443 پر لپیٹ۔ ہر قدم پر کلائنٹ لاگ پڑھیں اور رویہ بدلتے ہی رک جائیں۔

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