ایک ہی ذیلی نیٹ کی ویب سائٹیں گیٹ وے کے شفاف پراکسی سے گزر سکتی ہیں

انٹرنیٹ براؤزنگ گیٹ وے پراکسی کے لاگ میں ظاہر ہوتی ہے۔ دفتر کے LAN پر موجود ویب سائٹ ظاہر نہیں ہوتی۔ URL فلٹر تبدیل کرنے سے پہلے طے کریں کہ LAN درخواست گیٹ وے تک پہنچی تھی یا نہیں۔

براہ راست جڑے IPv4 منزل کے لیے کلائنٹ منزل کا لنک لیئر پتہ حل کر کے مقامی حصے میں اسے بھیج سکتا ہے۔ اس کا طے شدہ گیٹ وے اس راستے پر خود بخود نہیں ہوتا۔ گیٹ وے پر شفاف روکنے کا قاعدہ ان پیکٹوں کو ری ڈائریکٹ نہیں کر سکتا جو گیٹ وے کو کبھی نہیں ملتے۔

مثال کے طور پر، ایک ہی براہ راست جڑے ذیلی نیٹ کے دو ہوسٹ سوئچ کے ذریعے ٹریفک کا تبادلہ کر سکتے ہیں جبکہ پراکسی مشین کسی دوسرے سوئچ پورٹ سے جڑی ہوتی ہے۔ صرف اس LAN پر ہونا پراکسی کو فارورڈنگ نقطہ نہیں بناتا۔

مطلوبہ راستہ منتخب کریں

واضح پراکسی ترتیب شریک ایپلیکیشن کی درخواست پراکسی کو بھیج سکتی ہے چاہے ہدف ویب سائٹ مقامی ہو۔ بائی پاس قواعد اور PAC فیصلے بھی دیکھیں: وہ نجی ناموں یا پتوں کے لیے جان بوجھ کر DIRECT منتخب کر سکتے ہیں۔

اگر روکنا ضروری ہو تو نیٹ ورک کو روکنے کا نقطہ واقعی راستے میں رکھنا ہوگا؛ Linux گیٹ وے پر مقامی اور فارورڈ شدہ پیکٹ راستے الگ کریں۔ روٹ شدہ ذیلی نیٹ علیحدگی یا جان بوجھ کر ان لائن رکھا گیا برج موزوں ڈیزائنوں میں یہ کر سکتے ہیں، لیکن ہر ایک فارورڈنگ اور ناکامی کا رویہ بدلتا ہے۔ LAN پر کسی اور جگہ کا برج خود بخود ان لائن نہیں ہوتا۔

ایپلیکیشن پروٹوکول کی ضرورت الگ رکھیں۔ ٹریفک کے آلے سے گزرنے کے بعد بھی سننے والے کو روکنے کا موڈ سپورٹ کرنا چاہیے۔ پیکٹوں کو ہلانا HTTPS کو ڈکرپٹ کرنے کی اجازت نہیں اور نہ یہ ضمانت کہ عام SOCKS پورٹ انہیں قبول کر سکے گا۔

کلائنٹ کا منتخب کردہ راستہ، مقامی حصہ اور اصل فارورڈنگ ڈیوائس ریکارڈ کریں۔ پراکسی لاگ کا نہ ہونا لاگنگ کی ناکامی نہیں بلکہ ٹوپولوجی کی درست وضاحت ہو سکتا ہے۔