جدار حماية نقطة الاتصال يمنع DHCP قبل الإيجار
قاعدة نطاق العميل لا تطابق أول طلب DHCP أبدًا، لأن ذلك الطلب يأتي من 0.0.0.0. اسمح بالمسار المحلي بدلًا من ذلك.
ينضم هاتف جديد إلى نقطة الاتصال الخاصة بك، ولا يظهر له أي عنوان، ولا يحصل على عنوان أبدًا. نقطة الوصول سليمة، وخادم 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 كمهام منفصلة. الإيجار يثبت العنونة المحلية ولا شيء بعدها.