صرف WireGuard کے ذریعے چلنے والی HTTPS سروس کے لیے loopback پر Dante SOCKS

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

مثال فرض کرتی ہے کہ Dante 1.4.x کسی قابل اعتماد Linux ورک اسٹیشن پر مخصوص، زیر انتظام انسٹانس کے طور پر نصب ہے، اور پیکیج کا فراہم کردہ سروس اکاؤنٹ اور لاگ کنفیگریشن اپنی جگہ پر چھوڑے گئے ہیں۔ ورک اسٹیشن 10.77.0.2 کو اپنے WireGuard انٹرفیس پر رکھتا ہے، اس ٹنل کے ذریعے 10.60.0.20:443 تک پہنچتا ہے، اور سروس کا درست نام app.corp.example ہے۔

مرحلہ 1: سننے والے کو صرف loopback سے باندھیں

نیٹ ورک، طریقہ اور قواعد کے حصے انسٹانس کی فعال کنفیگریشن میں رکھیں اور مثال کے پتے بدلیں۔ سرور کی تمام ترتیبات قواعد کے بلاکس سے پہلے آتی ہیں:

internal: 127.0.0.1 port = 1080
external: 10.77.0.2
external.protocol: ipv4
clientmethod: none
socksmethod: none

client pass {
    from: 127.0.0.1/32 to: 127.0.0.1/32
}

socks pass {
    from: 127.0.0.1/32 to: 10.60.0.20/32 port = 443
    command: connect
    protocol: tcp
}

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

اس مرحلے کی واپسی انسٹانس روکنا ہے؛ ترتیب کی فائل ڈسک پر رہ سکتی ہے جب تک آپ اسے واپس لاتے ہیں۔

مرحلہ 2: ایک نہیں، دو قواعد لکھیں

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

غور کریں یہ کنفیگریشن جان بوجھ کر کیا نہیں کرتی: یہ کوئی SOCKS پاس ورڈ نہیں مانگتی۔ یہ قابل اعتماد مقامی میزبان کے لیے موزوں ہے، اور یہ صارف کی تصدیق نہیں ہے۔ اس مشین پر کوئی بھی دوسرا عمل loopback استعمال کر سکتا ہے۔ دور دراز ایپلیکیشن کی اپنی تصدیق اپنی جگہ رکھیں، اور اس بغیر تصدیق والی شکل کو غیر قابل اعتماد مقامی صارفین یا LAN کی طرف دیکھنے والے سننے والے کے لیے دوبارہ استعمال نہ کریں۔

مرحلہ 3: درست ماخذ سے راستے کی تصدیق کریں

external باہر جانے والا ماخذ پتہ منتخب کرتا ہے؛ یہ WireGuard راستہ نصب نہیں کرتا۔ مثال کے ماخذ اور منزل کے لیے صرف پڑھنے والی تلاش:

ip -4 route get 10.60.0.20 from 10.77.0.2

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

تلاش کامیاب ہونے کے لیے طے شدہ راستہ شامل کرنے کے لالچ کا مقابلہ کریں۔ پروکسی پورٹ صرف اسی ورک اسٹیشن پر موجود ہے؛ اسے بنانے کے لیے میزبان کا طے شدہ راستہ بدلنا پورا ڈیزائن الٹ دیتا ہے۔

مرحلہ 4: مطلوبہ شناخت کے ساتھ جانچیں

مالک کے نصب شدہ کنفیگریشن کی توثیق کرنے اور سروس مینیجر کے ذریعے انسٹانس شروع کرنے کے بعد، ایک مثال درخواست یہ ہے:

curl --proxy socks5h://127.0.0.1:1080 --noproxy '' https://app.corp.example/

کے ساتھ socks5h, Dante منزل کا حل کرتا ہے، مگر Dante اسی ورک اسٹیشن پر چلتا ہے، اس لیے ترتیب خود سے DNS ٹنل کے دور دراز سرے تک نہیں بھیجتی۔ Dante جو منظور شدہ حل کنندہ استعمال کرتا ہے اسے اس نام کے لیے اجازت شدہ پتہ واپس دینا چاہیے۔ خالی no-proxy فہرست کسی وراثتی استثنا کو خاموشی سے SOCKS سے بچنے سے روکتی ہے۔

جانچ میں HTTPS میزبان نام اور سرٹیفکیٹ کی توثیق برقرار رکھیں، پھر اصل سننے والے کا معائنہ کریں اور معاہدے کے دونوں نصف تصدیق کریں: اجازت شدہ درخواست کامیاب ہوتی ہے اور خارج شدہ منزل ناکام ہوتی ہے۔ یہ بھی تصدیق کریں کہ غیر معاون فارورڈنگ کمانڈز مسترد رہتے ہیں، کیونکہ یہ ٹکڑا TCP پر SOCKS CONNECT کمانڈ کی اجازت دیتا ہے اور عام UDP یا پورے ڈیوائس کی ٹنل جیسی کسی چیز کی نہیں۔

مرحلہ 5: فیصلہ کریں کہ ٹنل گرنے پر کیا ہوگا

اسے پیداوار کہنے سے پہلے ٹنل کے نقصان اور انسٹانس کی دوبارہ شروعات کی جانچ کریں۔ جو نگران WireGuard کے بعد Dante شروع کرتا ہے وہ fail-closed روٹنگ نہیں بناتا، اور fail-closed DNS بھی نہیں بناتا؛ دونوں نیٹ ورک کے مالک کے ذریعے نافذ کرنے ہوں گے۔ دیکھیں ٹنل بند ہونے پر ایپلیکیشن کیا کرتی ہے: صاف غلطی اچھا نتیجہ ہے، عوامی حل کنندہ پر خاموشی سے گرنا نہیں۔

اگر بندھا ہوا ٹنل پتہ بدلے تو اپ ڈیٹس کو ہم آہنگ کریں، کیونکہ external اسی پر پن ہے۔ جب اس ترتیب کی ضرورت نہ رہے، تو یہ انسٹانس اور ایپلیکیشن کی پروکسی ترتیب کو ساتھ ریٹائر کریں، اور WireGuard راستہ اس کے مالک کے حوالے کر دیں۔