Squid میں myportname اور src کو الگ ACL کے ساتھ جوڑنا
ایک ہی تعریف میں دو قسم کے ACL رکھے بغیر نامزد Squid listener کو مجاز کلائنٹ نیٹ ورک کے ساتھ جوڑیں۔
ترتیب پہلی نظر میں معقول لگتی ہے:
acl team_a myportname 3128 src 198.51.100.0/24
لیکن ACL تعریف کا صرف ایک قسم ہوتا ہے۔ یہاں myportname قسم ہے؛ src لفظ شامل کرنے سے دوسرا امتحان شروع نہیں ہوتا۔ باقی الفاظ پہلی قسم کی قدروں کی فہرست میں آتے ہیں۔ وہ سطر «یہ listener اور یہ کلائنٹ نیٹ ورک» نہیں کہتی۔
ہر شرط کو نام دیں
سننے والے socket کے لیے نام اور ماخذ کے لیے الگ ACL استعمال کریں۔ یہ اقتباس دستاویزی پتے استعمال کرتا ہے، جنہیں تعیناتی کے لیے موزوں پتوں سے بدلنا ہوگا:
http_port 192.0.2.10:3128 name=team_a_port
acl team_a_port myportname team_a_port
acl team_a_clients src 198.51.100.0/24
http_access allow team_a_port team_a_clients
http_access deny all
اجازت کا قاعدہ غیر محفوظ منزل پورٹس، محدود CONNECT اہداف اور انتظامی رسائی کے لیے موجود تحفظات کے بعد رکھیں۔ اقتباس کلائنٹ/listener شرط دکھاتا ہے؛ یہ اُن تحفظات کی جگہ نہیں لیتا۔
ایک http_access سطر کی شرطیں AND سے جڑتی ہیں۔ دو الگ اجازت کی سطریں ہر شرط کو خودمختار طور پر گزار دیں گی، جس سے پالیسی کافی بدل جائے گی۔ ایک ACL کے اندر کئی قدریں عام طور پر اُس ایک امتحان کے لیے متبادل دیتی ہیں۔
اخراج الگ منتخب کریں
مطابق listener کو tcp_outgoing_address کے ذریعے بھی مقامی ماخذ پتہ منتخب کرنے کے لیے استعمال کیا جا سکتا ہے۔ یہ روٹنگ کا انتخاب ہے، پراکسی استعمال کرنے کی اجازت نہیں۔ اخراجی پتے کا قاعدہ مسترد شدہ درخواست کو http_access سے نہیں گزار سکتا۔
اگر کئی پتوں والی ترتیب اپ گریڈ کے بعد کام کرنا چھوڑ دے تو شواہد الگ کریں: تجزیے کی خرابی ترتیب کے نحو کی طرف اشارہ کرتی ہے؛ رسائی سے انکار قواعد کے میلان کی طرف؛ غلط اخراج کے ساتھ مجاز درخواست اخراج کے انتخاب یا بعد کے NAT کی طرف۔ تینوں کو ایک ساتھ بدلنا چھوٹی ACL غلطی تلاش کرنا بہت مشکل بنا دیتا ہے۔