مجازی pfSense TAP پل: تین جگہیں جہاں فریم مر سکتا ہے

آپ LAN انٹرفیس پر ایک قاعدہ بند کرتے ہیں، فریم پھر بھی غائب ہو جاتا ہے، اور نتیجہ یہ نکلتا ہے کہ pfSense اپنے ہی فائر وال کو نظرانداز کر رہا ہے۔ عام طور پر جو ہوا ہے وہ یہ ہے کہ کسی دوسرے مالک نے فیصلہ کیا: پل خود، رکن انٹرفیس، یا مہمان سے باہر مجازی سوئچ۔ ہر ایک کا اپنا کنٹرول اور اپنا لاگ ہے۔

نیچے دی گئی تین حدیں کسی ترتیب کو بدلنے سے پہلے الگ کرنے کے قابل ہیں، کیونکہ ایک کو بند کرنا دوسرے کی تلافی نہیں کر سکتا۔

ایک فریم، تین پالیسی مالکان

TAP کلائنٹ کا فریم ٹنل ڈیوائس سے داخل ہوتا ہے، pfSense پل عبور کرتا ہے، LAN رکن سے باہر نکلتا ہے، اور پھر کسی چیز تک پہنچنے سے پہلے مجازی سوئچ سے گزرتا ہے۔ مہمان کے اندر فلٹرنگ پل پر یا رکن انٹرفیس پر ہو سکتی ہے، اور کون سا فعال ہے یہ مستقل خصوصیت نہیں بلکہ کنفیگریشن کا انتخاب ہے۔ مہمان سے باہر ہائپر وائزر فیصلہ کرتا ہے کہ آیا وہ مجازی اڈاپٹر ایسے ماخذ MAC کے ساتھ فریم بھیج سکتا ہے جو اس کا نہیں ہے۔ ان میں سے کسی بھی مقام پر ڈراپ کلائنٹ کی طرف سے یکساں نظر آتا ہے۔

تحقیق سے پہلے مطلوبہ راستہ لکھیں: ٹنل رکن، پل، LAN رکن، مجازی سوئچ، منزل۔ پھر پوچھیں کہ اس راستے پر کون سا مالک فریم دیکھتا۔

کون سا pfSense کنٹرول فلٹر کر رہا ہے

pfSense اس کے لیے دو sysctl دستاویز کرتا ہے، ایک پل کے ارکان پر فلٹرنگ کے لیے اور ایک خود پل پر فلٹرنگ کے لیے، اور ان میں سے کم از کم ایک فعال رہنا چاہیے۔ پل کی سطح پر فلٹرنگ پل کے ارکان سے آنے والی ٹریفک پر لاگو ہوتی ہے، اس لیے یہ سمت کے لحاظ سے اندر آنے والی ہے، ہم آہنگ نہیں۔ قواعد اس انٹرفیس پر پڑھیں جو حقیقتاً فلٹر کر رہا ہے، کیونکہ فلٹرنگ کردار کے بغیر رکن پر رکھا گیا قاعدہ کچھ نہیں کرتا۔ پل فلٹرنگ کی دستاویز ملکیت واضح کرتی ہے۔

IP پتہ نہ ہونے والے رکن انٹرفیس کا اپنا پتہ یا سب نیٹ میکرو نہیں ہوتا، اس لیے اس میکرو کے خلاف لکھا گیا قاعدہ آپ کے مطلوبہ LAN کے علاوہ کچھ اور بیان کر سکتا ہے۔ سہولت والے میکرو کی بجائے جان بوجھ کر مختص کی گئی نیٹ ورک اشیاء استعمال کریں۔

ٹکڑا فریم نہیں ہے

ایتھرنیٹ فریم IP پیکٹ اٹھاتے ہیں، اور ایک IP پیکٹ بڑے ڈیٹاگرام کا ٹکڑا ہو سکتا ہے، اس لیے یہ دونوں الفاظ ایک دوسرے کی جگہ نہیں لے سکتے۔ ٹنل کے اندر ایک اندرونی پیکٹ اور اس کے باہر ایک بیرونی نقل و حمل پیکٹ بھی ہوتا ہے، اور ناکامی کسی ایک کی ہو سکتی ہے۔ چھوٹا ping اس اسٹیک سے گزرنے والا ایک راستہ آزماتا ہے اور بڑی منتقلی کے بارے میں کچھ ثابت نہیں کرتا۔ دو قریبی حدوں پر ناکام تبادلے کا موازنہ کریں اور کسی قاعدے کو مورد الزام ٹھہرانے سے پہلے ڈراپ کی وجہ پڑھیں۔

اگر ٹکڑے غائب ہوں تو جواب محدود اصلاح یا پیکٹ کے حجم کی تحقیق ہے، فلٹرنگ مکمل طور پر بند کرنے کا فیصلہ نہیں۔

ہائپر وائزر کا اپنا داخلہ فیصلہ ہے

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

رابطہ بحال کرنا آزمائش کا نصف ہے؛ باقی نصف یہ تصدیق کرنا ہے کہ جو بہاؤ مسدود رہنا چاہیے وہ اب بھی مسدود ہے۔

درج کریں کہ کس مالک نے فلٹر کیا، کون سا کنٹرول بدلا اور کون سے دو بہاؤ آپ نے تصدیق کیے۔ وہ ریکارڈ اگلے واقعے کو اسی گمان سے شروع ہونے سے روکتا ہے کہ pfSense خود کو نظرانداز کر رہا ہے۔