NAT في Azure VPN لا يحل تداخل عناوين VNet
شبكتان VNet بنطاق خاص واحد لن تتصل لمجرد وجود NAT. افحص نوع الاتصال أولًا، ثم أعد الترقيم أو امتلك اسمًا بديلًا للترجمة.
تستخدم شبكتا VNet النطاق 10.40.1.0/24، وترتفع الأنفاق، ولا يعمل شيء. إضافة بوابة VPN ثانية لا تغيّر ذلك، ولا مقياس المسار الأقل يفعل، لأن المشكلة ليست في اختيار المسار. وجود حملين يستجيبان للعنوان الخاص نفسه يجعل كل حزمة ذات وجهة غامضة ومسار عودة غير قابل للتحقق. قبل التخطيط لأي ترجمة، اكتشف نوع الاتصال الذي أنشأته فعلًا، لأن هذا الخيار الواحد يحدد ما إذا كانت ميزة NAT في Azure متاحة أصلًا.
ما الذي يخبرك به هذا العَرَض فعليًا
عندما يرسل مضيف في VNet A إلى 10.40.1.10، لا يمكن لجدول التوجيه إلا أن يوجّهه إلى مكان ما. وإذا كانت VNet B تحتوي أيضًا على 10.40.1.10، فإن هذا العنوان ليس وجهة يستطيع المسار تمييزها؛ إنه عنوان واحد له مالكين.
البوابة الثانية التي ينشرها الناس عادة لا تساعد. فهي تمنحك نفقًا آخر، لا عنوانًا آخر، والنطاق المكرر ينتقل داخل النفق دون تغيير. كما أنها تضاعف الإعدادات التي عليك إبقاءها متسقة. وما لا تستطيع فعله هو أن تجعل عنوانًا واحدًا يعني مضيفين.
تغيير العناوين العامة لأقران VPN لا يفعل شيئًا أيضًا. فتلك العناوين تحدد طرفي النفق، بينما التصادم في النطاق الخاص المحمول داخله.
نوع الاتصال يحدد ما إذا كان NAT متاحًا
بوابة Azure VPN تملك فعلًا قدرة NAT، وهي موثقة لاتصالات IPsec المستندة إلى المسار بين المواقع وعلى وحدات SKU محددة. وتستثني الوثائق نفسها اتصالات VNet-to-VNet وpoint-to-site، لذا الميزة ليست مربع اختيار يظهر في كل علاقة بوابة.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
يتطلب VNet-to-VNet الأصلي أيضًا ألا تتداخل نطاقات VNet والشبكة المحلية من البداية، وهو ما يتسق مع الاستثناء. واقتران VNet ليس حلًا للتداخل للسبب نفسه.
هناك بديل مدعوم يخلطه الناس بالنوع الأصلي: نمذجة شبكة VNet الأخرى كشبكة محلية وربطها كاتصال من موقع إلى موقع. هذا مورد مختلف وتصميم مختلف، لذا تعامل مع اتصال أُعيد تسميته كتغيير يحتاج إلى تحقق، لا كمجرد إعادة تسمية.
أعد الترقيم، أو ترجم بشيء يملك الاسم البديل
إذا كانت الشبكتان ملكك، فقارن إعادة الترقيم المخططة بالتكلفة المستمرة للترجمة. إعادة الترقيم تمس إعدادات التطبيق وسجلات DNS وقواعد الأمان وكل اتصال قائم، لكنها تترك شبكة تُقرأ بشكل طبيعي بعد ذلك. نفّذها شبكة فرعية واحدة في كل مرة، مع تغيير DNS أخيرًا. النطاق نصف المُرقَّم أسوأ من أي من الخيارين، لأن البادئتين تبدوان بعد ذلك موثوقتين لمن يقرأ الجدول تاليًا.
حيث لا تكون إعادة الترقيم عملية، استخدم تصميمًا مترجمًا بمالك حقيقي للاسم البديل. قد يصل المتصلون في VNet A إلى 10.40.1.10 في VNet B عبر 10.140.1.10، لكن هذا الاسم البديل يحتاج جهازًا يترجم، ومسارًا نحوه، وسلوكًا مطابقًا للرد. العنوان المضاف إلى DNS وحده ليس ترجمة.
سجّل النطاقين في الاتجاهين: ما يطلبه المتصل، وما تراه الوجهة كمصدر، وأي جانب يجوز له البدء. تتضمن قواعد NAT الخاصة بـ Azure الترجمة العكسية لتعيينات SNAT، فلا تكتب قاعدة DNAT مطابقة يدويًا، لكن هذه الراحة تتوقف عند أنواع الاتصال التي تدعمها الميزة.
ما لن يعمل
لا يستطيع مسار يحدده المستخدم ولا مقياس مسار أن يخلق تمييزًا مفقودًا للعناوين. كلاهما يعمل على وجهة ما زالت غامضة، وتصل الحزمة إلى القفزة التالية التي يفضلها الجدول.
إضافة النطاق المكرر إلى جدول توجيه كبادئة أكثر تحديدًا تنقل الغموض خطوة واحدة فقط. كما أنها تميل إلى كسر الاتجاه الآخر، حيث يكون للرد الآن مصدران محتملان.
اقبل التصميم مع حركة في الاتجاهين
أثبت التصميم بعملية مسموحة جديدة من كل جانب، لا بحالة النفق. نفق IPsec المتصل يقول إن الأقران يتفقون على التشفير؛ ولا يقول شيئًا عمّا إذا أصبحت الوجهات قابلة للتمييز.
ثم شغّل المسارات المرفوضة: عنوان يجب أن يبقى غير قابل للوصول، وخدمة يجب أن تحجبها السياسة. إذا نجح كلاهما، فالترجمة أوسع مما قصده التصميم.
اختم بالحقائق التي تشرح الإعداد لاحقًا: النطاق الأصلي، والنطاق المعروض، والجهاز الذي يترجم، والاتجاه الذي يجوز لكل جانب البدء فيه. إذا غاب أي منها، يرث المهندس التالي شبكة يتشارك فيها مضيفان اسمًا ولا يتذكر أحد لماذا يستجيب أحدهما.