OpenVPN بذریعہ SOCKS5: ورژن، ٹرانسپورٹ اور DNS کی مطابقت
SOCKS زنجیر اُس وقت ناکام ہوتی ہے جب پراکسی ورژن، ٹرانسپورٹ یا DNS راستہ متفق نہ ہو۔ SOCKS5 کی مطابقت رکھیں، TCP لے جائیں، اور زنجیر کو ایک نیم اسپیس میں رکھیں۔
اس ورک اسٹیشن سے نکلنے کا ایک راستہ SOCKS پراکسی ہے، اور اس کے پیچھے OpenVPN کنیکٹ ٹائم آؤٹ کی اطلاع دیتا ہے جس کے ساتھ کوئی مفید تفصیل نہیں ہوتی۔ اسی مشین کا براؤزر اُس پراکسی سے کام کرتا ہے، اسناد درست ہیں، اور پورٹ جواب دیتا ہے۔ تین چیزیں اتنی مختلف ہوتی ہیں کہ پہلے جانچی جائیں: وہ SOCKS ورژن جو پراکسی بولتا ہے، وہ ٹرانسپورٹ جو کلائنٹ نے چنا، اور وہ جگہ جہاں نام کی تحلیل ہوتی ہے۔ فائر وال کو قصوروار ٹھہرانے سے پہلے ان میں سے ہر ایک کی تصدیق کریں۔
فائر وال سے پہلے SOCKS ورژن کی مطابقت رکھیں
کمیونٹی OpenVPN socks-proxy کے لیے SOCKS5 بولتا ہے۔ اسے ایسی پراکسی پر لگائیں جو صرف SOCKS4 پیش کرتی ہو؛ TCP کنکشن کھلتا ہے اور پھر رک جاتا ہے، کیونکہ کلائنٹ ایسے سلام کا جواب منتظر رہتا ہے جسے دوسرا سرا کبھی نہیں پڑھتا۔ باہر سے یہ ٹھہراؤ بالکل فلٹر شدہ پورٹ جیسا لگتا ہے، اسی لیے ورژن کا سوال کسی بھی فائر وال اصول سے پہلے آتا ہے۔ SOCKS سے واقف ایک بازیافت ایک ہی کمانڈ میں اسے طے کر دیتی ہے۔
curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
مکمل شدہ درخواست ایک ساتھ دو چیزیں ثابت کرتی ہے: پراکسی نے SOCKS درخواست قبول کی اور اس نے نام تحلیل کیا۔ کسی URL اسکیم کی ضرورت نہیں، کیونکہ curl ننگے میزبان کو HTTP سمجھتا ہے، اور یہ اس ٹیسٹ کے لیے کافی ہے۔
یہ بازیافت اُس ناکامی کو بھی خارج کرتی ہے جو کلائنٹ لاگ چھپاتا ہے۔ پراکسی براؤزر کو اجازت دے کر بھی VPN منزل سے انکار کر سکتی ہے، اور ایسے میں مسترد ہونا CONNECT پر ہوتا ہے، کسی بھی VPN تصدیق سے پہلے۔ OpenVPN صرف ٹائم آؤٹ بتاتا ہے، اس لیے پراکسی کا اپنا جواب وہ ثبوت ہے جو آپ کو درکار ہے۔
ٹرانسپورٹ دونوں طرف TCP ہونا چاہیے
SOCKS5 یہاں TCP اسٹریم لے جاتا ہے، اس لیے سرنگ کو خود proto tcp-client درکار ہے۔ وہ پروفائل جو اب بھی UDP پر ہے اس راستے سے کام نہیں کرے گا، کیونکہ کلائنٹ پروٹوکول کا UDP ایسوسی ایشن موڈ استعمال نہیں کرتا۔ پروفائل پلٹنا حقیقی تبدیلی ہے، رسمی نہیں: دور سرے کو اسی پورٹ پر TCP پر سننا ہوگا۔ پھر پے لوڈ TCP کے اندر TCP بن جاتا ہے، جہاں گمشدہ سیگمنٹ دو بار دوبارہ بھیجا جاتا ہے اور رفتار گرتی ہے، اور انٹرایکٹو سیشنز یہ بڑی منتقلیوں سے کہیں زیادہ محسوس کرتے ہیں۔
proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050
یہ ہدایت پراکسی میزبان، اختیاری پورٹ اور اختیاری اسناد فائل لیتی ہے۔ انہیں خود پروفائل میں رکھیں تاکہ کہیں اور رکھی گئی نقل ویسا ہی برتاؤ کرے۔
پوری زنجیر کو ایک کنٹینر میں محدود کریں
زنجیر میزبان پر چلانے کا مطلب اس کا ڈیفالٹ راستہ سنبھالنا اور resolver کو ایسی حالت میں چھوڑنا ہے جسے بعد میں کوئی سمجھا نہ سکے۔ نیم اسپیس یا کنٹینر اسے محدود کرتا ہے، چنانچہ میزبان اپنا راستہ رکھتا ہے جبکہ SOCKS قدم اور سرنگ ساتھ رہتے ہیں۔ اس کے اندر کوئی چیز سرنگ ڈیوائس، اس ڈیوائس کی ترتیب کے حقوق اور قابل رسائی پراکسی کے بغیر نہیں اٹھتی۔ Compose سروس یہ cap_add: NET_ADMIN اور بائنڈ ماونٹ شدہ /dev/net/tun سے حاصل کرتی ہے۔
cap_add:
- NET_ADMIN
devices:
- /dev/net/tun:/dev/net/tun
یہ جوڑا کنٹینر کو privileged چلانے سے زیادہ تنگ ہے اور ڈیوائس تک رسائی کا سارا ضروری حصہ ہے۔ Tor کلائنٹ یا الگ پراکسی کنٹینر سننے والا مہیا کر سکتا ہے۔ دونوں صورتوں میں اسے loopback پر باندھیں، اور پراکسی کو نیٹ ورک پر بے نقاب کرنے کے بجائے نیم اسپیس سے میزبان کے ذریعے اس تک پہنچیں۔
نام کی تحلیل وہ جگہ ہے جہاں تنہائی ناکام ہوتی ہے
وہ سرنگ جو پیکٹ لے جاتی ہے مگر میزبان کے resolver سے پوچھتی ہے اس نے کچھ بھی الگ نہیں کیا۔ دو چیزیں تنہائی کو حقیقی بناتی ہیں: نیم اسپیس کا اپنا resolver ہونا، اور اس کے استفسارات کا پراکسی یا سرنگ سے گزرنا، کبھی فزیکل انٹرفیس سے نہیں۔ ٹیسٹ کے لیے دو نام استعمال کریں: ایک جو صرف سرنگ کے پیچھے موجود ہو، اور ایک عوامی جو اسی راستے پر چلنا چاہیے۔
docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example
اگر دور والا نام تحلیل ہو اور عوامی نہ ہو، تو زنجیر منتخب ہے، خراب نہیں، اور فرق بتاتا ہے کہ ہر استفسار کون سا راستہ لیا۔ اگر دونوں میزبان پر تحلیل ہوں مگر کنٹینر کے اندر کوئی نہ ہو، تو کنٹینر اب بھی میزبان کا resolver مانگ رہا ہے۔ جو resolver فائل ملی اسے ریکارڈ کریں، کیونکہ وہی ترتیب ہے جسے بدلنا ہے۔
ہر قدم کو ترتیب سے ثابت کریں
فہرست مختصر ہے۔ SOCKS5 درخواست کو جواب ملتا ہے، سرنگ پراکسی کے ذریعے اپنے سننے والے تک پہنچتی ہے، اور نیم اسپیس سے نکلنے والے پیکٹ وہ پتہ لے جاتے ہیں جس کی دور سرا توقع رکھتا ہے۔ مزید ترتیب بچھانے کے بجائے ایک ایک کو الگ سے تصدیق کریں۔ جب کلائنٹ کہے کہ جڑا ہوا ہے اور کچھ نہیں ہلتا، تو وقفہ تقریباً ہمیشہ دوسری یا تیسری حقیقت میں ہوتا ہے۔
curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example
جو مجموعہ کام کر گیا اسے لکھ لیں: SOCKS ورژن، ٹرانسپورٹ، resolver اور نیم اسپیس کی ترتیبات۔ اس زنجیر کو دوبارہ یاد سے حل کرنا نوٹ سے زیادہ مہنگا ہے۔ وہ چار حقائق ٹکٹ میں رکھیں، چیٹ تھریڈ میں نہیں۔
وہ زنجیر جو جڑا ہوا بتاتی ہے اور کچھ نہیں گزارتی، عموماً اُس قدم پر ناکام ہوئی ہے جو آپ نے ابھی ثابت نہیں کیا۔ مزید تہہ لگانے سے پہلے اُس قدم کو آزمائیں۔