Anypoint VPN أم NAT في Transit Gateway: أين تجري الترجمة
لا يترجم Anypoint VPN العناوين بنفسه. احسم الاختيار بين تصميم PAT على جدار الحماية أو خريطة بادئات في AWS أو ارتباط مختلف قبل أن تعِد بـ NAT.
متطلب NAT لا يصبح متطلبًا حتى يحدد العناوين التي تتغير والمكوّن المسموح له بتغييرها. في اتصال MuleSoft لهذا القرار ثلاثة مدخلات: هل يحتاج النظام الخلفي ترجمة منافذ من متعدد إلى واحد أم اسمًا مستعارًا لبادئة واحد إلى واحد، وهل يستطيع ارتباط AWS الذي تملكه فعلًا تنفيذ هذا التعيين، وهل يبقى المسار كله داخل تركيبة يدعمها المورّد. أخطئ في ذلك وستبني مختبرًا يعمل لكنه يفشل في المراجعة.
النقطة الثابتة الوحيدة هي أن Anypoint VPN نفسه ليس جهاز ترجمة. توثيق CloudHub 2.0 يدرج NAT كغير مدعوم هناك، لذا فأي تصميم يفترض أن النفق سيخفي عناوين العاملين لديك هو تصميم معطوب أصلًا.
حدد ما يجب أن تفعله الترجمة
إذا كان على العديد من عاملات التطبيق أن تظهر للنظام الخلفي كعنوان واحد، فالمتطلب ترجمة مصدر مشتركة، عادة SNAT أو PAT مع الحفاظ على الحالة على جدار حماية تديره. يجب أن يجلس هذا العنصر على مسار معتمد، وأن يحفظ حالته طوال عمر التدفق، وأن يرى حركة الرد لكل اتصال أعاد كتابته. فقدان الحالة في منتصف الجلسة لا يضعف الاتصال؛ بل ينهيه. زوج جدران حماية يرفض مشاركة حالة الترجمة سيسقط كل جلسة تهبط على العضو الاحتياطي بعد التحويل. قدّر حجم هذا العنصر بحسب التدفقات المتزامنة لا بحسب معدل النقل.
إن كانت شبكتان متداخلتين وكل مضيف يحتاج اسمًا مستعارًا مميزًا، فالمتطلب خطة عناوين واحد إلى واحد ببادئات معيّنة لا لبس فيها ومسارات مطابقة ودقة أسماء تتفق مع التعيين. إخفاء كل عامل خلف عنوان واحد ليس نسخة أرخص من ذلك، واستبدال أحدهما بالآخر في مراجعة التصميم هو كيف تخسر المشاريع ربعًا كاملًا.
سجّل القرار بمصطلحات ملموسة قبل اختيار المنتج: المصدر الأصلي، والوجهة الأصلية، والقيمة المترجمة، واتجاه البدء، ومالك الترجمة، ومسار الرد المتوقع. أضف الهوية التي ستحتفظ بها سجلات النظام الخلفي، لأن التصميم الذي يخفي كل المصادر يدمّر أيضًا التدقيق لكل عميل.
تحقق مما إذا كان 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 عامة في نفق يعمل. فعلى رد النظام الخلفي أن يعود عبر عنصر الترجمة نفسه، والنفق الصادر السليم لا يقول شيئًا عن مسار العودة ذلك.
وبالنسبة لمسار بوابة العبور، احصر ارتباط المساحة الخاصة وجداول التوجيه المعنية والارتباط المحلي والأجزاء التي يستطيع العميل ضبطها فعلًا. هذه معمارية اتصال مختلفة، وليست مربع اختيار 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 تمرر الحركة لكنها تكسر التسجيل لكل عميل تفشل في التدقيق الذي يتبع.
تحقق من التعيين قبل أن تعِد به
أرسل عملية تطبيق جديدة واحدة عبر المسار وأكّد الرد، لا الطلب فقط. اسأل مالك النظام الخلفي أي عنوان مصدر سجّلته سجلاتهم، وتحقّق من أن معالجة عائلة العناوين تطابق الخطة في الاتجاهين، وتأكد من أن مسارًا واحدًا يجب رفضه ما زال مرفوضًا. فالاتصال القديم لا يثبت شيئًا عن التعيين الذي غيّرته للتو.
أبقِ مصادقة النظام الخلفي مستقلة عن أي عنوان مترجم يرضي قائمة السماح، لأن التعيين سباكة شبكة وليس قرار تحكم بالوصول. في اللحظة التي تعتمد فيها إعادة تعيين كلمة المرور على بادئة NAT، يصبح كل تغيير مستقبلي للنطاق انقطاعًا.
قبل الاعتماد، اكتب الإجابات الثلاث: نوع الترجمة، ومالك الترجمة، والارتباط أو مسار المنتج المدعوم الذي يحملها. وإذا بقي أي منها تخمينًا، فالتصميم غير جاهز لنافذة تغيير.