عنوانا VPN محليان: نظيران في Azure، لا نظير واحد

يحتوي المخطط على رابطي إنترنت عند الفرع وبوابة VPN واحدة في Azure، لذلك تحصل بوابة الشبكة المحلية على العنوانين العامين. يبدو الأمر مرتباً، لكنه لا يعمل بالطريقة التي يوحي بها المخطط. كل جهاز VPN محلي هو علاقة نظير مستقلة، ويخصص تصميم Microsoft متعدد الأجهزة لكل جهاز مورد بوابة شبكة محلية خاصاً به واتصالاً خاصاً به. إضافة عنوان ثانٍ إلى مورد واحد لا تنشئ نظيراً ثانياً. بل تنشئ مورداً لا يصف أيّاً من الجهازين وصفاً صحيحاً.

الأسطورة: بوابة واحدة وعنوانان

بوابة الشبكة المحلية هي وصف لنظير بعيد: نقطة نهاية عامة واحدة والبادئات الخاصة التي تقف خلفها. لا توجد طريقة مدعومة لجعل ذلك المورد يعني «أي هذين الجهازين».

ينتشر الارتباك نفسه في الاتجاه الآخر، حيث يُقرأ عنوانا IP عامان في Azure كدليل على وجود بوابتين في Azure.

احسب الكائنات، ثم احسب الأنفاق

خذ جهازين محليين يُشغَّلان بشكل مستقل، لكل منهما عنوانه العام ووصوله إلى الشبكات الخاصة نفسها، مع بوابة Azure واحدة قائمة على التوجيه في وضع النشاط النشط. لبوابة Azure نسختان نشطتان بعنواني IP عامين منفصلين. يتصل كل جهاز محلي بكلا النسختين. هذا هو الشبكة الكاملة، ويُشتق عدد الكائنات منها لا من المخطط.

الحساب قصير بما يكفي للصقه في وثيقة التصميم:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

يمكن لمورد اتصال واحد أن يحمل أكثر من نفق أساسي، لذا لا تعني أربعة أنفاق أربع بوابات شبكة افتراضية. كما أن عنواني IP عامين في Azure ليسا الكائنين نفسهما اللذين تمثلهما بوابتا الشبكة المحلية اللتان تصفان الموقع البعيد.

ما يضيفه وضع النشاط النشط على جانب Azure

يحوّل وضع النشاط النشط بوابة Azure من نسخة نشطة واحدة إلى نسختين، لكل منهما عنوان IP عام خاص بها، وهو ما يجعل الشبكة الكاملة ممكنة أصلاً. ولا يضاعف معدل نقل تدفق واحد. كما لا يزيل الحاجة إلى دعم جانب الموقع المحلي لتعدد المسارات متساوي التكلفة إذا كان الجهازان يمرران في الوقت نفسه. تحقق من وضع البوابة وفئة SKU وقدرة الجهاز البعيد قبل توفير أي شيء.

بوابة بوضع الاستعداد السلبي تصميم صالح تماماً؛ لكنها تنتج عدداً مختلفاً من الأنفاق.

يجعل BGP المسارين قابلين للاستخدام

في التصميم متعدد الأجهزة، يشغّل كلا الجهازين المحليين BGP. أعطِ كل واحد عنوان نظير BGP فريداً وأعلن البادئات الخاصة المقصودة نفسها عبر المسارات ذات الصلة. تحدد البادئات الخاصة الشبكات المحمية، بينما تحدد العناوين العامة أين تنتهي اتصالات الناقل المشفرة. الخلط بين الاثنين ينتج تصميماً يكون فيه كل نفق قائماً والمسارات خاطئة.

خطّط لتوجيه العودة ولأي فحص للحالة يجب أن يتحمل أي المسارين. جلسة IKE سليمة على كل نقطة نهاية لا تثبت أن حمولة عمل ما يمكنها استخدام كل مسار معلن.

الاختيار القائم على التدفق ليس تجميعاً للنطاق الترددي

تختار Azure مساراً لكل تدفق باستخدام تجزئة على عناوين التدفق ومنافذه. في الحالة المستقرة، تسلك حزم تدفق TCP أو UDP معين عادةً النفق نفسه، وقد يختار الجانب المحلي نفقاً مختلفاً لاتجاه العودة. لذا يحسّن جهازان وأربعة أنفاق التوافر، لا سرعة نقل واحد. عندما يعد شريحة عرض من مورّد بالتجميع، فإنه يصف ميزة مختلفة أو سوء فهم.

اختبر بتدفقات متوازية إذا أردت مشاهدة انتشار المسارات، وبتبدق واحد إذا أردت رؤية الحد.

ما التكرار الذي أزلته فعلاً

عنوانا WAN على جهاز واحد يحسّنان خيارات رابط الوصول مع تقاسم طاقة ذلك الجهاز وبرمجياته وحالته عند الفشل. وهما ليسا مثل جهازين، ولا تغيّر أي كمية من إعداد جانب Azure ذلك. اتبع تصميم الجهاز المدعوم ثنائي WAN أو تصميم العنقود من المورّد بدلاً من استنتاج التكرار من عدد العناوين. ثم اختبره: أزل مساراً واحداً في كل مرة وأكد المسارات المتبقية وتبادلاً حقيقياً للتطبيق في الاتجاهين.

توقّع تأخيرات في الاكتشاف والتقارب، وتوقّع انتهاء بعض الجلسات القائمة.