مهاجرت فایروال سازمانی با کمترین قطعی؛ برنامه مرحله‌ای اجرا

مهاجرت فایروال سازمانی از آن کارهایی است که در ظاهر ساده به نظر می‌رسد: config قدیمی را می‌خوانیم، ruleها را می‌نویسیم، کابل را جابه‌جا می‌کنیم و دستگاه جدید را روشن می‌کنیم. اما در شبکه واقعی، همین نگاه ساده می‌تواند باعث قطعی سرویس، از دست رفتن VPN، اشتباه در NAT، یا باز شدن دسترسی‌های ناخواسته شود. اجرای کم‌ریسک به برنامه مرحله‌ای نیاز دارد.

مرحله اول: discovery قبل از نوشتن rule

قبل از نوشتن policy جدید، باید بدانیم فایروال قبلی واقعاً چه کاری انجام می‌دهد. ruleها همیشه حقیقت کامل را نمی‌گویند. بعضی ruleها سال‌ها hit نداشته‌اند، بعضی سرویس‌ها از NAT غیرمستند استفاده می‌کنند، بعضی مسیرها asymmetric هستند و بعضی tunnelها فقط در زمان‌های خاص فعال می‌شوند. discovery باید با config، لاگ، hit count، route table، NAT و مصاحبه با مالک سرویس‌ها انجام شود.

• ruleهای پرمصرف و ruleهای بدون hit جدا شوند.
• NATهای ورودی و خروجی با مالک سرویس تطبیق داده شوند.
• VPNها، routeها و dependencyهای شعبه‌ها بررسی شوند.
• سرویس‌های حساس برای تست قبل و بعد از cutover فهرست شوند.

مرحله دوم: پاک‌سازی قبل از migration

اگر همه چیز را همان‌طور که هست منتقل کنیم، فقط فایروال جدیدی با بدهی قدیمی ساخته‌ایم. بهتر است قبل از cutover، ruleهای واضحاً بی‌استفاده، objectهای تکراری، توضیح‌های نامفهوم و دسترسی‌های موقت بررسی شوند. حذف ناگهانی همیشه خوب نیست؛ گاهی باید اول rule را log-only یا محدودتر کرد و چند هفته رفتار را دید.

مرحله سوم: تست موازی و cutover محدود

در پروژه‌های حساس، بهتر است تا جای ممکن تست موازی انجام شود. حتی اگر ترافیک واقعی از فایروال جدید عبور نمی‌کند، می‌توان route، NAT، VPN، objectها و policyها را با نمونه‌های کنترل‌شده بررسی کرد. cutover هم بهتر است در window مشخص و با تیم آماده انجام شود، نه در زمانی که مالک سرویس‌ها در دسترس نیستند.

برای هر سرویس مهم باید تست ساده وجود داشته باشد: دسترسی کاربر، پاسخ سرویس، لاگ فایروال، مسیر برگشت و مانیتورینگ. اگر سرویس بعد از cutover کار می‌کند اما لاگ نداریم، کار هنوز کامل نیست.

مرحله چهارم: rollback واقعی

rollback باید قبل از اجرا نوشته شود. یعنی مشخص باشد اگر مشکل جدی رخ داد، دقیقاً چه چیزی به حالت قبل برمی‌گردد: کابل، route، NAT، DNS، VPN، policy یا همه این‌ها. backup config لازم است، اما کافی نیست. اگر تیم onsite، دسترسی console یا دستگاه قبلی آماده نیست، rollback فقط روی کاغذ وجود دارد.

اتصال به مسیر خدمات

برای پروژه‌های اجرایی، صفحه پیاده‌سازی فایروال سازمانی مسیر اصلی است. برای تصمیم قبل از اجرا، مطلب قبل از پیاده‌سازی فایروال سازمانی چه ریسک‌هایی را باید ببینیم؟ هم کمک می‌کند ریسک‌ها از ابتدا روشن شوند.

چطور cutover را قابل کنترل کنیم؟

برای cutover بهتر است لیست سرویس‌ها به ترتیب حساسیت نوشته شود. سرویس‌هایی مثل VPN شعب، سرویس‌های مالی، ایمیل، DNS داخلی، دسترسی مدیریت و سامانه مشتریان باید تست جدا داشته باشند. اگر همه تست‌ها به یک نفر سپرده شود، احتمال جا افتادن مشکل بالا می‌رود. مالک هر سرویس باید در زمان تغییر در دسترس باشد.

بعد از cutover هم چند ساعت اول مهم است. بعضی خطاها سریع دیده نمی‌شوند؛ مثل jobهای زمان‌بندی‌شده، ارتباط شبانه شعبه یا APIهایی که فقط در ساعت خاص استفاده می‌شوند. برای همین بهتر است post-change monitoring از قبل تعریف شود و فقط به اعلام «سایت باز شد» محدود نماند.

چه چیزهایی را بعد از migration پاک نکنیم؟

config قدیمی، لاگ‌های migration، جدول NAT و rule mapping باید نگه داشته شود. این‌ها برای troubleshooting هفته‌های بعد ارزش دارند. حذف سریع مستندات قدیمی باعث می‌شود هر مشکل کوچک به حدس و آزمون‌وخطا تبدیل شود.