Anypoint VPN یا NAT در Transit Gateway: ترجمه کجا انجام می‌شود
Anypoint VPN خودش نشانی‌ها را ترجمه نمی‌کند. پیش از وعده دادن NAT، بین طراحی PAT روی فایروال، نقشه پیشوندهای AWS یا اتصال دیگر تصمیم بگیرید.
یک نیاز NAT تا زمانی که نشانی‌هایی که تغییر می‌کنند و مؤلفه‌ای که اجازه تغییر آن‌ها را دارد نام نبرد، نیاز نیست. در اتصال MuleSoft این تصمیم سه ورودی دارد: اینکه backend به ترجمه پورت چندبه‌یک نیاز دارد یا به نام مستعار پیشوند یک‌به‌یک، اینکه اتصال AWS که واقعاً در اختیار دارید می‌تواند این نگاشت را انجام دهد یا نه، و اینکه کل مسیر در ترکیبی می‌ماند که فروشنده پشتیبانی می‌کند یا نه. اگر این‌ها را اشتباه بگیرید، آزمایشگاهی می‌سازید که کار می‌کند اما در بازبینی رد می‌شود.
تنها نکته ثابت این است که خود Anypoint VPN دستگاه ترجمه نیست. مستندات CloudHub 2.0 در آنجا NAT را پشتیبانی‌نشده فهرست می‌کند، پس هر طراحی که فرض کند تونل نشانی‌های کارگران شما را پنهان می‌کند، از پیش خراب است.
مشخص کنید ترجمه چه کاری باید انجام دهد
اگر بسیاری از کارگران برنامه باید در برابر backend به‌صورت یک نشانی واحد دیده شوند، نیاز عبارت است از ترجمه مبدأ مشترک، معمولاً SNAT یا PAT حالت‌دار روی فایروالی که خودتان کنترل می‌کنید. این عنصر باید روی مسیری تأییدشده بنشیند، حالت خود را در تمام عمر جریان نگه دارد و ترافیک بازگشتی هر اتصالی را که بازنویسی کرده ببیند. از دست رفتن حالت در میانه نشست اتصال را ضعیف نمی‌کند؛ آن را پایان می‌دهد. جفتی از فایروال‌ها که از به اشتراک گذاشتن حالت ترجمه خودداری کند، هر نشستی را که پس از جابه‌جایی روی عضو آماده بیفتد رها می‌کند. این عنصر را برای جریان‌های هم‌زمان اندازه بگیرید، نه برای توان عبوری.
اگر در عوض دو شبکه هم‌پوشانی داشته باشند و هر میزبان به نام مستعار متمایز نیاز داشته باشد، نیاز عبارت است از طرح نشانی یک‌به‌یک با پیشوندهای نگاشت‌شده بی‌ابهام، مسیرهای منطبق و تفکیک نامی که با نگاشت هم‌خوان باشد. پنهان کردن هر کارگر پشت یک نشانی نسخه ارزان‌تر آن نیست، و جایگزین کردن یکی با دیگری در بازبینی طراحی همان چیزی است که پروژه‌ها را یک فصل عقب می‌اندازد.
پیش از انتخاب محصول، تصمیم را با عبارات مشخص ثبت کنید: مبدأ اولیه، مقصد اولیه، مقدار ترجمه‌شده، جهت آغاز، مالک مترجم و مسیر پاسخ مورد انتظار. این را هم اضافه کنید که گزارش‌های backend چه هویتی را نگه می‌دارند، زیرا طراحی‌ای که همه مبدأها را پنهان می‌کند ممیزی به‌ازای هر مشتری را هم نابود می‌کند.
بررسی کنید آیا AWS می‌تواند نگاشت را برای شما انجام دهد
AWS اکنون NAT مدیریت‌شده یک‌به‌یک را روی اتصال‌های Transit Gateway و Cloud WAN مستند می‌کند که در اواخر اکتبر 2026 اعلام شد، پس ادعای کلی قدیمی که دروازه ترانزیت هرگز نمی‌تواند ترجمه کند دیگر کهنه است. مستندات Transit Gateway NAT نگاشت پیشوند IPv4 بدون حالت را توصیف می‌کند: پیشوندهای اولیه و ترجمه‌شده طول یکسان را حفظ می‌کنند و بیت‌های میزبان و پورت‌های انتقال از ترجمه جان سالم به در می‌برند. جهت‌های ورود و خروج را دو تصمیم طراحی جداگانه بخوانید، زیرا جداگانه پیکربندی می‌شوند و ممکن است یکی آماده باشد و دیگری نه. هیچ چیز در آن توصیف به حالت به‌ازای هر جریان اشاره ندارد، پس انتظار نداشته باشید نگاشت اتصال‌ها را به‌جای شما دنبال کند.
این یعنی نگاشت 10.80.0.0/16 به 172.28.0.0/16 نشانی 10.80.10.23 را به 172.28.10.23 تبدیل می‌کند. این کار /16 را در یک نشانی فرو نمی‌ریزد و جای نیاز PAT را نمی‌گیرد. انواع اتصال گزیده را هم پوشش می‌دهد، از جمله VPC و Site-to-Site VPN، اما نه اتصال‌های Client VPN، و پیکربندی نزد مالک دروازه ترانزیت است نه سمت Anypoint.
این قابلیت را یک نقطه کنترل ممکن دیگر بدانید، نه شاهدی بر اینکه استقرار شما می‌تواند از آن استفاده کند. CloudHub 2.0 اتصال‌های فضای خصوصی به دروازه ترانزیت را در حساب AWS خود مشتری مستند می‌کند، همراه با شرایط منطقه‌ای و شرایط استحقاق، پس پیش از طراحی حول گزینه جدید، نوع واقعی اتصال، مالک آن و موضع پشتیبانی فروشنده را تأیید کنید.
مسیر را درون مرز پشتیبانی‌شده نگه دارید
برای مترجم فایروال، از مدل پشتیبانی‌شده VPN، ترجمه و مسیریابی همان محصول استفاده کنید، نه اینکه یک قاعده عمومی NAT را در تونلی کارآمد بچسبانید. پاسخ backend باید از همان عنصر ترجمه بازگردد، و تونل خروجی سالم هیچ چیزی درباره آن مسیر بازگشت نمی‌گوید.
برای مسیر دروازه ترانزیت، اتصال فضای خصوصی، جدول‌های مسیر مرتبط، اتصال درون‌سایتی و قطعه‌هایی را که مشتری واقعاً می‌تواند پیکربندی کند فهرست کنید. این معماری اتصال متفاوتی است، نه یک تیک NAT پیچ‌شده به اتصال موجود Anypoint VPN، و مرز پشتیبانی همراه آن جابه‌جا می‌شود.
سه گزینه را در یک جدول مقایسه کنید
بیشتر تیم‌ها فقط باید به دو پرسش پاسخ دهند: چندبه‌یک یا یک‌به‌یک، و اینکه اتصال مال کیست. جدول زیر آن پاسخ‌ها را به گزینه آغازین تبدیل می‌کند.
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
ستون سوم را به‌عنوان پرسش بازبینی بخوانید، نه اندیشه‌ای پس از کار. نقشه پیشوندی که روی کاغذ مجاز است اما روی اتصالی پیکربندی شده که مالکش نیستید، هنوز پروژه‌ای متوقف است، و قاعده PAT که ترافیک را عبور می‌دهد اما ثبت به‌ازای هر مشتری را می‌شکند در ممیزی بعدی رد می‌شود.
پیش از وعده دادن، نگاشت را اعتبارسنجی کنید
یک عملیات تازه برنامه را از مسیر عبور دهید و پاسخ را تأیید کنید، نه فقط درخواست را. از مالک backend بپرسید گزارش‌هایشان کدام نشانی مبدأ را ثبت کرده‌اند، بررسی کنید که رفتار خانواده نشانی در هر دو جهت با طرح بخواند، و تأیید کنید مسیری که باید رد شود هنوز رد می‌شود. یک اتصال کهنه درباره نگاشتی که همین حالا تغییر داده‌اید هیچ چیزی را اثبات نمی‌کند.
احراز هویت backend را مستقل از اینکه کدام نشانی ترجمه‌شده فهرست مجاز آن را برآورده می‌کند نگه دارید، زیرا نگاشت لوله‌کشی شبکه است نه تصمیم کنترل دسترسی. همان لحظه‌ای که بازنشانی گذرواژه به یک پیشوند NAT وابسته شود، هر تغییر محدوده در آینده به قطعی سرویس تبدیل می‌شود.
پیش از تأیید نهایی، سه پاسخ را بنویسید: نوع ترجمه، مالک مترجم، و اتصال یا مسیر محصول پشتیبانی‌شده‌ای که آن را حمل می‌کند. اگر هر یک از آن‌ها هنوز حدس است، طراحی برای پنجره تغییر آماده نیست.