فایروال هات‌اسپات شما 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 را به‌عنوان وظایف جداگانه بررسی کنید. اجاره فقط نشانی‌دهی محلی را برقرار می‌کند و نه چیزی بیشتر.