NAT و Port Forwarding چیست و چه زمانی به آن‌ها نیاز داریم؟

دو کامپیوتر با IP خصوصی متفاوت ممکن است از یک روتر به اینترنت بروند. روتر در روش PAT، برای جریان‌های ارتباطی نگاشت نگه می‌دارد تا پاسخ برگشتی را به دستگاه درست برساند. NAT پایه فقط آدرس را ترجمه می‌کند؛ در NAPT یا PAT، شماره پورت هم می‌تواند در ترجمه دخیل باشد.

عددهای پورت این جدول انتخاب آموزشی‌اند؛ روتر واقعی الزاماً این عددها را انتخاب نمی‌کند یا در همه ارتباط‌ها پورت را تغییر نمی‌دهد. اطلاعات پروتکل و دو سر جریان در مدیریت نگاشت اهمیت دارند. برای مفهوم پورت، تفاوت TCP، UDP و پورت را ببینید.

پاسخ سایت به درخواست مرورگر، ادامه همان ارتباط خروجی است و در روتر معمولِ درست تنظیم‌شده به Port Forwarding دستی برای هر کاربر نیاز ندارد. بنابراین مشاهده یک IP عمومی مشترک برای چند کامپیوتر، به معنی تداخل IP داخلی آن‌ها نیست.

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

در یک نمونه مفهومی، نگاشت TCP روی پورت بیرونی 8443 به سرویس وب آزمایشی 192.168.10.50 روی پورت 443 اشاره می‌کند. پورت بیرونی و داخلی می‌توانند متفاوت باشند. این توصیف فقط اجزای نگاشت را نشان می‌دهد؛ دستور ایجاد قانون یا توصیه انتشار پنل مدیریتی نیست.

در Port Forwarding ساده، یک ترکیب معین از آدرس مقصد بیرونی، پروتکل و پورت، برای شرایط یکسان به یک مقصد داخلی مشخص می‌رود. برای چند سرویس یا چند میزبان، طراحی باید نگاشت‌ها را از هم متمایز کند یا از درگاه متناسب استفاده کند؛ دو قانون متعارض راه تقسیم خودکار یک اتصال نیستند.

مسیریابی مسیر رسیدن بسته را مشخص می‌کند؛ NAT آدرس و در موارد لازم پورت را ترجمه می‌کند؛ فایروال درباره اجازه عبور ترافیک تصمیم می‌گیرد. ممکن است رابط یک روتر هنگام ساخت Port Forwarding چند تنظیم را با هم ایجاد کند، اما این نقش‌ها از نظر مفهومی جدا هستند.

در Source NAT یا ترجمه مبدأ، آدرس سمت فرستنده تغییر می‌کند؛ نمونه رایج آن خروج دستگاه‌های داخلی به اینترنت است. در Destination NAT یا ترجمه مقصد، مقصد بسته تغییر می‌کند و Port Forwarding معمولاً از همین منطق استفاده می‌کند.

NAT رمزنگاری یا تأیید هویت کاربر نیست. بسته‌ای که به سرویس رسیده هنوز باید طبق سیاست دسترسی و حساب‌های همان سرویس بررسی شود. برای دورکاری، طراحی دسترسی مدیریت‌شده مهم‌تر از صرفاً ساختن یک نگاشت پورت است.

• ترافیک موردنظر باید از اینترنت و تجهیزات بالادست به نقطه‌ای برسد که نگاشت را انجام می‌دهد؛ سیاست سرویس‌دهنده هم مؤثر است.
• آدرس و پروتکل و پورت نگاشت باید با سرویس واقعی مطابق باشند؛ عوض‌شدن IP داخلی مقصد می‌تواند نگاشت را بی‌اثر کند.
• سرویس باید روی رابط و پورت مناسب آماده دریافت باشد و کنترل‌های شبکه و میزبان اجازه لازم را بدهند.
• پاسخ باید از مسیر سازگار برگردد تا ترجمه معکوس و ادامه ارتباط درست انجام شود.

بنابراین پیام «پورت باز نیست» به‌تنهایی مشخص نمی‌کند ایراد از NAT است، از سرویس خاموش، از سیاست دسترسی یا از مسیر بالادست. همچنین نتیجه اتصال به IP عمومی از داخل همان شبکه ممکن است به قابلیت Hairpin NAT یا طراحی DNS داخلی وابسته باشد؛ آن را معادل آزمون واقعی از بیرون نگیرید.

اگر روتر شرکت پشت مودم یا روتر دیگری باشد که NAT انجام می‌دهد، بیش از یک لایه ترجمه داریم. در CGNAT، ترجمه‌ای هم در شبکه سرویس‌دهنده انجام می‌شود و چند مشترک ممکن است یک IPv4 عمومی را به اشتراک بگذارند. این دو عنوان یکی نیستند؛ وجود روتر بالادست داخل دفتر، به‌تنهایی CGNAT را ثابت نمی‌کند.

قانونی که فقط روی روتر داخلی ساخته شده، کنترل نگاشت بالادست سرویس‌دهنده را به شما نمی‌دهد. برای دسترسی ورودی باید امکان مسیر در کل زنجیره روشن باشد؛ تغییر مکرر پورت داخلی، محدودیت بالادست را برطرف نمی‌کند. راهنمای IP عمومی و CGNAT روش برداشت از آدرس‌ها و گزینه‌های قابل بررسی را توضیح می‌دهد.

خیر. بعضی راهکارها ارتباط را از داخل آغاز می‌کنند و از سرویس واسط یا مسیر مدیریت‌شده استفاده می‌کنند. بعضی دیگر درگاه ورودی مشخصی در شرکت دارند. نیاز به نگاشت، IP عمومی یا سرویس بیرونی باید از معماری همان راهکار مشخص شود.

برای استفاده کارمندان از برنامه و فایل، راهنمای انتخاب روش دورکاری گزینه‌های VPN، دسکتاپ و برنامه راه دور را مقایسه می‌کند. بازکردن مستقیم سرویس‌های مدیریتی، RDP یا پایگاه داده برای همه اینترنت، پیش‌فرض این انتخاب نیست؛ مسیر باید متناسب با کاربران مجاز و نیاز سرویس طراحی شود.

در خدمات دسترسی راه دور شرکت نیاز کاربران، تجهیزات و شرایط ارتباط بررسی می‌شود. هدف، دسترسی قابل استفاده به سرویس موردنیاز است؛ داشتن یک قانون Port Forwarding به‌تنهایی نتیجه نهایی نیست.