استكشاف مشكلات خادم Azure Route وإصلاحها

تعرف على كيفية استكشاف بعض مشكلات Azure Route Server الشائعة وإصلاحها.

مشكلات الاتصال

لماذا يفقد الجهاز الظاهري للشبكة (NVA) الاتصال بالإنترنت بعد أن يعلن عن المسار الافتراضي (0.0.0.0/0) إلى Route Server؟

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

لماذا يفقد NVA اتصاله ب Route Server بعد فرض جميع نسبة استخدام الشبكة إلى جدار حماية باستخدام مسار محدد من قبل المستخدم (UDR) على GatewaySubnet؟

إذا كنت ترغب في فحص حركة المرور المحلية باستخدام جدار حماية، يمكنك فرض جميع حركة المرور المحلية إلى جدار الحماية باستخدام مسار محدد من قبل المستخدم (UDR) على GatewaySubnet (جدول توجيه مقترن ب GatewaySubnet الذي يحتوي على UDR). ومع ذلك، قد يؤدي هذا UDR إلى قطع الاتصال بين Route Server والبوابة عن طريق فرض حركة مرور وحدة التحكم (BGP) على جدار الحماية (تحدث هذه المشكلة إذا كنت تقوم بفحص نسبة استخدام الشبكة الموجهة إلى الشبكة الظاهرية التي تحتوي على Route Server). لتجنب هذه المشكلة، تحتاج إلى إضافة UDR آخر إلى جدول توجيه GatewaySubnet لاستبعاد فرض حركة مرور وحدة التحكم إلى جدار الحماية (في حالة إضافة قاعدة BGP إلى جدار الحماية غير مرغوبة/ممكنة):

10.0.0.0/16 هو مساحة العنوان للشبكة الظاهرية و10.0.1.0/27 هو مساحة عنوان RouteServerSubnet. 10.0.2.1 هو عنوان IP لجدار الحماية.

أضفت مسارا معرفا من قبل المستخدم (UDR) مع نوع الوثبة التالية كبوابة الشبكة الظاهرية، ولكن هذا UDR لا يسري المفعول. هل هذا متوقع؟

نعم، هذا هو السلوك المتوقع. المسارات المعرفة من قبل المستخدم مع نوع الوثبة التالية بوابة الشبكة الظاهرية غير مدعومة للشبكات الفرعية داخل الشبكة الظاهرية ل Route Server والشبكات الظاهرية النظيرة. ومع ذلك، إذا كنت ترغب في تكوين الوثبة التالية لتكون جهازا ظاهريا للشبكة (NVA) أو الإنترنت، فإن إضافة مسار معرف من قبل المستخدم مع نوع الوثبة التالية VirtualAppliance أو الإنترنت مدعوم.

في المسارات الفعالة لواجهة شبكة الجهاز الظاهري، لماذا لدي مسار محدد من قبل المستخدم (UDR) مع تعيين نوع الوثب التالي إلى بلا؟

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

لماذا أفقد الاتصال بعد ربط نهج نقطة نهاية الخدمة ب RouteServerSubnet أو GatewaySubnet؟

إذا قمت بربط نهج نقطة نهاية الخدمة ب RouteServerSubnet أو GatewaySubnet، فقد ينقطع الاتصال بين النظام الأساسي للإدارة الأساسية ل Azure وخدمات Azure المعنية هذه (Route Server وبوابة VPN/ExpressRoute). يمكن أن يؤدي هذا إلى دخول موارد Azure هذه في حالة غير صحية، ما يؤدي إلى فقدان الاتصال بين أحمال العمل المحلية وأحمال عمل Azure.

لماذا أفقد الاتصال بعد استخدام DNS المخصص بدلا من DNS الافتراضي (الذي يوفره Azure) للشبكة الظاهرية ل Route Server؟

بالنسبة للشبكة الظاهرية التي يتم نشر Route Server فيها، إذا كنت لا تستخدم DNS الافتراضي (الذي يوفره Azure)، فتأكد من أن تكوين DNS المخصص الخاص بك قادر على حل أسماء المجالات العامة. وهذا يضمن أن خدمات Azure (Route Server وبوابة VPN/ExpressRoute) قادرة على الاتصال بلوحة الإدارة الأساسية ل Azure. لمزيد من المعلومات، راجع الملاحظة حول قواعد أحرف البدل في وثائق Azure DNS Private Resolver.

لماذا لا يمكن I TCP ping من NVA الخاص بي إلى عنوان IP لنظير BGP ل Route Server بعد إعداد تناظر BGP بينهما؟

في بعض NVAs، تحتاج إلى إضافة مسار ثابت إلى الشبكة الفرعية Route Server لتكون قادرا على اختبار اتصال TCP بخادم التوجيه من NVA وتجنب خفقان نظير BGP. على سبيل المثال، إذا كان Route Server في 10.0.255.0/27 وكان NVA في 10.0.1.0/24، فستحتاج إلى إضافة المسار التالي إلى جدول التوجيه في NVA:

10.0.1.1 هو عنوان IP الافتراضي للبوابة في الشبكة الفرعية حيث تتم استضافة NVA الخاص بك (أو بشكل أكثر دقة، إحدى بطاقات NIC).

لماذا أفقد الاتصال بشبكتي المحلية عبر ExpressRoute و/أو Azure VPN عند نشر Route Server إلى شبكة ظاهرية تحتوي بالفعل على بوابة ExpressRoute و/أو بوابة Azure VPN؟

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

مشاكل طائرة التحكم

لماذا لا تتلقى شبكتي المحلية المتصلة ببوابة Azure VPN المسار الافتراضي المعلن عنه بواسطة Route Server؟

على الرغم من أن بوابة Azure VPN يمكن أن تتلقى المسار الافتراضي من نظرائها BGP بما في ذلك Route Server، إلا أنها لا تعلن عن المسار الافتراضي إلى نظراء آخرين.

لماذا لا يتلقى NVA المسارات من Route Server على الرغم من أن نظير BGP قد انتهى؟

ASN الذي يستخدمه Route Server هو 65515. تأكد من تكوين ASN مختلف ل NVA الخاص بك بحيث يمكن إنشاء جلسة eBGP بين NVA و Route Server بحيث يمكن أن يحدث نشر المسار تلقائيا. تأكد من تمكين "متعدد الوثب" في تكوين BGP لأن NVA وخادم التوجيه موجودان في شبكات فرعية مختلفة في الشبكة الظاهرية.

لماذا لا يعمل الاتصال عندما أعلن عن مسارات باستخدام ASN من 0 في AS-Path؟

يقوم Azure Route Server بإسقاط المسارات باستخدام ASN من 0 في AS-Path. لضمان الإعلان عن هذه المسارات بنجاح في Azure، يجب ألا يتضمن AS-Path 0.

تناظر BGP بين NVA الخاص بي وخادم التوجيه هو ما يصل. أستطيع أن أرى المسارات متبادلة بشكل صحيح بينهما. لماذا لا تكون مسارات NVA في جدول التوجيه الفعال لجهازي الظاهري؟

• إذا كان الجهاز الظاهري الخاص بك في نفس الشبكة الظاهرية مثل NVA و Route Server:

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

  

  إذا كان لديك مثيلان أو أكثر من NVA، يمكنك الإعلان عن مسارات AS مختلفة لنفس المسار من مثيلات NVA مختلفة إذا كنت تريد تعيين مثيل NVA واحد كمثيل نشط والآخر خامل.

• إذا كان الجهاز الظاهري الخاص بك في شبكة ظاهرية مختلفة عن تلك التي تستضيف NVA وخادم التوجيه. تحقق مما إذا كان تناظر VNet ممكنا بين شبكتي VNets وما إذا تم تمكين استخدام Remote Route Server على الشبكة الظاهرية للجهاز الظاهري.

لماذا يتم إيقاف تشغيل الدالة Equal-Cost Multi-Path (ECMP) ل ExpressRoute بعد نشر Route Server إلى الشبكة الظاهرية؟

عند الإعلان عن نفس المسارات من شبكتك المحلية إلى Azure عبر اتصالات ExpressRoute متعددة، عادة ما يتم تمكين ECMP افتراضيا لنسبة استخدام الشبكة الموجهة لهذه المسارات من Azure مرة أخرى إلى شبكتك المحلية. حاليا، عند نشر Route Server، يتم فقدان معلومات متعددة المسارات في تبادل BGP بين ExpressRoute و Route Server، وبالتالي ستجتاز نسبة استخدام الشبكة من Azure فقط على أحد اتصالات ExpressRoute.

المشاكل التشغيلية

لماذا أرى خطأ حول النطاق والتخويل غير الصالحين لتنفيذ عمليات Route Server؟

إذا رأيت خطأ بالتنسيق أدناه، فتأكد من تكوين الأذونات التالية: Route Server Roles and Permissions

تنسيق رسالة الخطأ: "العميل الذي لديه معرف {} الكائن ليس لديه تخويل لتنفيذ إجراء {} عبر النطاق {} أو النطاق غير صالح. إذا تم منح حق الوصول مؤخرا، فيرجى تحديث بيانات الاعتماد الخاصة بك."

الخطوة التالية

لمعرفة كيفية إنشاء وتكوين Azure Route Server، راجع: