قواعد توجيه IP على Acano وخادم الاجتماعات (CMS) من Cisco

المقدمة

يصف هذا المستند قواعد توجيه IP على خوادم Acano أو Cisco Meeting Server (CMS). يمكن أن يكون لخوادم Acano أو CMS واجهات متعددة تم تكوينها، لكل منها بوابتها الافتراضية الخاصة.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• مكونات CMS: 
  • WebBridge (WB)
  • إجتياز باستخدام مرحلات حول خادم NAT (TURN)
  • CallBridge (CB)
• توجيه ال IP الأساسي

المكونات المستخدمة

تستند المعلومات الواردة في هذا المستند إلى Cisco Meeting Server على الإصدار 2.3.x.

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

معلومات أساسية

يتمثل الحد الوحيد هنا في أن الواجهات المختلفة على المحول ذي ال 4 منافذ يجب أن تكون في شبكات فرعية مختلفة وإلا يمكنك أن ينتهي بك الأمر إلى مشاكل في التوجيه على الإعداد الخاص بك. وكاستثناء من ذلك، يسمح لخوادم Hardware X التي تحتوي على واجهة Admin بأن تحتوي على واجهة Admin هذه في الشبكة الفرعية نفسها الخاصة بإحدى الواجهات الأخرى (A/B/C/D) كما هو موضح في دليل تثبيت CMS كما هو موضح على هذه الملاحظة.

ملاحظة: يجب عدم وضع أي واجهات لخادم الاجتماعات من Cisco في الشبكة الفرعية نفسها. الاستثناء الوحيد هو أن واجهة Admin لخادم Acano X-Series مادي يمكن أن تكون على الشبكة الفرعية نفسها الخاصة بإحدى الواجهات الأخرى (من A إلى D) وربما تكون عملية نشر شائعة.

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

ما هي قواعد توجيه IP التي يتم تطبيقها على خوادم Acano/CMS؟

يعتمد منطق توجيه IP على ما إذا كان الاتصال هو بروتوكول مخطط بيانات المستخدم (UDP) أو بروتوكول التحكم في الإرسال (TCP) في الطبيعة.
في حالة بروتوكول TCP، سواء كان اتصالا جديدا أو ردا على اتصال وارد، يمكنك العثور على منطق توجيه IP الذي ينطبق على حالتك باستخدام المخطط الانسيابي في الصورة.

رد اتصال TCP الوارد

يرد خادم Acano/CMS على اتصال TCP الوارد على الواجهة نفسها التي تم تلقي الطلب عليها (نظرا لوجود اتصال TCP بالفعل).

اتصال TCP الصادر أو أي حزم UDP الصادرة

لكلا السيناريوهين، يتم اتباع قواعد توجيه IP هذه وفقا لهذا المخطط الانسيابي (بالإضافة إلى الخطوة الأولى لردود اتصال TCP الواردة).

ملاحظة: ينطبق المنطق على إنشاء حزم UDP الصادرة الجديدة أو تلك التي يتم إرسالها ردا على الحزم المستلمة.

كيف يتم عرض جميع جداول توجيه IP (لكل واجهة)؟

باستخدام الأمر IPv4 <interface>على معالج إدارة اللوحة الرئيسية (MMP).

مع هذا أنت يستطيع رأيت ال يشكل عنوان وبادئة طول as well as all of the ساكن إستاتيكي مسحاج تخديد أن يكون setup ل هذا قارن كما هو موضح في هذا صورة.

على سبيل المثال، تم إعداد الموجهات إلى 8.8.8.8/32 و 8.8.4.4/32 للخروج بشكل صريح على هذه الواجهة المحددة (أ):

يمكنك أيضا رؤية المسارات التي تمت إضافتها على ملف live.json للواجهة المعنية (A) التي تخطط إلى ETH4.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"
                        }
                    }

ملاحظة: في ملف Live.json، تظهر الواجهات A-D (من MMP) الخريطة إلى ETH4-ETH1 وبالتالي واجهة A الخرائط إلى ETH4 وخرائط الواجهة D إلى ETH1. القصاصة الأخرى هي قصاصة من خادم X-Series حيث أنت يستطيع رأيت ال ADMIN قارن في قسم mmp تحت IPv4 بدلا من وحدة نمطية كما هو موضح للواجهات الأخرى.

    "ipv4": {
        "mmp": {
            "interfaces": {
                "eth0": {
                    "macaddress": "44:4A:65:00:13:00",
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "address": "10.48.79.72",
                    "prefixlen": "24",
                    "gateway": "10.48.79.200"
                }

in order to أضفت أو محات ساكن إستاتيكي إلى قارن خاص، أنت يستطيع استعملت الأمر ipV4 <interface> مسار (إضافة | del) <address>/<prefix length>.

كيف يتم التحقق من الواجهة الافتراضية وتغييرها؟

بشكل افتراضي تكون الواجهة A هي الواجهة الافتراضية إذا بدأت بتكوين فارغ.

أنت يستطيع دققت هذا على القارن ب التقصير معلم كما مبرزة على هذا صورة:

هذا هو مخرج الأمر ipV4 <interface>على MMP.

ملاحظة: إذا تم تعيين هذه القيمة على true، فهذا هو الواجهة الافتراضية كما في الصورة.

يمكنك أيضا أن ترى من the live.json ما إذا كانت الواجهة A (التي تخطط إلى ETH4)، قد تم إعدادها كواجهة افتراضية.

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"

لتغيير الواجهة الافتراضية، يمكنك إستخدام الأمر IPv4 <interface> الافتراضي، ولكن تأكد من أن لديك المسار (المسارات) الثابتة الصحيحة في موضعها لاستيعاب هذا التغيير وإلا سيتأثر التوجيه.

مثال:

تمثل الصورة مثالا لإعداد خادم منفصل واحد بخادم Core وخادم Edge واحد مع هذه المتطلبات:

• يمكن للخادم الرئيسي الاتصال بواجهة DMZ (A) فقط وليس بالواجهات العامة (C & D).
• يلزم أن ينصت مكون Turn Server إلى صوت 443 تماما مثل WebBridge (وبالتالي يلزم توفر واجهات مختلفة لتجنب حدوث تعارض في المنفذ).

في هذا المثال، لم يتم إعداد أي توجيه خاص ولم يتم تحديد واجهة افتراضية مختلفة لذلك فإنها تقوم بالإعدادات الافتراضية للواجهة A على خادم Edge.

الحالة:

• يمكن لعملاء WebRTC تسجيل الدخول ولكن فشل المكالمات
• ربط الطلبات من CB إلى الخادم TURN وتخصيصها للحصول على استجابات ناجحة
• وصل الطلبات الملزمة والمخصصة من عملاء WebRTC الخارجيين إلى خادم TURN ولكن لا تحصل على استجابات النجاح

الشرح:

• بما أن WB و LoadBalanced (LB) يستجيبان فقط لاتصالات TCP الواردة ولا يبدآن الاتصالات الصادرة نفسها، فإن هذا التوجيه لا يطرح مشكلة.

ملاحظة: بما أن الخدمتين على نفس الخادم، فلا يزال بإمكان WB إجراء اتصال صادر ب LB ولكن يحدث ذلك داخليا.

• أيضا التوثيق وتخصيص الطلبات من ال CB إلى TURN نادل DMZ IP يستجاب بما أن إما أن يكون في ال نفسه subnet (قارن Edge A و Core قارن A) أو لأن هناك ما من مسار ساكن إستاتيكي يثبت وهو فقط يبعث هو على التقصير قارن (قارن A في هذه الحالة).
• بالنسبة للربط الخارجي وتخصيص الطلبات، لا يحتوي على أي مسارات ثابتة وبالتالي يستخدم الواجهة الافتراضية A لتوجيه حركة المرور (التي ينتج عنها عدم الوصول إلى العميل الخارجي).

الحل:

• قم بإضافة الواجهة B على خوادم Edge واستخدم الواجهة A لاتصال WB الداخلي (بالإضافة إلى LB) والواجهة B لاتصال خادم TURN الداخلي (لتجنب اشتباك المنفذ على 443 يتم إستخدامه لكل من TURN و WB). قم بتكوين هذا باستخدام الأوامر التالية على MMP (وتصحيح تكوين TURN على الكباري الخاصة بك وفقا لذلك ل ServerAddress الجديد للواجهة B).

يضيف IPv4 b <IP-address>/<prefix length> <default-gateway>
تمكين IPv4 b

تعطيل الدوران
إستمع إلى B
تمكين الدوران

• قم بإضافة مسارات ثابتة لتوجيه حركة المرور من خوادم Edge إلى خادم Core الداخلي باستخدام الأمر:
    
    إضافة مسار إلى IPv4 b <address>/<prefix length>

ملاحظة: بما أن LB و WB تتفاعلان فقط على إتصالات TCP الواردة، فإنك تحتاج فقط إلى إعداد التوجيه لحزم UDP ل TURN وبالتالي تقوم بذلك على الواجهة B. أيضا تأكد من أن العبارة على الواجهة (ب) يمكن أن ترشده إلى CB بالطبع.

على سبيل المثال، إذا كان الخادم الأساسي يحتوي على عنوان IP 192.168.0.100/24، فيجب أن يكون الأمر إما IPv4 b route add 192.168.0.100/24 أو IPv4 b route add 192.168.0.100/32.

• قم بعمل واجهة خادم TURN الخارجية (D) كواجهة افتراضية لحركة المرور.

افتراضي IPv4 d

التحقق من الصحة 

لا يوجد حاليًا إجراء للتحقق من صحة هذا التكوين.

استكشاف الأخطاء وإصلاحها 

هناك حاليا ما من خاص أستكشاف الأخطاء وإصلاحها معلومات متوفرة لهذا التكوين.

معلومات ذات صلة 

• الدعم التقني والمستندات - Cisco Systems
• أداة محلل حلول التعاون 
• وثائق CMS