OpenVPN کے لیے SOCKS5 پراکسی: TCP ٹنل یا ایپس کو پراکسی کرنا؟

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

ایک پابندی ڈیزائن طے کرتی ہے

SOCKS5 واقعی UDP ایسوسی ایشن موڈ متعین کرتا ہے۔ پھر بھی OpenVPN کلائنٹ کی پراکسی سپورٹ اسٹریمز کے گرد بنی ہے: socks-proxy TCP پروفائلز کے لیے دستاویزی ہے، اور HTTP CONNECT پراکسی کے پاس ڈیٹا گرام کے لیے کوئی راستہ نہیں۔ دستاویز کی ایک سطر کنفیگریشن فائل چھونے سے پہلے آرکیٹیکچر طے کر دیتی ہے۔

اس لیے سوال یہ نہیں کہ کون سی پراکسی منتخب کریں۔ سوال یہ ہے کہ ٹنل اسٹریم بنتی ہے، یا ڈیٹا گرام رہتی ہے اور کسی اور کو پراکسی کرنے کا موقع دیتی ہے۔

آپشن A: ٹنل کو اسٹریم بنائیں

اس کے لیے TCP سننے والے کے ساتھ سرور اور پراکسی کا نام دینے والی کلائنٹ پروفائل درکار ہے۔ دونوں حصے ضروری ہیں، اور لوگ سرور کا حصہ بھول جاتے ہیں:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

آخری سطر کو http-proxy proxy.internal 8080 سے بدلیں جب پراکسی HTTP بولتی ہے، اور اگر مانگے تو اسناد کی فائل شامل کریں۔ پراکسی کو آپ کے VPN پورٹ پر CONNECT کرنے کے لیے تیار ہونا چاہیے، اور سرور کو TCP پر جواب دینا چاہیے؛ صرف UDP سننے والا اس کوشش کو نظر انداز کرتا ہے۔ 443 کا انتخاب عملی قدم ہے، کیونکہ بہت سے محدود نیٹ ورک اسی کی اور بہت کم دوسری چیزوں کی اجازت دیتے ہیں۔

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

آپشن B: ٹنل کو تنہا چھوڑ دیں

جب ٹنل کو UDP پر ہی رہنا ہو، تو ٹنل وہ جگہ نہیں جہاں آپ کچھ کنفیگر کرتے ہیں۔ اس کے بجائے ایپس سے جانے والا TCP مقامی SOCKS سننے والے کی طرف ری ڈائریکٹ ہوتا ہے، اور ایپس کو کبھی پتہ نہیں چلتا کہ پراکسی موجود ہے۔ Linux پر یہ عام طور پر redsocks اور nat ٹیبل میں NAT REDIRECT قاعدہ ہوتا ہے۔

پھر بھی صرف TCP۔ privoxy جیسی صرف-HTTP پراکسی من مانی پروٹوکول منتقل نہیں کر سکتی، اور یہ ڈیزائن ایپس کے لیے ڈیٹا گرام سپورٹ بھی شامل نہیں کرتا۔

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

ہر آپشن کہاں ناکام ہوتا ہے

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

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

کوئی بھی آپشن ڈیوائس کی ضرورت نہیں بدلتا۔ پیکٹوں کو کرنل کے روٹ کرنے سے پہلے اب بھی TUN یا TAP نوڈ درکار ہے، اس لیے عمل کو اب بھی /dev/net/tun پر اجازت درکار ہے۔ ریپر یہ بدلتا ہے کہ وہ نوڈ کھلنے کے بعد کیا ہوتا ہے، یہ نہیں کہ آپ کو اس کی ضرورت ہے یا نہیں۔

ثابت کریں کہ آپ نے کون سا راستہ بنایا

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

ss -tnp | grep openvpn

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

ٹرانسپورٹ اور قبول کرنے والی پراکسی کو دیرپا جگہ پر نوٹ کریں۔ جب وہی پروفائل کسی دوسرے نیٹ ورک پر ناکام ہو، تو وہ نوٹ سیکنڈوں میں پراکسی کو خارج یا تصدیق کر دیتا ہے۔