لینکس کا کون سا پیکٹ راستہ پراکسی کے استعمال کو نافذ کرے؟
نیٹ ورک پراکسی کو نافذ کرنے والے کنٹرول اسی پیکٹ راستے پر رکھیں جس پر انہیں حکمرانی کرنی ہے، بجائے اس کے کہ صرف گیٹ وے سے رابطوں کو فلٹر کیا جائے۔
لینکس گیٹ وے پراکسی عمل چلا سکتا ہے اور ساتھ ہی ٹریفک کو اس کے پہلو سے گزر بھی سکتا ہے۔ یہ ایک ہی پیکٹ راستہ نہیں ہیں۔
| رابطہ | متعلقہ مقامی کردار |
|---|---|
| کلائنٹ گیٹ وے پر پراکسی تک پہنچتا ہے | مقامی ہوسٹ کو بھیجی گئی ٹریفک |
| کلائنٹ گیٹ وے کے ذریعے دوسرے ہوسٹ تک پہنچتا ہے | آگے بھیجی گئی ٹریفک |
| پراکسی ویب سائٹ کا رابطہ کھولتی ہے | مقامی عمل سے پیدا شدہ ٹریفک |
Netfilter ان پٹ، فارورڈ اور آؤٹ پٹ راستوں میں فرق کرتا ہے۔ گیٹ وے کے اپنے پراکسی سننے والے تک رسائی کو کنٹرول کرنے والا قاعدہ اس مشین سے گزرنے والے ہر روٹ شدہ رابطے کو خودکار طور پر محدود نہیں کرتا۔
طے کریں کہ کیا نافذ کرنا ہے
اگر کلائنٹس کو منظور شدہ پراکسی استعمال کرنی ہے تو پالیسی کو مطلوبہ سننے والے کی اجازت کے ساتھ ساتھ ان کے متبادل آؤٹ باؤنڈ راستوں کو بھی حل کرنا ہوگا۔ صرف اس لیے کہ کوئی دور دراز سروس مانوس پراکسی پورٹ استعمال کرتی ہے، اس سے رابطوں کی اجازت دینا صرف اپنے پراکسی اینڈ پوائنٹ کی اجازت دینے کے برابر نہیں۔
پراکسی کی اپنی آگے کی رسائی الگ رکھیں۔ Squid کے لیے، آؤٹ باؤنڈ اجازت لاگو کرنے سے پہلے مقامی ساکٹ کی ملکیت کو LAN صارف کی شناخت سے الگ کریں۔ پراکسی سے تمام مفید آؤٹ باؤنڈ رابطے مسترد کرنا مطلوبہ راستہ ناقابل استعمال بنا دے گا۔ انتظامی ٹریفک، نام کی تحلیل اور معاون غیر ویب کارروائیوں کو بھی تعیناتی کی پالیسی میں سوچے سمجھے علاج کی ضرورت ہے۔
پروٹوکول کی حد اہم ہے۔ TCP قاعدہ بذات خود UDP ٹریفک کی وضاحت نہیں کرتا، بشمول QUIC۔ ٹریفک کو روکنا ایک اور ڈیزائن ہے؛ واضح HTTPS پراکسی ویب سائٹ سیشن کو ڈکرپٹ کیے بغیر CONNECT فراہم کر سکتی ہے۔
قواعد کے مجموعے میں ترمیم سے پہلے مطلوبہ رابطوں کا نقشہ بنائیں۔ براؤزر کی ترجیح شریک کلائنٹس کے لیے راستہ منتخب کرتی ہے۔ نیٹ ورک نافذ کرنا فیصلہ کرتا ہے کہ کون سے دیگر راستے کامیاب ہو سکتے ہیں۔ دونوں میں سے کوئی بھی صرف پراکسی میں کامیاب لاگ ان سے اخذ نہیں کیا جانا چاہیے۔