Architecture-center: توضيح استخدام "السماح بحركة المرور المعاد توجيهها"

مرحبًا jtuliani شكرًا لك على الإبلاغ عن هذه المشكلة! سنراجع ونجري أي تغييرات ضرورية.

+1 ، أود أن أضيف أيضًا أنه يجب أن نلاحظ أنه عند تمكين حركة المرور المعاد توجيهها على شبكة VNet ، يحتاج المستخدمون إلى مراعاة أن بطاقات NIC في Azure تحتاج أيضًا إلى تمكين إعادة التوجيه (يمكننا ببساطة الارتباط هنا ).

لقد أمضيت الكثير من الوقت في محاولة لمعرفة سبب عدم تمكن أجهزة Linux VM الخاصة بي من الوصول إلى بعضها البعض في شبكات VNets المتسلسلة باتباع هذا الدليل حتى أدركت أن هناك إعدادًا إضافيًا على بطاقات NIC لتمكينها أيضًا.

شكرًا جزيلاً لك - تم نقل هذا العنصر إلى العمل المتراكم الداخلي لدينا لتحسين التوثيق.

@ doodlemania2 ما زالت الوثائق تنص على أن "السماح بحركة المرور المعاد توجيهها" مطلوب. إذا حكمنا من خلال اختبار jtuliani ، فلا ينبغي ، ويجب تغيير الوثائق.

هنا أجبت أنه مطلوب:
https://github.com/MicrosoftDocs/architecture-center/issues/1544#issuecomment -506504344

هذا سؤال عظيم! نقوم بذلك حتى يتمكن الأقران من التحدث مع بعضهم البعض عن طريق التوجيه عبر المحور. بدونها ، ستسقط الحزم أثناء محاولتها الخروج من السماعة الموجهة للمحور والعكس صحيح. أخبرنا إذا كان هذا لا يزال لا يفسرها جيدًا ويمكننا النظر في إعادة الصياغة!

هل هو في الواقع مطلوب وكان اختباره غير صحيح إلى حد ما؟ أو الوثائق بحاجة إلى تحديث؟

يمكنك أيضًا تكوين مكبرات الصوت لاستخدام بوابة المحور للتواصل مع الشبكات البعيدة. للسماح بحركة مرور البوابة بالتدفق من مكبر الصوت إلى المحور ، والاتصال بالشبكات البعيدة ، يجب عليك:

• قم بتكوين اتصال التناظر في المحور للسماح بعبور البوابة .
• قم بتكوين اتصال النظير في كل تحدث لاستخدام بوابات بعيدة .
• قم بتكوين جميع اتصالات النظراء للسماح بحركة المرور المعاد توجيهها .

أقترح أيضًا ألا نغلق المشكلة هنا حتى يتم ذلك. العملية الداخلية لا تهم المجتمع ، وإلا فإننا نواجه مواقف مثل هذه.

شكرًا لمشاركة هذه التعليقات jtuliani و evandropomatti ، نحن حقًا نقدر هذا 😸

أعتقد أن هذا يشير إلى قسم التناظر الشبكي الافتراضي تحت التوصيات حيث بناءً على فهمي ، تتم مناقشة سيناريوهين مختلفين.

السيناريو أ

إذا كنت بحاجة إلى مكبرات صوت للاتصال ببعضها البعض دون التحديق بها.

بالنسبة لسيناريو الحالة هذا ، يرجى السماح لنا بمشاركة ما يلي من إنشاء مستندات

_ "إذا لم يتم تحديد مربع الاختيار هذا للتناظر بين كل شبكة افتراضية متحدثة والشبكة الافتراضية للمحور ، فلن تتدفق حركة المرور بين الشبكات الافتراضية التي تم التحدث بها لأن المحور لا يقوم بإعادة توجيه حركة المرور بين الشبكات الافتراضية." _

بالإضافة إلى ذلك،

_ "لست بحاجة إلى التحقق من هذا الإعداد إذا تمت إعادة توجيه حركة المرور بين الشبكات الافتراضية من خلال Azure VPN Gateway." _

السيناريو ب

قم بتكوين المتحدث لاستخدام بوابة المحور للتواصل مع الشبكات البعيدة. لهذا التكوين الخاص جدًا ، لا يلزم السماح بحركة المرور المعاد توجيهها .

ومع ذلك ، يرجى السماح لنا بإعادة فتح هذه المشكلة لأنني أوافق أثناء قراءة المستندات على أن هذه فكرة جيدة للتمييز هنا.

كجزء من هذه المراجعة ، يُرجى دعنا نفكر أيضًا في الإشارة إلى أي عمليات التحقق هذه مطلوبة حقًا (على سبيل المثال ، السيناريو B ، [x] Use remote gateways مطلوب من نظير محور الكلام ، بينما [x] Allow gateway transit مطلوب من المركز -spoke peering ، و [] Allow forwarded traffic يمكن أن يظل غير محدد لكليهما) بشرط أن يكون هذا هو تفضيل المؤلف. قد يكون عرض جنبًا إلى جنب لهذا مثاليًا.

فقط في الختام وبكل إنصاف ، سيعمل التكوين الحالي جيدًا لكلا السيناريوهين A + B ، لذلك لا يتعارض كل منهما مع الآخر. بالنظر إلى ذلك ، من أجل البساطة ، قد نرغب في الاحتفاظ بـ ARM (s) كما هو في الوقت الحالي.

ferantivero أعتقد أنك