آپ کے ہاٹ اسپاٹ کا فائر وال لیز سے پہلے DHCP کو روکتا ہے

نیا فون آپ کے ہاٹ اسپاٹ سے جڑتا ہے، کوئی پتہ نہیں دکھاتا اور کبھی نہیں پاتا۔ رسائی کا مقام درست ہے، DHCP ڈیمن چل رہا ہے، اور آپ کا لکھا ہوا فائر وال قاعدہ پتہ منصوبے سے ہم آہنگ دکھتا ہے۔ لیکن اصل میں یہ مانگتا ہے کہ کلائنٹ کے پاس پہلے سے وہی پتہ ہو جو وہ مانگ رہا ہے۔ پہلے DHCP پیکٹ میں کوئی پتہ ہی نہیں ہوتا، اس لیے قاعدہ کبھی لاگو نہیں ہوتا۔

کسی کلائنٹ کے جڑنے کا مشاہدہ کریں

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

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

پہلے پیکٹ میں اصل میں کیا ہوتا ہے

RFC 2131 مقرر کرتا ہے کہ پتہ ملنے سے پہلے کلائنٹ کی DHCP نشریات صفر ماخذ پتہ استعمال کرتی ہیں۔ کلائنٹ سے سرور کی طرف پیغامات UDP پورٹ 67 پر، اور سرور سے کلائنٹ کی طرف پیغامات UDP پورٹ 68 پر جاتے ہیں۔ اس لیے دریافت 0.0.0.0 کو ماخذ بنا کر آتی ہے، اور آپ کے کلائنٹ سب نیٹ کے اندر ماخذ مانگنے والا قاعدہ اس سے سیدھا مطابقت نہیں رکھتا۔

یہ کلائنٹ کی طرف سے غلط ترتیب نہیں ہے۔ یہ پروٹوکول ہے، جیسے ڈیزائن کیا گیا تھا ویسے ہی کام کر رہا ہے، صرف اسی ایک ونڈو میں جہاں یہ ممکن ہے۔

اصل میں کون سا راستہ اسے سنبھالتا ہے

اگر رسائی کا مقام خود لیز دیتا ہے، تو یہ مقامی سروس کی گفتگو ہے، اور IP سے فلٹر شدہ مقامی راستے میں یہ ان پٹ اور آؤٹ پٹ پالیسی سے متعلق ہے۔ VPN کے ذریعے آگے بھیجا گیا کلائنٹ ٹرافک دوسرا فیصلہ ہے، اور اس ٹرافک کے لیے NAT پھر الگ ہے۔ ان تینوں کو ملانا ہی تنگ استثنا کو وسیع بنانے کا راستہ ہے۔

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

فورم سے نقل کیا گیا عام ان پٹ اور آؤٹ پٹ کا نسخہ اس بات کا ثبوت نہیں کہ آپ کا نفاذ ان زنجیروں سے اسی طرح گزرتا ہے۔

جواب ہمیشہ نشریات نہیں ہوتا

صرف نشریاتی جوابات کی اجازت دینے والا استثنا بھی غلط ہے۔ DHCP جواب کی منزل کلائنٹ کی حالت اور پیغام کے فیلڈز پر منحصر ہے، اور پروٹوکول نشریات اور واحد پتہ دونوں صورتیں مقرر کرتا ہے۔ اگر آپ کا سرور اس پتے پر واحد پتہ کے طور پر جواب دیتا ہے جو وہ ابھی دینے والا ہے، تو صرف نشریات والا قاعدہ وہ مرحلہ روک دیتا ہے جو کام مکمل کرتا ہے۔ قاعدہ اسی تبادلے کے مطابق لکھیں جو ترتیب شدہ سرور اصل میں کرتا ہے۔

بعد کی لیز تجدیدات مختلف حالت میں وہی تبادلہ دہراتی ہیں، اس لیے صرف پہلے اتصال کے لیے نہیں، ان کے لیے بھی جگہ چھوڑیں۔

تنگ طور پر درست کریں، پھر باقی جانچیں

موجودہ پالیسی رکھیں، غائب DHCP اجازت تلاش کریں اور اسے کلائنٹ کی طرف والے انٹرفیس، پروٹوکول اور دو پورٹس تک محدود کریں۔ ثابت کریں کہ درخواست سروس تک پہنچتی ہے، پھر ثابت کریں کہ سروس جواب دیتی ہے۔ یہ دو مختلف مشاہدے ہیں، اور بہترین فلٹرنگ کے پیچھے بھی سروس یا پتہ پول کی ترتیب غلط ہو سکتی ہے۔

ٹیبل فلش کرنا DHCP ترتیب کا مرحلہ نہیں ہے۔ iptables میں flush منتخب زنجیر یا ٹیبل سے قواعد حذف کرتا ہے، اور NAT ٹیبل فلش کرنے سے ترجمہ قاعدہ نہیں بنتا۔ وسیع ACCEPT پالیسیاں رکھنا لیز سے غیر متعلق تحفظ ہٹا دیتی ہیں، اسی لیے دونوں میں سے کوئی بھی دوبارہ قابل استعمال ہاٹ اسپاٹ درستی میں شامل نہیں۔

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