NAT در Juniper SRX؛ تفاوت Source NAT، Destination NAT و Static NAT در سناریوهای واقعی

NAT در Juniper SRX اگر درست طراحی شود، ساده و قابل پیگیری است؛ اگر عجولانه نوشته شود، عیب‌یابی را سخت می‌کند. خیلی وقت‌ها Policy درست است، Route هم وجود دارد، اما ترافیک به مقصد نمی‌رسد چون NAT در جای اشتباه اعمال شده یا Rule عمومی‌تر قبل از Rule دقیق‌تر match می‌شود.

در SRX باید تفاوت سه مدل اصلی را روشن بدانیم: Source NAT برای تغییر مبدأ، Destination NAT برای انتشار سرویس داخلی روی آدرس دیگر، و Static NAT برای نگاشت ثابت و دوطرفه. انتخاب اشتباه بین این سه، مخصوصاً در DMZ و VPN، می‌تواند هم قطعی سرویس ایجاد کند هم ریسک امنیتی.

Source NAT؛ وقتی مبدأ باید تغییر کند

Source NAT معمولاً برای خروج کاربران یا سرورها به اینترنت استفاده می‌شود. در این حالت آدرس مبدأ داخلی به آدرس خارجی یا pool مشخص تبدیل می‌شود. نکته مهم این است که Source NAT نباید بی‌دلیل برای همه مسیرها فعال شود، چون در عیب‌یابی ارتباطات داخلی و VPN دردسر ایجاد می‌کند.

set security nat source rule-set users-to-internet from zone users
set security nat source rule-set users-to-internet to zone untrust
set security nat source rule-set users-to-internet rule office-users match source-address 10.10.10.0/24
set security nat source rule-set users-to-internet rule office-users then source-nat interface

اگر شبکه داخلی از طریق VPN به شعبه یا دیتاسنتر دیگر وصل است، باید مطمئن شوید ترافیک VPN ناخواسته Source NAT نمی‌شود. این خطا از آن مواردی است که Tunnel را up نشان می‌دهد، ولی ارتباط واقعی کار نمی‌کند.

Destination NAT؛ انتشار سرویس داخلی

Destination NAT زمانی استفاده می‌شود که کاربر یا سامانه بیرونی به یک آدرس عمومی وصل می‌شود و SRX مقصد را به IP داخلی سرویس تبدیل می‌کند. برای وب‌سرور، پنل سازمانی، سرویس API یا دسترسی محدود از بیرون معمولاً این مدل دیده می‌شود.

set security nat destination pool app01 address 10.10.20.11/32
set security nat destination rule-set internet-to-dmz from zone untrust
set security nat destination rule-set internet-to-dmz rule publish-https match destination-address 203.0.113.10/32
set security nat destination rule-set internet-to-dmz rule publish-https match destination-port 443
set security nat destination rule-set internet-to-dmz rule publish-https then destination-nat pool app01

بعد از Destination NAT هنوز Policy لازم است. Policy باید مسیر from-zone به to-zone درست را پوشش دهد و مقصد نهایی را بر اساس رفتار SRX درست در نظر بگیرد. در طراحی production بهتر است لاگ برای این مسیر فعال باشد تا درخواست‌های ورودی و خطاهای احتمالی دیده شوند.

Static NAT؛ نگاشت ثابت و دوطرفه

Static NAT برای زمانی است که یک آدرس داخلی و خارجی رابطه ثابت دارند و مسیر برگشت هم باید قابل پیش‌بینی باشد. این مدل برای بعضی سرویس‌های خاص یا سناریوهای migration کاربرد دارد، اما نباید جایگزین بی‌دلیل Destination NAT شود. Static NAT اگر زیاد و بدون نظم استفاده شود، مدیریت آدرس‌ها را سخت می‌کند.

ترتیب و محدوده Ruleها را کنترل کنید

در NAT، Rule عمومی می‌تواند Rule دقیق‌تر را پنهان کند. برای همین rule-setها باید بر اساس zone و سناریو جدا شوند. یک rule-set بزرگ که هم اینترنت، هم VPN و هم DMZ را پوشش می‌دهد، دیر یا زود مشکل‌ساز می‌شود.

• Source NAT اینترنت را از NAT مربوط به VPN جدا نگه دارید.
• برای سرویس‌های منتشرشده، Destination NAT را با Policy و لاگ هماهنگ کنید.
• Ruleهای موقت migration را بعد از پایان پروژه پاک یا محدود کنید.
• قبل از تغییر، خروجی تنظیمات NAT و Policy مربوطه را ذخیره کنید.

عیب‌یابی NAT در SRX

در عیب‌یابی، فقط دیدن session کافی نیست. باید ببینید packet با چه مبدأ و مقصدی وارد شده، کدام NAT روی آن اعمال شده، به کدام Zone رفته و Policy چه تصمیمی گرفته است. برای شروع، خروجی‌های زیر معمولاً تصویر خوبی می‌دهند:

show security nat source rule all
show security nat destination rule all
show security flow session source-prefix 10.10.10.10
show security flow session destination-prefix 10.10.20.11

در محیط‌های حساس، بهتر است قبل از تغییر NAT یک برنامه rollback کوتاه داشته باشید. تغییر NAT اشتباه می‌تواند چند سرویس را هم‌زمان از دسترس خارج کند، حتی اگر خود فایروال و routeها سالم باشند.

جمع‌بندی

NAT در Juniper SRX باید با Zone، Policy و Route هم‌زمان دیده شود. Source NAT برای تغییر مبدأ، Destination NAT برای انتشار سرویس، و Static NAT برای نگاشت ثابت است. وقتی این سه با هم قاطی شوند، فایروال کار می‌کند اما قابل پشتیبانی نیست. طراحی درست یعنی هر NAT دلیل، محدوده و مسیر عیب‌یابی مشخص داشته باشد.