پالیسی روٹنگ بمقابلہ SOCKS: کون سی پرت واقعی ٹریفک کو پراکسی کرتی ہے

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

روٹنگ، DNAT اور SOCKS مختلف چیزیں بدلتے ہیں

پالیسی روٹ پرت 3 کے فیصلے کو دوبارہ لکھتی ہے۔ ایک کلائنٹ کی ٹریفک کو منتخب اگلے ہاپ پر بھیجنے کے لیے دو سطریں کافی ہیں:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

اس کے بعد کرنل پیکٹ کو 10.50.0.2 کے حوالے کرتا ہے، اور اصل منزل ابھی بھی IP ہیڈر میں ہے۔ اگر 10.50.0.2 راؤٹر ہے تو پیکٹ آگے بھیجتا ہے۔ اگر یہ 1080 پر SOCKS ڈیمن والا ہوسٹ ہے تو پیکٹ کسی ایسی چیز کی طرف نہیں بھیجا گیا جو اسے قبول کر سکے، اور پورٹ 1080 پر DNAT بھی مدد نہیں کرتا، کیونکہ تبدیل شدہ پیکٹ اب بھی SOCKS سلام کے بجائے اصل ایپلیکیشن پے لوڈ اٹھائے ہوئے ہے۔

SOCKS5 ورژن بائٹ، طریقوں کی فہرست، تصدیق کی ادلا بدلی اور منزل کا نام لینے والی درخواست سے شروع ہوتا ہے۔ یہ ایپلیکیشن ڈیٹا ہے۔ کوئی روٹنگ اندراج یا netfilter ہدف اسے پیدا نہیں کرتا، اور ایک سطر میں موازنہ یہ ہے: روٹنگ راستہ چنتی ہے، SOCKS سرور سے دوسرا کنکشن بنانے کو کہتا ہے۔

پہلا معاملہ: ایپلیکیشن خود SOCKS بول سکتی ہے

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

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

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

دوسرا معاملہ: وہ اڈاپٹر جو IP بہاؤ کو پراکسی سیشن میں بدلتا ہے

ان پروگراموں کے لیے جو SOCKS نہیں بول سکتے، تبدیلی ایسی چیز میں ہونی چاہیے جو IP ٹریفک ختم کرے اور ان کی جانب سے پراکسی سیشن کھولے۔ اس جزو کے پاس ٹنل انٹرفیس ہے، پالیسی روٹنگ کے منتخب کردہ بہاؤ قبول کرتا ہے، ہر ایک کے لیے SOCKS ہینڈ شیک کرتا ہے اور جوابات دوبارہ بناتا ہے۔ راستہ ٹریفک کو اس کی طرف بھیجتا ہے؛ سیشن بنانے والا اڈاپٹر ہے۔

پورا سب نیٹ اس کے سپرد کرنے سے پہلے اس کی دستاویزات پڑھیں۔ بہت سے اڈاپٹر TCP اچھی طرح لے جاتے ہیں اور UDP کو صرف SOCKS5 UDP انجمن کے ذریعے سنبھالتے ہیں، اور ان میں سے کوئی بھی ICMP کو پراکسی ٹریفک میں نہیں بدلتا، اس لیے کامیاب ping پراکسی راستے کے بارے میں کچھ نہیں کہتا۔ DNS دوسرا جال ہے: اگر اڈاپٹر نام مقامی طور پر حل کرے تو صرف-اندرونی ریکارڈ غلط جواب میں، یا بالکل کچھ نہیں میں حل ہوتے ہیں۔

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

تیسرا معاملہ: ہوسٹ درحقیقت روٹ شدہ گیٹ وے ہے

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

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

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

اصلی SOCKS کلائنٹ کا پہلا پے لوڈ بائٹ 0x05 ہے، سلام میں ورژن۔ اگر کیپچر اس کے بجائے اصل ایپلیکیشن ڈیٹا دکھائے تو کوئی SOCKS ڈیمن جواب نہیں دے گا، کیونکہ مذاکرات کبھی شروع ہی نہیں ہوئے۔ اگر 1080 پر کچھ نہیں سن رہا تو ہوسٹ گیٹ وے ہے، اور سوال یہ بن جاتا ہے کہ آیا یہ آگے بھیجتا ہے اور واپسی کا راستہ ہے یا نہیں۔

چار سوالوں سے پرت چنیں

کیا پروگرام میں پراکسی ترتیب ہے؟ اسے استعمال کریں اور وہیں رک جائیں۔ کیا ٹریفک میں ایسا UDP یا ICMP ہے جو بچنا چاہیے؟ ICMP صرف روٹ شدہ یا NAT گیٹ وے اٹھاتا ہے، اور UDP کو ایسی SOCKS5 انجمن چاہیے جسے دونوں سرے سپورٹ کریں۔ کیا مشین کے ہر عمل کو، بشمول وہ جنہیں آپ ترتیب نہیں دے سکتے، ڈھانپنا ہے؟ تو آپ کو ایسا اڈاپٹر چاہیے جو انٹرفیس کا مالک ہو اور بہاؤ ختم کرے۔ کیا آپ اس کی روٹنگ، DNS اور لوپ روک استثنائیں بھی سنبھال سکتے ہیں؟ اگر نہیں، تو سادہ گیٹ وے چلانا کم خرچ ہوگا۔

ایک فرق سیدھا رکھنے کے قابل ہے۔ VPN کلائنٹ کا اپنا socks-proxy اختیار بیان کرتا ہے کہ بیرونی ٹنل کنکشن اپنے سرور تک کیسے پہنچتا ہے، اور اندرونی کلائنٹ بہاؤ کی تبدیلی کے بارے میں کچھ نہیں کہتا۔ دونوں کو ایک ہی ٹکٹ میں مسلسل خلط ملط کیا جاتا ہے۔ راستے کو چھونے سے پہلے طے کریں کہ آپ کو کون سا رشتہ درکار ہے۔