Tinyproxy میں Listen، Bind اور BindSame: کون سا پتہ جیتتا ہے
Listen وہ پتہ چنتا ہے جو کلائنٹس کو قبول کرتا ہے، Bind باہر جانے والے روابط کا ماخذ چنتا ہے۔ کوئی بھی راستہ نہیں بچھاتا، اس لیے راستے کی الگ جانچ کریں۔
پراکسی جواب دیتا ہے، درخواست مکمل ہوتی ہے، اور پھر بھی منزل اب بھی LAN پتہ درج کرتی ہے۔ پراکسی لاگ میں کچھ بھی غلط نہیں لگتا، اور جو سطر آپ نے بدلی وہی سطر ہے جسے بدلنے کو دستاویزات نے کہا تھا۔ ایسے ہوسٹ پر جس کے پاس LAN پتہ اور ٹنل پتہ دونوں ہیں، تین ہدایات طے کرتی ہیں کہ کون سا پتہ کہاں ظاہر ہوگا، اور ان میں سے صرف ایک باہر جانے والے پہلو سے متعلق ہے۔ غلط ترتیب میں پڑھیں تو بلاوجہ روٹنگ جدول میں پہنچ جائیں گے۔
علامت: منزل LAN پتہ دیکھتی ہے
کلائنٹ LAN پتے پر پراکسی سے جڑتا ہے، اور پراکسی منزل کی طرف اپنا رابطہ کھولتا ہے۔ وہ دوسرا رابطہ کرنل کے قواعد کے مطابق ماخذ پتہ چنتا ہے، اور بطور طے شدہ وہی ہوتا ہے جو راستہ تلاش چنتی ہے۔ اس لیے منزل ہوسٹ کا بنیادی پتہ درج کرتی ہے اگرچہ ہر بائٹ پراکسی سے گزرا۔ آگے بھیجنے کے لحاظ سے کچھ بگڑا نہیں، اور اسی لیے پراکسی لاگ کے پاس اس بارے میں کہنے کو کچھ نہیں۔
اس خرابی کی آئینے والی تصویر پہچاننا آسان ہے: باہر جانے والے ماخذ کو ٹنل پتے پر پن کریں اور LAN کلائنٹس سننے والے تک پہنچنا ہی بند کر دیں گے۔ وہ نسخہ خود اعلان کرتا ہے، جبکہ پہلا کام کرنے والی درخواست کے پیچھے چھپا رہتا ہے۔ دونوں ایک ہدایت کو ایسا سمجھنے سے آتے ہیں جیسے وہ دونوں سوالوں کا جواب دیتی ہو۔
تین ہدایات، تین مختلف پتے
Listen اس مقامی پتے کا نام لیتی ہے جو پراکسی کلائنٹس کو قبول کرتا ہے۔ Bind باہر کی طرف پراکسی جو روابط بناتی ہے ان کے لیے ماخذ پتہ دیتی ہے، اور BindSame اسے کہتی ہے کہ ابھی قبول کیے گئے رابطے کا مقامی پتہ دوبارہ استعمال کرے۔ یہ تین الگ سوال ہیں، اور ایک سطر صرف ایک کا جواب دیتی ہے۔ انہیں خلط ملط کرنا ہی وہ عام وجہ ہے کہ تبدیلی کچھ نہ کرتی ہوئی لگتی ہے۔
| What you observe | Check first |
|---|---|
| A client cannot connect at all | Listen: the local address the listener binds |
| The request works but the far side logs the LAN address | Bind: the outgoing source is not being applied |
| A configured Bind appears to have no effect | BindSame yes: the accepted local address overrides the Bind list |
| The lookup names the LAN interface | The route, not the proxy: the source cannot reach that destination |
نصب شدہ نسخے کے ساتھ آنے والی تشریح شدہ ترتیب پڑھیں، کیونکہ طے شدہ اقدار اور قبول شدہ نحو نسخوں کے درمیان بدلتی ہیں۔ منصوبے کی نمونہ ترتیب ہر ہدایت کو دوسروں کے ساتھ دستاویز کرتی ہے۔ اس فائل کا موازنہ ڈسک پر موجود فائل سے کریں، کسی دوسری تقسیم کے لیے لکھی گئی رہنما سے نہیں۔
سننے والے اور باہر جانے والے ماخذ کو الگ الگ مقرر کریں
ایسا ہوسٹ لیں جس کا LAN پتہ 192.168.50.10 اور ٹنل پتہ 10.90.0.3 ہے۔ اگر LAN کلائنٹس کو پراکسی تک پہنچنا ہے اور ان کی درخواستیں ٹنل سے باہر جانا ہیں، تو یہ دو خودمختار فیصلے ہیں اور دونوں لکھنے ہوں گے۔ نیچے کا حصہ بالکل یہی کہتا ہے، اس سے زیادہ کچھ نہیں۔
Listen 192.168.50.10
Bind 10.90.0.3
BindSame noیہ مکمل ترتیب نہیں، اس لیے منظور شدہ پورٹ، توثیق، کلائنٹ رسائی کے کنٹرول اور منزل کی پابندیاں برقرار رکھیں۔ دونوں پتے Tinyproxy کے نیٹ ورک نام کی جگہ کے اندر اسی ہوسٹ کے ہونے چاہئیں، کیونکہ جس Bind قدر کا عمل مالک نہیں ہو سکتا وہ شروع میں نہیں، جڑنے کے وقت ناکام ہوتی ہے۔ BindSame yes دوسری پالیسی بیان کرتی ہے، جہاں قبول شدہ رابطے کا مقامی پتہ ہی باہر جانے والا ماخذ بن جاتا ہے۔ موجودہ نسخوں میں اس شاخ کو Bind فہرست پر فوقیت ہے، اور اسی طرح ترتیب دیا گیا ماخذ بغیر کسی غلطی کے غائب ہو جاتا ہے۔
وہ راستہ جانچیں جس کی طرف ماخذ اشارہ کرتا ہے
ماخذ پتہ چننے سے راستہ نہیں بنتا، اس لیے کرنل سے پوچھیں کہ وہ اس ماخذ اور اس منزل کے ساتھ کیا کرے گا۔ وہ تلاش جو ٹنل انٹرفیس کا نام لیتی ہے کم سے کم ثبوت ہے، اور جو LAN انٹرفیس کا نام لیتی ہے اس کا مطلب ہے کہ ماخذ لکھے ہوئے مطابق کام نہیں کر سکتا۔ تلاش سیاق و سباق پر مبنی ہے: یہ اس نام کی جگہ کے لیے نافذ پالیسی قواعد اور جدول کا جائزہ لیتی ہے۔ یہ رابطہ نہیں ہے، اور اس بارے میں کچھ نہیں کہتی کہ نیچے کا NAT خدمت کو کیا پیش کرے گا۔
ip -4 route get 203.0.113.25 from 10.90.0.3مثال میں دستاویزی پتہ استعمال کریں اور اس خدمت کو رکھیں جسے جانچنے کی آپ کو اجازت ہے۔ جب پراکسی کنٹینر میں چل رہا ہو تو تلاش پراکسی کے نام کی جگہ کے اندر چلائیں، کیونکہ ہوسٹ کے قواعد وہ نہیں جو عمل دیکھتا ہے۔ اگر مطلوبہ ٹنل راستہ موجود نہ ہو تو پراکسی ہوسٹ پر منزل مخصوص قواعد شامل کرنے کے بجائے نیٹ ورک کے مالک سے اسے درست کرائیں۔ تلاش کامیاب ہونے کے لیے ہوسٹ کے راستے صاف نہ کریں اور سرور کی بھیجی ہوئی راہیں بند نہ کریں، اگرچہ کسی پرانی رہنما نے ایسا کیا ہو، کیونکہ ایسی تبدیلیاں ایک پراکسی راستہ درست کرنے کے لیے پورے ہوسٹ کے منظور شدہ VPN رویے کو ہلا دیتی ہیں۔
منزل پر ماخذ کی تصدیق کریں
ماخذ وہاں پڑھیں جہاں درخواست پہنچتی ہے، نہ کہ جہاں سے نکلتی ہے۔ منزل کا اطلاقی لاگ، یا اس کے سامنے کا کنارہ آلہ، وہ پتہ درج کرتا ہے جو اس نے واقعی دیکھا، جبکہ پراکسی صرف اپنا ارادہ بتا سکتی ہے۔ تبدیلی کے بعد مطلوبہ سننے والے کے ذریعے ایک نئی درخواست کریں، کیونکہ کیش میں موجود رابطہ نئی بندش کے بارے میں کچھ ثابت نہیں کرتا۔ پھر درج شدہ پتے کا موازنہ اپنے مقرر کردہ پتے سے کریں۔
ss -ltnp | grep tinyproxy
curl -x http://192.168.50.10:8888 https://example.com -o /dev/null -sScurl صرف ٹریفک پیدا کرنے والا ہے؛ جانچنے کے قابل پتہ وہی ہے جو دور کے سرے نے درج کیا، نہ کہ وہ ساتھی جس سے curl اتفاقاً جڑا۔ اگر دونوں نہ ملیں تو فیصلہ کریں کہ فرق ماخذ کے انتخاب سے آ رہا ہے یا آگے کی تبدیلی سے، کیونکہ وہ مختلف جگہوں پر درست ہوتے ہیں۔ پتے کی تبدیلیاں اور پراکسی کی دوبارہ شروعات اکٹھی منصوبہ بندی میں رکھیں، کیونکہ جس پتے کا ٹنل اب مالک نہیں اسے باندھنا دوبارہ جڑنے کے بعد خاموشی سے ناکام ہوتا ہے۔ DNS اور IPv6 کا رویہ بھی الگ سے متعین کریں، کیونکہ اوپر کا IPv4 حصہ دونوں میں سے کسی کے بارے میں کچھ ثابت نہیں کرتا۔