حقن المسار الافتراضي في الشبكات الظاهرية المحورية

أحد البنى الأكثر شيوعا في Azure هو تصميم المركز والمحور، حيث ترسل أحمال العمل المنشورة في شبكة ظاهرية محورية (VNet) نسبة استخدام الشبكة من خلال أجهزة الشبكة المشتركة الموجودة في الشبكة الظاهرية المركزية. عادة ما تحتاج المسارات المعرفة من قبل المستخدم (UDR) إلى تكوينها في الشبكات الظاهرية المحورية لتوجيه نسبة استخدام الشبكة نحو أجهزة الأمان في المركز. ومع ذلك، يتطلب هذا التصميم من المسؤولين إدارة هذه المسارات عبر العديد من المحاور.

يوفر Azure Route Server نقطة مركزية حيث يمكن للأجهزة الظاهرية للشبكة (NVAs) الإعلان عن المسارات التي تقوم بإدخالها في الشبكات الظاهرية المحورية. بهذه الطريقة، لا يتعين على المسؤولين إنشاء جداول التوجيه وتحديثها في الشبكات الظاهرية المحورية.

المخطط

يصور الرسم التخطيطي التالي محورا بسيطا وتصميما محوريا مع شبكة ظاهرية مركزية وشبكتين ظاهريتين محوريتين. في المركز، تم نشر جهاز ظاهري للشبكة وخادم توجيه. بدون Route Server، يجب تكوين المسارات المعرفة من قبل المستخدم في كل محور. عادة ما تحتوي UDRs هذه على مسار افتراضي ل 0.0.0.0/0 يرسل كافة نسبة استخدام الشبكة من الشبكات الظاهرية المحورية من خلال NVA. يمكن استخدام هذا السيناريو، على سبيل المثال، لفحص حركة المرور لأغراض أمنية.

مع Route Server في مركز VNet، ليست هناك حاجة لاستخدام المسارات المعرفة من قبل المستخدم. يعلن NVA عن بادئات الشبكة إلى Route Server، الذي يقوم بإدخالها بحيث تظهر في المسارات الفعالة لأي جهاز ظاهري تم نشره في الشبكة الظاهرية المركزية أو الشبكات الظاهرية المحورية التي يتم إقرانها مع الشبكة الظاهرية المركزية مع الإعداد استخدام بوابة الشبكة الظاهرية البعيدة أو Route Server.

الاتصال بالأماكن المحلية من خلال NVA

إذا تم استخدام NVA لتوفير الاتصال بالشبكة المحلية عبر IPsec VPNs أو تقنيات SD-WAN، يمكن استخدام نفس الآلية لجذب نسبة استخدام الشبكة من المحاور إلى NVA. بالإضافة إلى ذلك، يمكن لـ NVA معرفة بادئات Azure ديناميكيًا من Azure Route Server، والإعلان عنها باستخدام بروتوكول توجيه ديناميكي إلى محلي. يصف الرسم التخطيطي التالي هذا الإعداد:

فحص حركة المرور الخاصة من خلال NVA

تصور الأقسام السابقة حركة المرور التي يتم فحصها بواسطة الجهاز الظاهري للشبكة (NVA) عن طريق إدخال 0.0.0.0/0 مسار افتراضي من NVA إلى Route Server. ومع ذلك، إذا كنت ترغب فقط في فحص نسبة استخدام الشبكة من كلام إلى كلام ومن محوري إلى محلي من خلال NVA، يجب مراعاة أن Azure Route Server لا يعلن عن مسار هو نفس البادئة أو أطول من مساحة عنوان الشبكة الظاهرية المستفادة من NVA. بمعنى آخر، لن يقوم Azure Route Server بإدخال هذه البادئات في الشبكة الظاهرية ولن تتم برمجتها على بطاقات NIC للأجهزة الظاهرية في المركز أو الشبكات الظاهرية المحورية.

ومع ذلك، سيعلن Azure Route Server عن شبكة فرعية أكبر من مساحة عنوان VNet التي تم تعلمها من NVA. من الممكن الإعلان من NVA عن شبكة فائقة لما لديك في شبكتك الظاهرية. على سبيل المثال، إذا كانت شبكتك الظاهرية تستخدم مساحة 10.0.0.0/16عنوان RFC 1918 ، فيمكن ل NVA الإعلان إلى 10.0.0.0/8 Azure Route Server وسيتم إدخال هذه البادئات في المركز والشبكات الظاهرية المحورية. تتم الإشارة إلى سلوك VNet هذا في حول BGP مع بوابة VPN.

الاتصال بالأماكن المحلية من خلال بوابات الشبكة الظاهرية

إذا كانت VPN أو بوابة ExpressRoute موجودة في نفس الشبكة الظاهرية مثل Route Server وNVA لتوفير الاتصال بالشبكات المحلية، برمجة المسارات التي تعلمتها هذه البوابات أيضا في الشبكات الظاهرية المحورية. تتجاوز هذه المسارات المسار الافتراضي (0.0.0.0/0) الذي تم إدخاله بواسطة Route Server، لأنها ستكون أكثر تحديدا (أقنعة شبكة أطول). يصف الرسم التخطيطي التالي التصميم السابق، حيث تمت إضافة بوابة ExpressRoute.

لا يمكنك تكوين الشبكات الفرعية في الشبكات الظاهرية المحورية لمعرفة المسارات فقط من Azure Route Server. يؤدي تعطيل "نشر مسارات البوابة" في جدول توجيه مقترن بشبكة فرعية إلى منع إدخال كلا النوعين من المسارات (التوجيهات من بوابة الشبكة الظاهرية والمسارات من Azure Route Server) في NICs في تلك الشبكة الفرعية.

بشكل افتراضي، يعلن Route Server عن جميع البادئات التي تم تعلمها من NVA إلى ExpressRoute أيضا. قد لا يكون هذا مطلوبًا، على سبيل المثال بسبب حدود مسار ExpressRoute أو Route Server نفسه. في هذه الحالة، يمكن أن تعلن NVA عن مساراتها إلى Route Server بما في ذلك مجتمع no-advertise BGP (بقيمة 65535:65282). عندما يتلقى Route Server المسارات مع مجتمع BGP هذا، فإنه يضخها في الشبكات الفرعية، ولكنه لن يعلن عنها لأي أقران BGP آخرين (مثل ExpressRoute أو بوابات VPN أو NVAs الأخرى).

تعايش SDWAN مع ExpressRoute وجدار حماية Azure

حالة معينة من التصميم السابق هي عندما يقوم العملاء بإدراج جدار حماية Azure في تدفق نسبة استخدام الشبكة لفحص جميع نسبة استخدام الشبكة التي تنتقل إلى الشبكات المحلية، إما عبر ExpressRoute أو عبر أجهزة SD-WAN/VPN. في هذه الحالة، تحتوي جميع الشبكات الفرعية المحورية على جداول توجيه تمنع المحاور من تعلم أي مسار من ExpressRoute أو Route Server، ولديها مسارات افتراضية (0.0.0.0/0) مع جدار حماية Azure كوثبة تالية، كما يظهر الرسم التخطيطي التالي:

تتعلم الشبكة الفرعية لجدار حماية Azure المسارات القادمة من كل من ExpressRoute وVPN/SDWAN NVA، وتقرر ما إذا كان إرسال حركة المرور بطريقة أو بأخرى. كما هو موضح في القسم السابق، إذا أعلن جهاز NVA عن أكثر من 1000 مسار إلى Route Server، فيجب عليه إرسال مسارات BGP المميزة بمجتمع no-advertiseBGP. بهذه الطريقة، لن يتم حقن بادئات SDWAN مرة أخرى إلى أماكن العمل عبر Express-Route.

تماثل نسبة استخدام الشبكة

إذا تم استخدام مثيلات NVA متعددة في سيناريو نشط/نشط لتحسين المرونة أو قابلية التوسع، فإن تماثل نسبة استخدام الشبكة هو مطلب إذا كانت NVAs بحاجة إلى الحفاظ على حالة الاتصالات. هذا هو، على سبيل المثال، حالة جدران الحماية من الجيل التالي.

• للاتصال من أجهزة Azure الظاهرية إلى الإنترنت العام، يستخدم NVA ترجمة عنوان الشبكة المصدر (SNAT) بحيث يتم الحصول على نسبة استخدام الشبكة الخارجة من عنوان IP العام ل NVA، وبالتالي تحقيق تماثل نسبة استخدام الشبكة.
• بالنسبة لحركة المرور الواردة من الإنترنت إلى أحمال العمل التي تعمل في الأجهزة الظاهرية، بالإضافة إلى ترجمة عنوان الشبكة الوجهة (DNAT)، ستحتاج NVAs إلى ترجمة عنوان الشبكة المصدر (SNAT)، للتأكد من أن نسبة استخدام الشبكة المرتجدة من الأجهزة الظاهرية تهبط في نفس مثيل NVA الذي عالج الحزمة الأولى.
• للاتصال من Azure إلى Azure، نظرًا لأن الجهاز الظاهري المصدر سيتخذ قرار التوجيه بشكل مستقل عن الوجهة، فإن SNAT مطلوب اليوم لتحقيق تماثل نسبة استخدام الشبكة.

يمكن نشر مثيلات NVA متعددة في إعداد نشط/سلبي أيضًا، على سبيل المثال إذا أعلن أحدهما عن مسارات أسوأ (بمسار AS أطول) من الآخر. في هذه الحالة، سيقوم Azure Route Server فقط بإدخال المسار المفضل في الأجهزة الظاهرية VNet، وسيتم استخدام المسار الأقل تفضيلاً فقط عندما يتوقف مثيل NVA الأساسي عن الإعلان عبر BGP.

خوادم التوجيه المختلفة للإعلان عن المسارات إلى بوابات الشبكة الظاهرية وإلى الشبكات الظاهرية

كما أظهرت الأقسام السابقة، فإن Azure Route Server له دور مزدوج:

• وهو يتعلم ويعلن عن المسارات من/إلى بوابات الشبكة الظاهرية (VPN وExpressRoute)
• يقوم بتكوين المسارات المستفادة على الشبكة الظاهرية الخاصة به، وعلى الشبكات الظاهرية المتناظرة مباشرة

غالبًًا ما تكون هذه الوظيفة المزدوجة مثيرة للاهتمام، ولكن في بعض الأحيان يمكن أن تكون ضارة بمتطلبات معينة. على سبيل المثال، إذا تم توزيع خادم الطريق في شبكة VNet مع إعلان NVA عن مسار 0.0.0.0/0 وبادئات إعلانات بوابة ExpressRoute من أماكن العمل، فسيتم تكوين جميع المسارات (كلاهما 0.0.0.0/0 من NVA والبادئات المحلية) على الأجهزة الافتراضية في VNet الخاص بها وأطل مباشرة على VNets. نتيجة لذلك، نظرًا لأن البادئات المحلية ستكون أكثر تحديدًا من 0.0.0.0/0، فإن نسبة استخدام الشبكة بين أماكن العمل و Azure ستتجاوز NVA. إذا لم يكن هذا مطلوبا، فقد أظهرت الأقسام السابقة في هذه المقالة كيفية تعطيل نشر BGP في الشبكات الفرعية للجهاز الظاهري وتكوين UDRs.

ومع ذلك، هناك نهج بديل أكثر ديناميكية. من الممكن استخدام خوادم توجيه Azure مختلفة لوظائف مختلفة: سيكون أحدهما مسؤولا عن التفاعل مع بوابات الشبكة الظاهرية، والآخر للتفاعل مع توجيه الشبكة الظاهرية. يوضح الرسم البياني التالي تصميمًا محتملاً لهذا:

يتم استخدام Route Server 1 في المركز لإدخال البادئات من SDWAN في ExpressRoute. نظرا لأن الشبكات الظاهرية المحورية تتناظر مع الشبكة الظاهرية المركزية دون استخدام بوابة الشبكة الظاهرية البعيدة أو خادم التوجيه (في نظير الشبكة الظاهرية المحوري) واستخدام بوابة الشبكة الظاهرية هذه أو خادم التوجيه (عبور البوابة في تناظر الشبكة الظاهرية المركزية)، لا تتعلم الشبكات الظاهرية المحورية هذه المسارات (لا بادئات SDWAN ولا بادئات ExpressRoute).

لنشر المسارات إلى الشبكات الظاهرية المحورية، يستخدم NVA Route Server 2، المنشور في شبكة ظاهرية مساعدة جديدة. سيقوم NVA بنشر مسار واحد 0.0.0.0/0 فقط إلى Route Server 2. نظرا لأن الشبكات الظاهرية المحورية تتناظر مع هذه الشبكة الظاهرية المساعدة مع استخدام بوابة الشبكة الظاهرية البعيدة أو Route Server (في نظير الشبكة الظاهرية المحوري) واستخدام بوابة هذه الشبكة الظاهرية أو Route Server (عبور البوابة في تناظر الشبكة الظاهرية المركزية)، 0.0.0.0/0 سيتم تعلم المسار من قبل جميع الأجهزة الظاهرية في المحاور.

الوثبة التالية للمسار 0.0.0.0/0 هي NVA، لذلك لا تزال الشبكات الظاهرية المحورية بحاجة إلى النظر إلى الشبكة الظاهرية المركزية. جانب مهم آخر يجب ملاحظته هو أن الشبكة الظاهرية المركزية تحتاج إلى نظير إلى الشبكة الظاهرية حيث يتم نشر Route Server 2، وإلا فلن تتمكن من إنشاء تجاور BGP.

إذا كان من المقرر إرسال نسبة استخدام الشبكة من ExpressRoute إلى الشبكات الظاهرية المحورية إلى جدار حماية NVA للفحص، فلا يزال هناك حاجة إلى جدول توجيه في GatewaySubnet، وإلا فإن بوابة الشبكة الظاهرية ExpressRoute سترسل حزم البيانات إلى الأجهزة الظاهرية باستخدام المسارات التي تم تعلمها من نظير الشبكة الظاهرية. يجب أن تتطابق المسارات في جدول التوجيه هذا مع البادئات المحورية، ويجب أن تكون الوثبة التالية عنوان IP لجدار الحماية NVA (أو موازن التحميل أمام NVAs لجدار الحماية، للتكرار). يمكن أن يكون جدار الحماية NVA هو نفس SDWAN NVA في الرسم التخطيطي أعلاه، أو يمكن أن يكون جهازا مختلفا مثل Azure Firewall، حيث يمكن ل SDWAN NVA الإعلان عن المسارات مع الوثبة التالية التي تشير إلى عناوين IP الأخرى. يوضح الرسم التخطيطي التالي هذا التصميم مع إضافة Azure Firewall:

يسمح هذا التصميم بالحقن التلقائي للمسارات في الشبكات الظاهرية المحورية دون تداخل من المسارات الأخرى المستفادة من ExpressRoute أو VPN أو بيئة SDWAN، وإضافة NVAs لجدار الحماية لفحص حركة المرور.

المحتوى ذو الصلة

• تعرف على المزيد حول دعم Azure Route Server ل ExpressRoute وAzure VPN.
• تعرف على كيفية تكوين التناظر بين Azure Route Server والأجهزة الظاهرية للشبكة.