آموزش کانفیگ NAT در فایروال سیسکو ASA و FTD (Static, Dynamic, PAT)

NAT یکی از پایه‌ای‌ترین اما در عین حال حساس‌ترین بخش‌های طراحی فایروال است. اشتباه در NAT می‌تواند باعث قطع کامل دسترسی اینترنت، اختلال در VPN یا حتی باز شدن ناخواسته سرویس‌ها به بیرون شود. در این مقاله، کانفیگ و منطق NAT در Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense را به‌صورت مهندسی بررسی می‌کنیم و سه سناریوی اصلی Static NAT، Dynamic NAT و PAT را پیاده‌سازی می‌کنیم.

هدف فقط نوشتن دستور نیست، بلکه درک رفتار NAT Engine در هر دو پلتفرم است.

درک منطق NAT در ASA و FTD

برای کانفیگ درست NAT، فقط دانستن دستور کافی نیست. باید بدانید موتور NAT دقیقاً در چه مرحله‌ای از پردازش Packet وارد عمل می‌شود، ترتیب Ruleها چگونه بررسی می‌شود و NAT چه ارتباطی با ACL، Routing و VPN دارد. بسیاری از مشکلات عملی در پروژه‌ها ناشی از درک ناقص همین منطق است.

در Cisco Adaptive Security Appliance، NAT بر اساس ساختار Section-Based پردازش می‌شود. به‌صورت منطقی سه بخش اصلی وجود دارد: Manual NAT (Before-Auto)، Auto NAT (Object NAT) و After-Auto NAT. ترتیب بررسی دقیقاً به همین شکل است. ابتدا Manual NATهای بخش اول بررسی می‌شوند. اگر Rule منطبق پیدا نشود، سیستم وارد Auto NAT می‌شود. در نهایت اگر باز هم Matchی وجود نداشته باشد، After-Auto بررسی می‌شود.

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

در ASA، ترجمه NAT قبل از اعمال Access Control انجام می‌شود، اما نکته مهم اینجاست که ACLها بر اساس Real IP نوشته می‌شوند، نه Translated IP. این موضوع یکی از نقاطی است که بسیاری از مهندسان تازه‌کار را سردرگم می‌کند. Packet ابتدا NAT می‌شود، اما هنگام بررسی ACL، فایروال همچنان IP واقعی را در نظر می‌گیرد. در عیب‌یابی اگر این موضوع درک نشده باشد، نتیجه تحلیل اشتباه خواهد بود.

در Cisco Firepower Threat Defense منطق پایه NAT مشابه ASA است، زیرا موتور ترجمه مشترک است. تفاوت در نحوه مدیریت و نمایش Ruleهاست. در FTD، NAT Policy از طریق Cisco Firepower Management Center تعریف می‌شود و Ruleها به‌صورت گرافیکی در سه بخش مشابه دسته‌بندی می‌شوند. همچنان ترتیب Ruleها و نوع NAT (Manual یا Auto) تعیین‌کننده رفتار نهایی است، اما تغییرات پس از Deploy فعال می‌شوند.

موضوع مهم دیگر، تعامل NAT با VPN است. در هر دو پلتفرم، اگر NAT Exemption به‌درستی تعریف نشود، ترافیک VPN قبل از ورود به Tunnel ترجمه می‌شود و در نتیجه Proxy ID یا Encryption Domain با سمت مقابل همخوانی نخواهد داشت. نتیجه این است که Tunnel بالا می‌آید اما ترافیک عبور نمی‌کند. این یکی از رایج‌ترین سناریوهای خطا در پروژه‌های Site-to-Site است.

همچنین باید درک کنید که NAT فقط Source Translation نیست. Destination NAT، Identity NAT و Twice NAT نیز وجود دارند. در سناریوهای پیچیده مانند انتشار سرویس در DMZ یا طراحی با چند لینک اینترنت، ممکن است نیاز به Twice NAT داشته باشید که هم Source و هم Destination را همزمان ترجمه می‌کند. این نوع NAT معمولاً باید در بخش Manual NAT تعریف شود تا اولویت بالاتری داشته باشد.

از نظر پردازش Packet، ترتیب ساده‌شده در ASA و FTD معمولاً به این شکل است:
Route Lookup اولیه
NAT Translation
Access Control Policy
Intrusion Policy و سایر Featureها

درک این ترتیب کمک می‌کند هنگام استفاده از ابزارهایی مانند packet-tracer دقیقاً بدانید Packet در کدام مرحله Drop می‌شود.

سناریو اول: Static NAT

Static NAT ساده به نظر می‌رسد، اما در پروژه‌های واقعی یکی از حساس‌ترین بخش‌های طراحی است. چون معمولاً برای Publish کردن سرویس‌های مهم مانند وب‌سرور، میل‌سرور یا API استفاده می‌شود. هر اشتباه در این بخش می‌تواند یا سرویس را از دسترس خارج کند یا ناخواسته آن را بیش از حد در معرض اینترنت قرار دهد.

در Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense، منطق Static NAT این است که یک IP داخلی همیشه به یک IP عمومی مشخص نگاشت شود. این نگاشت دوطرفه است. یعنی هم ترافیک خروجی از سرور با IP عمومی ترجمه می‌شود، هم ترافیک ورودی به IP عمومی به IP داخلی هدایت می‌گردد.

درک رفتار Static NAT در عمل

فرض کنید یک وب‌سرور داخلی با IP 192.168.10.10 دارید که باید از طریق IP عمومی 1.1.1.10 در دسترس اینترنت باشد. وقتی کلاینتی از اینترنت به 1.1.1.10 روی پورت 443 متصل می‌شود، فایروال ابتدا Destination را به 192.168.10.10 ترجمه می‌کند، سپس Access Control Policy بررسی می‌شود تا اجازه عبور داده شود یا خیر.

نکته مهم این است که در ASA و FTD، ACL یا Access Control Policy بر اساس IP واقعی سرور نوشته می‌شود، نه IP عمومی. یعنی شما در Policy باید 192.168.10.10 را Allow کنید، نه 1.1.1.10. این موضوع در عیب‌یابی بسیار کلیدی است.

کانفیگ Static NAT در ASA

در ASA معمولاً از Object NAT استفاده می‌شود:

پس از اعمال این تنظیم، ترجمه فعال می‌شود. اما این به‌تنهایی کافی نیست. باید یک ACL نیز تعریف شود که ترافیک ورودی از outside به این سرور روی پورت موردنظر مجاز باشد.

مثلاً:

اگر NAT درست تعریف شده باشد ولی ACL وجود نداشته باشد، سرویس همچنان در دسترس نخواهد بود.

کانفیگ Static NAT در FTD

در FTD، Static NAT معمولاً به‌صورت Manual NAT در FMC تعریف می‌شود. شما Source Interface را inside، Destination Interface را outside انتخاب می‌کنید و Static Translation را مشخص می‌نمایید. سپس در Access Control Policy باید Rule مناسب برای Allow کردن ترافیک به Real IP تعریف شود. در نهایت Deploy انجام می‌شود.

تفاوت اصلی با ASA در این است که تغییرات بلافاصله فعال نمی‌شوند و نیاز به Deploy دارند.

Static NAT با Port Forwarding

در برخی سناریوها، فقط یک پورت خاص باید Publish شود، نه کل IP. در این حالت از Static PAT استفاده می‌شود. مثلاً اگر فقط پورت 8443 روی IP عمومی به 443 داخلی هدایت شود:

در ASA:

در این حالت، کاربر اینترنتی به 1.1.1.10:8443 متصل می‌شود و ترافیک به 192.168.10.10:443 هدایت می‌شود.

سناریوی عملی و خطاهای رایج

در یک پروژه واقعی، Static NAT برای یک سرور ERP تعریف شده بود اما کاربران اینترنت به سرویس دسترسی نداشتند. بررسی نشان داد NAT درست تعریف شده، اما ACL روی outside به IP عمومی نوشته شده بود، نه IP داخلی. چون ASA ACL را بر اساس Real IP بررسی می‌کند، ترافیک Drop می‌شد. با اصلاح ACL مشکل بلافاصله حل شد.

خطای رایج دیگر، هم‌پوشانی Static NAT با Ruleهای Dynamic یا PAT است. اگر ترتیب Ruleها اشتباه باشد، ممکن است یک Rule عمومی‌تر زودتر Match شود و Static NAT اجرا نشود.

نکات مهندسی در طراحی Static NAT

IP عمومی اختصاص‌داده‌شده نباید در Pool Dynamic استفاده شود.
Ruleهای Static باید بالاتر از Ruleهای عمومی قرار گیرند.
همیشه Logging را برای ترافیک ورودی به سرویس‌های Publish شده فعال کنید.
در سناریوهای چند لینک اینترنت، توجه کنید Route و NAT با هم همخوانی داشته باشند.

سناریو دوم: Dynamic NAT

Dynamic NAT زمانی استفاده می‌شود که بخواهیم یک محدوده از IPهای داخلی به یک Pool از IPهای عمومی ترجمه شوند، به‌گونه‌ای که هر کلاینت داخلی هنگام خروج، یکی از IPهای آزاد Pool را دریافت کند. برخلاف Static NAT که نگاشت ثابت و دائمی است، در Dynamic NAT نگاشت به‌صورت موقت و بر اساس Session ایجاد می‌شود.

در Cisco Adaptive Security Appliance و Cisco Firepower Threat Defense منطق Dynamic NAT مشابه است، اما نحوه پیاده‌سازی و مدیریت آن متفاوت است.

درک رفتار Dynamic NAT در عمل

فرض کنید شبکه داخلی 192.168.20.0/24 دارید و ISP به شما یک رنج عمومی 1.1.1.20 تا 1.1.1.30 داده است. می‌خواهید کلاینت‌های داخلی هنگام خروج به اینترنت، هر کدام یک IP عمومی از این Pool دریافت کنند.

وقتی اولین کلاینت داخلی یک اتصال ایجاد می‌کند، فایروال یکی از IPهای آزاد Pool را به آن اختصاص می‌دهد. این نگاشت تا زمانی که Session فعال است باقی می‌ماند. پس از پایان Session، IP آزاد می‌شود و می‌تواند به کلاینت دیگری تخصیص داده شود.

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

کانفیگ Dynamic NAT در ASA

در ASA معمولاً از Object NAT برای این کار استفاده می‌شود:

در این حالت، هر کلاینت داخلی یکی از IPهای این رنج را دریافت می‌کند.

برای بررسی ترجمه‌های فعال:

این دستور نگاشت‌های فعال NAT را نمایش می‌دهد.

کانفیگ Dynamic NAT در FTD

در FTD از طریق Cisco Firepower Management Center وارد NAT Policy می‌شوید، یک Auto NAT Rule تعریف می‌کنید، Source Network را انتخاب کرده و نوع ترجمه را Dynamic NAT با Pool مشخص می‌کنید. سپس Deploy انجام می‌شود.

تفاوت Dynamic NAT با PAT

در Dynamic NAT هر کلاینت یک IP عمومی جداگانه دریافت می‌کند. در PAT چندین کلاینت از یک IP عمومی مشترک با ترجمه Port استفاده می‌کنند. بنابراین Dynamic NAT مصرف IP عمومی بیشتری دارد اما در برخی سناریوها مانند نیاز به IP اختصاصی برای هر کاربر یا جلوگیری از Blacklist شدن یک IP مشترک مفید است.

سناریوی عملی

در یک سازمان، برای خروج کاربران واحد مالی به اینترنت، Dynamic NAT با Pool جداگانه تعریف شد تا ترافیک آن‌ها از سایر کاربران تفکیک شود. این کار امکان مانیتورینگ دقیق‌تر و اعمال Policy متفاوت در سمت ISP را فراهم کرد.

در سناریوی دیگر، Pool فقط شامل سه IP عمومی بود اما بیش از 20 کاربر همزمان اتصال برقرار می‌کردند. نتیجه این شد که برخی کاربران نتوانستند به اینترنت دسترسی پیدا کنند. بررسی show xlate نشان داد تمام IPهای Pool مصرف شده‌اند. با افزایش اندازه Pool مشکل برطرف شد.

خطاهای رایج در Dynamic NAT

کم بودن تعداد IPهای Pool نسبت به تعداد کاربران
هم‌پوشانی Pool با IPهای Static NAT
قرار گرفتن Rule عمومی PAT بالاتر از Dynamic NAT
فراموش کردن Route مناسب برای رنج عمومی

نکات مهندسی

اگر تعداد IP عمومی محدود است، معمولاً PAT گزینه بهتری است.
Dynamic NAT زمانی منطقی است که نیاز به تفکیک IP عمومی یا Log دقیق‌تری داشته باشید.
همیشه Ruleهای خاص‌تر را بالاتر از Ruleهای عمومی قرار دهید.
در محیط‌های دارای VPN، مطمئن شوید Dynamic NAT روی ترافیک داخلی به شبکه‌های VPN اعمال نشود.

سناریو سوم: PAT (Port Address Translation)

PAT رایج‌ترین نوع NAT در سازمان‌هاست. در این روش، چندین IP داخلی از یک IP عمومی مشترک با ترجمه Port استفاده می‌کنند.

کانفیگ PAT در ASA

در این حالت، تمام کاربران از IP اینترفیس outside برای خروج به اینترنت استفاده می‌کنند.

کانفیگ PAT در FTD

در FMC یک Auto NAT Rule تعریف کنید و گزینه Dynamic PAT with Interface IP را انتخاب نمایید. پس از Deploy، ترجمه فعال می‌شود.

NAT Exemption برای VPN

در سناریوهای Site-to-Site یا Remote Access VPN، ترافیک بین دو شبکه نباید NAT شود. در ASA:

در FTD نیز باید یک Manual NAT Rule از نوع Identity NAT تعریف شود.

اگر این مرحله انجام نشود، VPN Tunnel برقرار می‌شود اما ترافیک عبور نخواهد کرد.

عیب‌یابی NAT

در ASA ابزار قدرتمند packet-tracer بسیار مفید است:

این دستور نشان می‌دهد ترافیک در کدام مرحله NAT یا ACL Drop می‌شود.

در FTD نیز packet-tracer از CLI قابل اجراست و Logهای FMC نیز کمک بزرگی هستند.

رایج‌ترین خطاها در NAT شامل ترتیب اشتباه Ruleها، هم‌پوشانی Poolها و فراموش کردن NAT Exemption است.

تفاوت عملی ASA و FTD در NAT

در ASA، کانفیگ NAT مستقیم و CLIمحور است و تغییرات فوری اعمال می‌شود. در FTD، NAT بخشی از Policy گرافیکی است و نیاز به Deploy دارد. در محیط‌هایی با تغییرات مکرر، این تفاوت در Workflow اهمیت پیدا می‌کند.

از نظر منطق پردازش، رفتار NAT در هر دو بسیار مشابه است، زیرا موتور پایه مشترک است.

جمع‌بندی مهندسی

NAT فقط ترجمه IP نیست، بلکه بخشی از معماری امنیتی شبکه است. ترتیب Ruleها، تعامل با ACL و VPN و انتخاب نوع NAT همگی بر پایداری شبکه اثر دارند.

در ASA انعطاف CLI بالا است و تغییرات سریع اعمال می‌شود. در FTD مدیریت متمرکز و گرافیکی وجود دارد اما فرآیند Deploy باید در نظر گرفته شود.

طراحی صحیح NAT از ابتدا، بسیاری از مشکلات بعدی در VPN، Publish سرویس‌ها و دسترسی اینترنت را حذف می‌کند.

وینو سرور؛ مرجع تخصصی طراحی و عیب‌یابی NAT

پیاده‌سازی NAT در محیط‌های Enterprise، به‌ویژه در سناریوهای ترکیبی شامل VPN، DMZ و چندین لینک اینترنت، نیازمند تجربه عملی است. اشتباه کوچک در ترتیب Rule می‌تواند ساعت‌ها زمان عیب‌یابی ایجاد کند.

وینو سرور به عنوان مرجع تخصصی در حوزه Cisco ASA و Firepower، با تجربه عملی در طراحی و بهینه‌سازی NAT در پروژه‌های سازمانی، به شما کمک می‌کند ساختار ترجمه IP را به‌صورت پایدار، امن و قابل توسعه پیاده‌سازی کنید. اگر به دنبال اجرای مهندسی و بدون ریسک NAT در زیرساخت خود هستید، وینو سرور می‌تواند نقطه اتکای تخصصی شما باشد.