socat SOCKS پل: سائٹ کا TLS ہوسٹ نام محفوظ رکھیں

ایپ کے پاس SOCKS اختیار نہیں ہے، لیکن یہ منتخب کردہ TCP پتے سے جڑ سکتی ہے۔ مقررہ ہدف والا اڈاپٹر ایک منزل کے لیے SOCKS گفتگو فراہم کر سکتا ہے۔ اسے کوئی اور عام فارورڈ پراکسی بننے کی ضرورت نہیں۔

SOCKS4A فراہم کرنے والے socat بلڈز کے لیے ایک مثالی ترتیب یہ ہے:

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS اینڈ پوائنٹ مقامی پورٹ 1080 ہے۔ اڈاپٹر مقامی پورٹ 9443 پر سنتا ہے اور اس اینڈ پوائنٹ سے service.example.net:443 مانگتا ہے۔ یہ مثالی قدریں ہیں، مکمل سروس تعیناتی نہیں۔

اڈاپٹر کا ایک مقررہ ہدف ہے

ہر قبول شدہ TCP کنکشن وہی سروس مانگتا ہے۔ 9443 سے جڑنے والی ایپ اپنے معمول کے پروٹوکول بائٹس دیتی ہے؛ socat SOCKS4A گفت و شنید فراہم کرتا ہے۔ 9443 پر نئی HTTP CONNECT درخواست بھیجنا کوئی دوسری منزل منتخب نہیں کرے گا—یہ ان بائٹس کو مقررہ سروس کی طرف بھیج دے گا۔

SOCKS4A دور دراز حل کے لیے SOCKS اینڈ پوائنٹ کو ہوسٹ نام دیتا ہے۔ یہ کلائنٹ کے منتخب کردہ پتے والی SOCKS4 شکل سے مختلف ہے۔ منتخب کردہ اپ اسٹریم—SOCKS4 پراکسی فہرست سے عوامی امیدوار سمیت—کو SOCKS4A ہوسٹ نام ہینڈلنگ اور مطلوبہ تصدیق کی حمایت کرنی چاہیے؛ یہ مثال SOCKS5 پاس ورڈ لاگ ان کی ترکیب نہیں ہے۔

مقامی طور پر جڑیں، اصل سروس پہچانیں

HTTPS URL کو https://127.0.0.1:9443/ میں بدلنے سے وہ ہوسٹ نام بدل جاتا ہے جو کلائنٹ TLS اور HTTP کے لیے استعمال کر سکتا ہے۔ service.example.net کے لیے سرٹیفکیٹ loopback کے لیے درست سرٹیفکیٹ نہیں بنے گا۔

جہاں کلائنٹ الگ کنکشن روٹنگ کی حمایت کرتا ہے، وہاں اصل URL کی شناخت رکھیں۔ Curl وہ فرق دکھا سکتا ہے:

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

ساکٹ مقامی اڈاپٹر کی طرف جاتا ہے جبکہ TLS تصدیق اور HTTP منزل service.example.net رہتے ہیں۔ دوسری ایپس کو اپنا مساوی معاون کنٹرول چاہیے؛ ہر کلائنٹ یہ نہیں دیتا۔

loopback بائنڈنگ نیٹ ورک کی نمائش محدود کرتی ہے، لیکن دیگر اہل مقامی عمل اب بھی اس تک پہنچ سکتے ہیں۔ سروس کی مدت اور صارفین مناسب رکھیں۔ loopback URL کی وجہ سے ہونے والی شناخت کی خرابی کو دبانے کے بجائے TLS تصدیق رکھیں۔