تبدیل کانفیگ FortiGate به Juniper با Python؛ تجربه یک مهاجرت واقعی فایروال

در یکی از پروژه‌هایی که نیاز به تعویض فایروال داشتیم، یکی از بخش‌های زمان‌بر کار، تبدیل کانفیگ‌های FortiGate به ساختار قابل استفاده در Juniper بود. اگر تعداد policyها، objectها، address groupها، serviceها و scheduleها کم باشد، شاید تبدیل دستی قابل قبول باشد؛ اما در پروژه‌های واقعی، تبدیل دستی هم کند است، هم خطاپذیر، و هم بررسی نهایی را سخت‌تر می‌کند.

برای همین، یک اسکریپت پایتونی نوشتم که از طریق API به FortiGate متصل می‌شود، بخش‌هایی از کانفیگ را می‌خواند و خروجی را به شکل دستورهای Juniper CLI تولید می‌کند. سورس این ابزار در GitHub منتشر شده است:

FortigateToJuniper در GitHub

چرا تبدیل FortiGate به Juniper ساده نیست؟

در نگاه اول ممکن است تصور شود که تبدیل کانفیگ بین دو فایروال فقط جایگزین کردن چند دستور است؛ اما در عمل، مدل ذهنی FortiGate و Juniper در بعضی بخش‌ها متفاوت است. برای مثال:

  • در FortiGate معمولاً با VDOM، interface، address object، address group، service و firewall policy کار می‌کنیم.
  • در Juniper، مخصوصاً در SRX، مفاهیم zone، address-book، address-set، application و security policy نقش اصلی دارند.
  • نام‌گذاری objectها، نحوه تعریف range، FQDN، geography object و scheduleها ممکن است نیاز به بازبینی داشته باشد.
  • ترتیب policyها و رفتار implicit deny باید قبل از اعمال کانفیگ در محیط عملیاتی بررسی شود.

بنابراین هدف ابزار این نیست که بدون بررسی انسانی، کانفیگ را مستقیم روی فایروال مقصد اعمال کند. هدف اصلی این است که حجم زیادی از کار تکراری تبدیل اولیه را خودکار کند تا مهندس شبکه بتواند زمان بیشتری را روی طراحی، بازبینی و تست بگذارد.

این اسکریپت چه کاری انجام می‌دهد؟

پروژه FortigateToJuniper با Python نوشته شده و با استفاده از کتابخانه fortigate-api به FortiGate وصل می‌شود. ایده اصلی این است که تنظیمات مورد نیاز از FortiGate خوانده شود و معادل اولیه آن‌ها به شکل دستورهای Juniper تولید شود.

در ساختار فعلی ریپو، چند بخش مهم دیده می‌شود:

  • Policy.py: دریافت firewall policyها و تبدیل آن‌ها به دستورهای set security policies در Juniper.
  • object.py: دریافت address objectها مثل IP/Subnet، FQDN، IP Range و geography object و تبدیل آن‌ها به address-book در Juniper.
  • object-group.py: تبدیل address groupهای FortiGate به address-set در Juniper.
  • ports.py: تبدیل سرویس‌ها و پورت‌ها.
  • schedules.py و schedules-recurring.py: کمک به تبدیل scheduleها.
  • zone.py: آماده‌سازی بخش‌هایی که به zone و interface مربوط می‌شوند.

نمونه تبدیل policy

در FortiGate، یک policy معمولاً شامل مواردی مثل source interface، destination interface، source address، destination address، service، action، schedule و وضعیت logging است. اسکریپت این اطلاعات را از API می‌خواند و خروجی‌ای مشابه دستورهای زیر تولید می‌کند:

set security policies from-zone LAN to-zone WAN policy policy-10 match source-address Internal-Network destination-address Internet application HTTPS
set security policies from-zone LAN to-zone WAN policy policy-10 then permit
set security policies from-zone LAN to-zone WAN policy policy-10 then log session-init session-close

این خروجی برای استفاده نهایی هنوز باید بررسی شود، اما مزیت بزرگ آن این است که اسکلت اصلی policyها، objectها و گروه‌ها سریع‌تر آماده می‌شود.

مزیت استفاده از API به جای کپی دستی کانفیگ

یکی از تصمیم‌های خوب در این پروژه استفاده از API است. وقتی مستقیماً از API می‌خوانیم، داده‌ها ساختارمندتر هستند و نیاز کمتری به parse کردن خروجی متنی CLI داریم. این روش چند مزیت دارد:

  • کاهش خطای انسانی در خواندن و تبدیل کانفیگ.
  • امکان اجرای مجدد اسکریپت بعد از تغییرات جدید در FortiGate.
  • امکان توسعه تدریجی ابزار برای object typeهای بیشتر.
  • امکان ساخت گزارش و خروجی قابل بررسی قبل از migration.
  • مناسب بودن برای پروژه‌هایی که چند VDOM یا تعداد زیادی policy دارند.

پیش‌نیازها

برای اجرای ابزار، Python نسخه ۳.۷ یا بالاتر و چند کتابخانه لازم است:

pip install -r requirements.txt

بعد از نصب وابستگی‌ها، باید اطلاعات اتصال FortiGate در اسکریپت تنظیم شود:

  • HOST: آدرس FortiGate
  • USERNAME: نام کاربری
  • PASSWORD: رمز عبور
  • VDOM: نام VDOM مورد نظر

نکته مهم امنیتی: بهتر است برای این کار یک اکانت محدود و مخصوص API ساخته شود؛ نه اینکه از اکانت اصلی ادمین برای اسکریپت استفاده کنیم. همچنین بهتر است اطلاعات حساس مثل username و password در نسخه عمومی کد قرار نگیرد و از متغیرهای محیطی یا فایل تنظیمات امن استفاده شود.

چرا این ابزار برای پروژه‌های Migration مهم است؟

در پروژه‌های مهاجرت فایروال، مشکل اصلی فقط نوشتن کانفیگ جدید نیست. چالش اصلی این است که مطمئن شویم رفتار امنیتی شبکه بعد از مهاجرت تغییر ناخواسته نداشته باشد. یعنی:

  • policyهای مهم حذف نشوند.
  • objectها اشتباه map نشوند.
  • سرویس‌ها و پورت‌ها درست تبدیل شوند.
  • ترتیب ruleها و zoneها بررسی شود.
  • logging و visibility حفظ شود.
  • قبل از cutover، خروجی در محیط lab یا maintenance window تست شود.

اسکریپت‌هایی مثل FortigateToJuniper کمک می‌کنند بخش تکراری کار سریع‌تر انجام شود، اما تصمیم نهایی همچنان باید با مهندس شبکه باشد. این ترکیب، یعنی automation همراه با review انسانی، بهترین مدل برای چنین پروژه‌هایی است.

چک‌لیست پیشنهادی قبل از اعمال خروجی روی Juniper

  • خروجی CLI را روی یک دستگاه آزمایشی یا lab بررسی کنید.
  • نام zoneها را با طراحی نهایی Juniper تطبیق دهید.
  • address-book و address-setها را از نظر تکراری بودن یا نام‌های ناسازگار بررسی کنید.
  • policyهای deny، disabled و temporary را جداگانه بازبینی کنید.
  • serviceهای سفارشی را با applicationهای Juniper تطبیق دهید.
  • قبل از commit، از دستورهای check/compare در Junos استفاده کنید.
  • بعد از migration، لاگ‌ها و sessionها را مانیتور کنید.

جمع‌بندی

تبدیل کانفیگ FortiGate به Juniper کاری نیست که همیشه بتوان آن را صد درصد خودکار و بدون ریسک انجام داد؛ اما خودکارسازی بخش‌های تکراری آن می‌تواند زمان پروژه را بسیار کمتر کند و احتمال خطا را پایین بیاورد. این اسکریپت دقیقاً برای همین هدف نوشته شده است: دریافت کانفیگ از FortiGate، تولید خروجی اولیه Juniper CLI و فراهم کردن یک نقطه شروع قابل بررسی برای مهاجرت فایروال.

اگر شما هم درگیر مهاجرت FortiGate به Juniper هستید، می‌توانید سورس پروژه را از GitHub ببینید و بسته به نیاز پروژه خودتان آن را توسعه دهید:

مشاهده پروژه FortigateToJuniper

برای مطالعه مرتبط، این مطلب هم می‌تواند مفید باشد: به عنوان مهندس شبکه و امنیت شبکه، چرا پایتون یاد بگیرم؟

n

برچسبها
مطالب مرتبط

دیدگاهی بنویسید.

بهتر است دیدگاه شما در ارتباط با همین مطلب باشد.