چکلیست عملی Juniper SRX؛ Policy، NAT، VPN و Logging را جدا نبینید
در Juniper SRX اگر Policy، NAT، VPN و Logging جدا از هم طراحی شوند، شبکه بعد از چند ماه سخت عیبیابی میشود. ممکن است tunnel برقرار باشد اما ترافیک عبور نکند، rule درست به نظر برسد اما NAT مسیر را تغییر دهد، یا لاگ کافی برای فهمیدن مشکل وجود نداشته باشد. طراحی SRX باید از ابتدا با نگاه عملیاتی انجام شود.
Zone و Policy پایه تصمیم است
در SRX، zone فقط یک برچسب نیست؛ مدل فکری فایروال بر اساس zone و policy شکل میگیرد. قبل از نوشتن rule باید مشخص باشد هر interface در چه zoneای قرار دارد، مسیر اعتماد بین zoneها چیست، و کدام سرویسها واقعا باید عبور کنند. policyهای باز و موقت معمولا بعدا دائمی میشوند و سطح حمله را بالا میبرند.
NAT را بعد از Policy فراموش نکنید
خیلی از خطاهای SRX به خاطر ناهماهنگی بین policy و NAT است. اگر source NAT، destination NAT یا static NAT دارید، باید مسیر packet را قبل و بعد از ترجمه آدرس بفهمید. مستندسازی NAT در کنار policy کمک میکند تغییر بعدی باعث قطع سرویس نشود.
VPN بدون لاگ یعنی عیبیابی کند
در Site-to-Site VPN فقط up بودن tunnel کافی نیست. باید phaseها، proxy-id یا traffic selector، routing، policy و NAT کنار هم بررسی شوند. لاگ مناسب باعث میشود بفهمید مشکل از مذاکره VPN است یا ترافیک بعد از بالا آمدن tunnel اجازه عبور ندارد.
show security flow session
show security ike security-associations
show security ipsec security-associations
show log messages | match ikeچکلیست نگهداری
- نامگذاری واضح: address book، application و policy name باید بعد از چند ماه هم قابل فهم باشد.
- لاگ برای ruleهای حساس: همه چیز را log نکنید، اما ruleهای حیاتی بدون log نمانند.
- backup قبل از تغییر: تغییر NAT یا VPN بدون backup و rollback plan ریسک جدی دارد.
- بازبینی ruleهای موقت: ruleهای emergency باید تاریخ پایان و مالک داشته باشند.
روش بررسی قبل از تغییر در SRX
قبل از تغییر policy یا NAT در Juniper SRX، بهتر است مسیر یک packet نمونه را روی کاغذ یا در مستند تغییر بنویسید: مبدا، مقصد، zone ورودی، zone خروجی، route، policy، NAT و log. همین تمرین ساده جلوی بسیاری از خطاهایی را میگیرد که بعدا با عنوان tunnel up است ولی ترافیک رد نمیشود دیده میشوند.
در محیطهای شلوغ، address book و application objectهای بینام یا تکراری خیلی زود policy را غیرقابل نگهداری میکنند. اگر نام object نشان ندهد متعلق به کدام سرویس، شعبه یا مالک است، عیبیابی بعدی کند و پرریسک میشود. در بازبینی دورهای، objectهای بدون استفاده و ruleهای موقت باید جداگانه علامتگذاری شوند.
چکهای عملیاتی بعد از تغییر
- یک session واقعی را با source/destination مشخص بررسی کنید، نه فقط وضعیت کلی interface را.
- برای VPN، هم IKE/IPsec و هم route و security policy را کنار هم ببینید.
- اگر NAT تغییر کرده، از سمت سرویس مقصد هم source IP دیدهشده را کنترل کنید.
- لاگ rule جدید را فقط به اندازه لازم فعال کنید تا هم عیبیابی ممکن باشد و هم نویز لاگ زیاد نشود.
منبع رسمی: Juniper security policies documentation و مستندات SRX در Juniper TechLibrary.
مستندسازی که واقعا به درد میخورد
برای SRX، مستند خوب لازم نیست طولانی باشد؛ باید برای هر سرویس مهم، zone مبدا و مقصد، policy name، NAT مرتبط، route و وضعیت log را نشان دهد. وقتی حادثه یا تغییر فوری پیش میآید، همین چند خط باعث میشود تیم به جای حدس زدن، مسیر packet را مرحلهبهمرحله بررسی کند.
NAT در Juniper SRX؛ تفاوت Source NAT، Destination NAT و Static NAT در سناریوهای واقعی
تبدیل کانفیگ FortiGate به Juniper با Python؛ تجربه یک مهاجرت واقعی فایروال
طراحی Security Zone و Policy در Juniper SRX؛ از trust و untrust تا Rule قابل دفاع
HA و Chassis Cluster در Juniper SRX؛ قبل از Failover چه چیزهایی را چک کنیم؟