ترجمه آدرس شبکه: اشتراک‌گذاری آدرس‌های IP عمومی

تأمین محدود آدرس‌های IPv4 عمومی باعث شد غیرممکن باشد هر دستگاه در سراسر جهان آدرس یکتای جهانی خودش را داشته باشد، و NAT این را با اجازه‌دادن به بسیاری دستگاه خصوصی برای اشتراک‌گذاری تعداد کمی آدرس عمومی حل کرد. این مقاله سه نوع اصلی NAT را توضیح می‌دهد، پیکربندی static NAT، dynamic NAT، و PAT روی یک روتر سیسکو را مرور می‌کند، و دستورات ضروری برای تأیید ترجمه‌های فعال را پوشش می‌دهد.

پیکربندی NATPATStatic NAT

~5 min read · Updated Sep 9, 2026

چرا NAT ضروری شد

IPv4 تقریباً ۴.۳ میلیارد آدرس ممکن فراهم می‌کند، عددی که دهه‌ها پیش عظیم به‌نظر می‌رسید اما وقتی اینترنت به میلیاردها دستگاه متصل رشد کرد بسیار کوچک ثابت شد. بازه‌های آدرس خصوصی که پیش‌تر در این مجموعه درباره آدرس‌دهی IPv4 بحث شد بخشی از این مسئله را با اجازه‌دادن به شبکه‌های داخلی برای استفاده‌مجدد از همان بازه‌های آدرس حل می‌کنند، اما یک دستگاه که از یک آدرس خصوصی استفاده می‌کند نمی‌تواند مستقیماً با اینترنت عمومی ارتباط برقرار کند، چون آدرس‌های خصوصی به‌طور جهانی مسیریابی‌پذیر نیستند. NAT (Network Address Translation) این قطعه نهایی را با ترجمه آدرس‌های خصوصی به عمومی هنگام عبور ترافیک از مرز بین یک شبکه داخلی و اینترنت حل می‌کند.

Static NAT: یک نگاشت یک-به-یک ثابت

Static NAT یک نگاشت دائمی و بدون‌تغییر بین یک آدرس خصوصی خاص و یک آدرس عمومی خاص ایجاد می‌کند — معمولاً برای سرورهای داخلی که نیاز دارند به‌طور پیوسته از اینترنت قابل‌دسترسی باشند، مانند یک سرور وب یا سرور ایمیل، استفاده می‌شود.

Router(config)# ip nat inside source static 192.168.1.10 203.0.113.10

Router(config)# interface gigabitethernet 0/1
Router(config-if)# ip nat inside
Router(config-if)# exit

Router(config)# interface gigabitethernet 0/0
Router(config-if)# ip nat outside

هر پیکربندی NAT نیازمند تعیین اینکه کدام اینترفیس‌ها inside (رو‌به‌سمت شبکه خصوصی) و کدام outside (رو‌به‌سمت اینترنت عمومی) هستند — بدون این تعیین، روتر هیچ راهی برای دانستن اینکه ترجمه باید به کدام جهت اعمال شود ندارد.

Dynamic NAT: نگاشت از یک استخر آدرس‌ها

Dynamic NAT آدرس‌های خصوصی را به آدرس‌های عمومی برداشته‌شده از یک استخر تعریف‌شده نگاشت می‌کند، که به‌صورت اول‌آمده-اول‌دریافت‌شده به‌جای یک رابطه ثابت یک‌به‌یک اختصاص می‌یابند.

Router(config)# ip nat pool PUBLIC-POOL 203.0.113.20 203.0.113.30 netmask 255.255.255.0

Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

Router(config)# ip nat inside source list 1 pool PUBLIC-POOL

-- لیست دسترسی مشخص می‌کند کدام آدرس‌های داخلی
-- واجد شرایط ترجمه هستند، که پیش‌تر در این مجموعه
-- درباره ACL های استاندارد بحث شد

Dynamic NAT همچنان به یک آدرس عمومی به‌ازای هر دستگاه داخلی فعال هم‌زمان نیاز دارد، چون همچنان اساساً یک نگاشت یک-به-یک است — فقط با جفت‌سازی خاصی که به‌طور پویا تعیین می‌شود به‌جای پیکربندی ایستا برای هر دستگاه. این آن را به یک میانه تبدیل می‌کند: مقیاس‌پذیرتر از static NAT برای دستگاه‌های زیاد، اما همچنان توسط اندازه استخر آدرس عمومی محدود است.

PAT: راه‌حلی که واقعاً مقیاس می‌یابد

PAT (Port Address Translation)، که NAT Overload نیز نامیده می‌شود، محدودیت مقیاس‌بندی هم static و هم dynamic NAT را با اجازه‌دادن به بسیاری دستگاه داخلی برای اشتراک‌گذاری یک آدرس IP عمومی واحد به‌طور هم‌زمان، و تشخیص آن‌ها با استفاده از شماره پورت‌های منبع متفاوت، حل می‌کند.

Router(config)# access-list 1 permit 192.168.1.0 0.0.0.255

Router(config)# ip nat inside source list 1 interface gigabitethernet 0/0 overload

-- "overload" کلیدواژه‌ای است که PAT را فعال می‌کند،
-- و از آدرس IP خود اینترفیس بیرونی به‌عنوان آدرس
-- عمومی مشترک برای همه دستگاه‌های داخلی
-- ترجمه‌شده استفاده می‌کند

این تا حد زیادی رایج‌ترین پیکربندی NAT در شبکه‌های دنیای واقعی است، شامل تقریباً هر روتر خانگی، چون اجازه می‌دهد یک کل شبکه با بالقوه صدها دستگاه یک آدرس IP عمومی واحد که معمولاً توسط یک ارائه‌دهنده خدمات اینترنتی اختصاص یافته را به اشتراک بگذارند.

PAT چگونه بین دستگاه‌های داخلی تشخیص می‌دهد:

دستگاه داخلی A: 192.168.1.11:52001 → 203.0.113.5:40001
دستگاه داخلی B: 192.168.1.12:52001 → 203.0.113.5:40002

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

تأیید ترجمه‌های فعال NAT

Router# show ip nat translations

Pro  Inside global      Inside local       Outside local      Outside global
tcp  203.0.113.5:40001  192.168.1.11:52001 93.184.216.34:443  93.184.216.34:443
tcp  203.0.113.5:40002  192.168.1.12:52001 93.184.216.34:443  93.184.216.34:443

Router# show ip nat statistics
Total active translations: 2 (0 static, 2 dynamic; 2 extended)

خروجی چهار-ستونی show ip nat translations اصطلاحات خود NAT را منعکس می‌کند: Inside Local آدرس خصوصی اصلی است، Inside Global آدرس عمومی ترجمه‌شده است، و ستون‌های outside آدرس‌های متناظر برای مقصد خارجی را نشان می‌دهند — این جدول ابزار اصلی برای تأیید اینکه دقیقاً یک قطعه خاص از ترافیک ترجمه‌شده واقعاً متعلق به کدام دستگاه داخلی است.

یک الگوی رایج عیب‌یابی: تعیین inside/outside گم‌شده

-- علامت: قوانین NAT به‌درستی پیکربندی شده‌اند،
-- اما ترجمه صرفاً هرگز رخ نمی‌دهد

-- علت رایج: یک اینترفیس هرگز با
-- "ip nat inside" یا "ip nat outside" علامت‌گذاری نشده

Router# show ip interface gigabitethernet 0/1 | include NAT
  NAT: not enabled  ← این اینترفیس تعیینش گم شده

فراموش‌کردن اعمال ip nat inside یا ip nat outside روی اینترفیس‌های مرتبط یکی از رایج‌ترین پیکربندی‌های نادرست NAT است — خود قوانین ترجمه می‌توانند کاملاً درست باشند، اما هیچ اتفاقی نمی‌افتد چون روتر نمی‌داند کدام اینترفیس‌ها نمایانگر سمت‌های خصوصی و عمومی مرز ترجمه هستند.

چرا NAT با وجود IPv6 مرتبط باقی می‌ماند

حتی همان‌طور که اتخاذ IPv6، که بعداً در این مجموعه پوشش داده می‌شود، به‌تدریج فشاری که در ابتدا ایجاد NAT را انگیزه داد کاهش می‌دهد، NAT در شبکه‌های IPv4 به‌شدت رایج باقی می‌ماند و به هدف ثانویه‌ای فراتر از حفظ آدرس ادامه می‌دهد: از آنجا که آدرس‌های خصوصی داخلی هرگز مستقیماً در معرض اینترنت قرار نمی‌گیرند، NAT درجه‌ای از امنیت-از‌طریق-ابهام فراهم می‌کند، و ساختار شبکه داخلی را برای ناظران خارجی نامرئی می‌کند. درک هر سه نوع NAT، و توانایی شناسایی سریع یک تعیین inside/outside گم‌شده به‌عنوان یک علت رایج شکست ترجمه، یک مهارت عملی ضروری در تقریباً هر استقرار شبکه دنیای واقعی باقی می‌ماند.

Written & researched by Dr. Shahin Siami

Related Articles

عیب‌یابی سیستماتیک شبکه: یک روش‌شناسی که همه‌چیز را به هم پیوند می‌دهد

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های OSI ارائه می‌دهد، اعمالش روی یک مسئله اتصال واقع‌بینانه را مرور می‌کند، و نشان می‌دهد دستورات تأیید خاصی که در سراسر این کل مجموعه پوشش داده شدند چگونه در یک فرآیند تشخیصی ساختاریافته جا می‌گیرند.

Continue

NETCONF، YANG، و پایتون: پیکربندی برنامه‌ای شبکه در مقیاس

REST API ها و فرمت‌های JSON/YAML که پیش‌تر در این مجموعه پوشش داده شدند یک رویکرد به اتوماسیون شبکه را نشان می‌دهند، اما NETCONF و YANG یک جایگزین ساختاریافته‌تر و مبتنی‌بر-استاندارد فراهم می‌کنند که به‌طور خاص برای پیکربندی دستگاه شبکه ساخته شده. این مقاله توضیح می‌دهد چه چیزی NETCONF را از یک REST API ساده متمایز می‌کند، اینکه مدل‌های YANG چگونه دقیقاً تعریف می‌کنند داده پیکربندی چگونه به‌نظر می‌رسد را پوشش می‌دهد، و استفاده از پایتون برای تعامل برنامه‌ای با دستگاه‌های شبکه را مرور می‌کند.

Continue

اصول IPsec VPN: امن‌سازی ترافیک در سراسر شبکه‌های نامورد‌اعتماد

اتصال دو سایت در سراسر اینترنت عمومی ترافیک را در معرض رهگیری قرار می‌دهد مگر اینکه به‌درستی رمزگذاری شود، و IPsec چارچوب استانداردی برای ساخت تونل‌های امن و احراز‌هویت‌شده بین سایت‌ها فراهم می‌کند. این مقاله فرآیند مذاکره دومرحله‌ای IKE را توضیح می‌دهد، تمایز بین پروتکل‌های AH و ESP را پوشش می‌دهد، پیکربندی یک VPN سایت-به-سایت پایه IPsec را مرور می‌کند، و دستورات تأیید ضروری را پوشش می‌دهد.

Continue

اصول MPLS: توضیح سوئیچینگ برچسب

مسیریابی IP سنتی نیازمند این است که هر روتر در طول یک مسیر یک جستجوی کامل جدول مسیریابی روی هر بسته انجام دهد، اما MPLS رویکردی اساساً متفاوت را با گرفتن آن تصمیم فوروارد‌کردن یک‌بار و متصل‌کردن یک برچسب ساده که هر روتر بعدی می‌تواند به‌جای آن استفاده کند اتخاذ می‌کند. این مقاله مفهوم اصلی سوئیچینگ-برچسب را توضیح می‌دهد، اینکه پروتکل توزیع برچسب چگونه جداول فوروارد‌کردن برچسبی که این را ممکن می‌کنند می‌سازد را مرور می‌کند، و بهره‌های عملی‌ای که MPLS در شبکه‌های ارائه‌دهنده واقعی فراهم می‌کند را پوشش می‌دهد.

Continue

Route Reflector و Confederation های BGP: مقیاس‌دهی iBGP فراتر از Full Mesh

نیازمندی full-mesh iBGP، که به‌طور مختصر پیش‌تر در این مجموعه ذکر شد، با رشد یک سیستم خودمختار به یک مسئله جدی مقیاس‌دهی تبدیل می‌شود، که نیازمند تعدادی جلسه است که به‌طور درجه‌دوم با تعداد روتر افزایش می‌یابد. این مقاله دقیقاً توضیح می‌دهد چرا full mesh مقیاس‌پذیر نیست، اینکه route reflector ها چگونه این را با شل‌کردن قوانین معمول انتشار-مسیر BGP حل می‌کنند مرور می‌کند، و confederation ها را به‌عنوان یک رویکرد جایگزین که یک AS واحد را به سیستم‌های خودمختار زیرمجموعه کوچک‌تر تقسیم می‌کند پوشش می‌دهد.

Continue

بررسی عمیق انواع ناحیه OSPF: Stub، Totally Stubby، و NSSA

طراحی OSPF چندناحیه‌ای پایه، که پیش‌تر در این مجموعه پوشش داده شد، از قبل اندازه پایگاه‌داده را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان کاهش می‌دهد، اما انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند. این مقاله انواع LSA که باید برای ساخت هر نوع ناحیه تخصصی سرکوب شوند را توضیح می‌دهد، پیکربندی نواحی stub، totally stubby، و not-so-stubby را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

Continue