خلاصه خبر
NAT روی DRG قابلیت تازهٔ شبکهٔ Oracle Cloud Infrastructure است که اوراکل در یادداشت انتشار ۱ اکتبر ۲۰۲۶ برای آدرس‌های IPv4 معرفی کرده است. این قابلیت به مدیر شبکه اجازه می‌دهد سیاست ترجمه را مستقیماً روی اتصال DRG تنظیم کند و برای source NAT، destination NAT یا هر دو، ترجمهٔ یک‌به‌یک آدرس را به کار بگیرد.
اهمیت این خبر برای تیم‌های زیرساخت در سناریوهایی است که چند شبکهٔ خصوصی، منطقهٔ ابری یا محیط بیرونی از محدوده‌های IP هم‌پوشان استفاده می‌کنند. در چنین وضعیتی، NAT روی DRG می‌تواند بخشی از پیچیدگی طراحی اتصال را کاهش دهد؛ البته فعال‌کردن آن بدون طراحی دقیق route و کنترل امنیتی، مشکل را فقط به لایه‌ای دیگر منتقل می‌کند.
NAT روی DRG دقیقاً چه چیزی را تغییر می‌دهد؟
Dynamic Routing Gateway نقطهٔ اتصال شبکه‌های VCN، مناطق OCI و شبکه‌های بیرونی مانند دیتاسنتر یا محیط چندابری است. پیش از این، تیم‌ها برای ترجمهٔ آدرس در چنین مسیرهایی معمولاً به معماری‌های جداگانه، تجهیزات میانی یا تغییرات پیچیده در شبکهٔ مبدأ و مقصد نیاز داشتند. قابلیت جدید، سیاست NAT را به attachment مربوط به DRG نزدیک‌تر می‌کند.
در NAT روی DRG، ترجمه می‌تواند یک‌به‌یک و برای IPv4 انجام شود. بنابراین یک محدودهٔ خصوصی که در دو محیط تکرار شده است، می‌تواند در زمان عبور از مرز اتصال با محدوده‌ای قابل‌تفکیک نمایش داده شود. این الگو برای اتصال VCNهای دارای آدرس‌های تکراری، ارتباط میان regionها و پیوند OCI با شبکه‌های بیرونی کاربرد دارد.
تفاوت source NAT و destination NAT
Source NAT مبدأ بسته را هنگام خروج از یک محدوده تغییر می‌دهد. این روش زمانی مفید است که مقصد باید ترافیک را از یک فضای آدرس مشخص و قابل‌اعتماد ببیند یا پاسخ‌ها را به یک محدودهٔ ترجمه‌شده برگرداند. در مقابل، destination NAT آدرس مقصد را برای رسیدن بسته به سرویس یا شبکهٔ موردنظر تغییر می‌دهد.
در بعضی معماری‌ها فقط یکی از این دو نوع ترجمه لازم است، اما برای سناریوهای پیچیده‌تر ممکن است هر دو سیاست روی یک مسیر مورد نیاز باشد. انتخاب بین آن‌ها باید بر اساس جهت ترافیک، محل اعمال route، نیاز سرویس به مشاهدهٔ آدرس واقعی و سیاست ثبت لاگ انجام شود؛ نه صرفاً بر اساس اینکه کدام گزینه در کنسول ساده‌تر به نظر می‌رسد.
چه مسئله‌هایی با این قابلیت حل می‌شود؟
مهم‌ترین کاربرد NAT روی DRG، اتصال شبکه‌هایی با فضای IP هم‌پوشان است. فرض کنید دو VCN در پروژه‌های جداگانه هر دو از محدودهٔ ۱۰.۲۰.۰.۰/۱۶ استفاده می‌کنند و باید از طریق DRG با یکدیگر ارتباط داشته باشند. بدون ترجمه، routeها نمی‌توانند مقصد واقعی را به‌صورت یکتا تشخیص دهند. یک سیاست ترجمهٔ یک‌به‌یک می‌تواند یکی از این فضاها را در سمت مقابل با محدوده‌ای دیگر نمایش دهد.
این قابلیت همچنین در مهاجرت تدریجی، اتصال چند region، ادغام شبکه‌های سازمانی و ارتباط OCI با دیتاسنترهایی که امکان تغییر سریع آدرس‌دهی ندارند، ارزشمند است. با این حال، NAT جایگزین طراحی درست آدرس‌دهی نیست. اگر پروژه‌ای هنوز در مرحلهٔ طراحی است، استفاده از محدوده‌های غیرهم‌پوشان معمولاً ساده‌تر، شفاف‌تر و کم‌هزینه‌تر از افزودن ترجمه خواهد بود.
چک‌لیست امن پیش از فعال‌سازی
پیش از استفاده از NAT روی DRG، ابتدا مسیر رفت و برگشت را روی کاغذ و محیط آزمایشی مدل کنید. جدول‌های route در VCN، DRG و شبکهٔ بیرونی باید با آدرس‌های قبل و بعد از ترجمه سازگار باشند. سپس مشخص کنید کدام سمت باید آدرس واقعی را در لاگ ببیند و کدام سمت فقط آدرس ترجمه‌شده را دریافت می‌کند.
در مرحلهٔ بعد، دامنهٔ ترجمه، ترتیب ruleها، تداخل احتمالی با security list و NSG و رفتار health checkها را بررسی کنید. اگر سرویس به allowlist وابسته است، آدرس مشاهده‌شده پس از NAT باید در تمام کنترل‌های دسترسی ثبت شود. لاگ‌گیری را پیش از rollout فعال کنید تا خطاهای route، timeout و برگشت ترافیک قابل تفکیک باشند.
برای تیم‌های عملیاتی، NAT روی DRG زمانی ارزشمند است که نتیجهٔ آن با مانیتورینگ و فرایند پاسخ‌گویی به رخداد قابل مشاهده باشد. نام‌گذاری ruleها، ثبت مالک هر attachment و مستندسازی آدرس قبل و بعد از ترجمه، عیب‌یابی آینده را بسیار سریع‌تر می‌کند.
بهتر است ابتدا یک attachment آزمایشی یا یک مسیر محدود را انتخاب کنید، چند سناریوی اتصال را با ترافیک واقعی اما کم‌خطر بسنجید و سپس به‌تدریج دامنهٔ ترجمه را افزایش دهید. برای تصمیم‌های بیشتر دربارهٔ شبکه و کلاد، مطالب تکتاز مگ را دنبال کنید.
جمع‌بندی
ارائهٔ NAT برای Dynamic Routing Gateway، ابزار تازه‌ای برای حل سناریوهای IPv4 هم‌پوشان در OCI است. NAT روی DRG می‌تواند source NAT، destination NAT یا ترکیب هر دو را روی attachmentهای DRG در اختیار مدیران بگذارد و اتصال VCNها، regionها و مکان‌های بیرونی را انعطاف‌پذیرتر کند.
با این حال، نتیجهٔ خوب به route table دقیق، ثبت لاگ، کنترل امنیتی و آزمایش مرحله‌ای وابسته است. این قابلیت برای ساده‌کردن مسیرهای موجود مفید است، اما نباید بهانه‌ای برای نادیده‌گرفتن برنامهٔ صحیح آدرس‌دهی باشد. جزئیات رسمی قابلیت در یادداشت انتشار Oracle Cloud Infrastructure آمده است.
