هل ينبغي لـ Home Assistant استخدام شبكة المضيف أم شبكة الجسر؟

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

ينبغي أن يستخدم Home Assistant شبكة المضيف عندما يكون اكتشاف الأجهزة عبر الشبكة المحلية متطلبًا أساسيًا؛ بينما تكون شبكة الجسر أفضل عندما تكون المنافذ المحددة والعزل أكثر أهمية.

لا يُعد أيٌّ من الوضعين أسرع أو أكثر أمانًا على نحو مطلق. فالاختيار يغيّر مساحة أسماء الشبكة التي يراها Home Assistant، وكيف يصل إليه اكتشاف البث المتعدد والبث العام، والمنافذ التي تنشرها، وكيف تتصل الحاويات الأخرى. اتخذ القرار استنادًا إلى التكاملات التي يجب أن تعمل بعد إعادة التشغيل، ثم اختبر الاكتشاف والتحكم المباشر وبوابات MQTT أو الراديو والوصول الوارد عن بُعد في الوضع المختار قبل اعتبار الإعداد مستقرًا.

تحقق أولًا مما إذا كان Home Assistant يحتاج إلى استقبال حركة اكتشاف الشبكة المحلية

يمكن للعديد من تكاملات Home Assistant استخدام عنوان IP معروف أو اتصال بوسيط، لكن تكاملات أخرى تعتمد على mDNS أو SSDP أو UPnP أو اكتشاف البث العام. وتُعد هذه البروتوكولات السبب الرئيسي لشيوع استخدام شبكة المضيف في عمليات تثبيت Container؛ إذ يشارك Home Assistant مباشرة في مساحة أسماء الشبكة المحلية للمضيف بدلًا من الحاجة إلى تمرير البث المتعدد عبر جسر Docker.

يوضح دليل لشبكات Docker أن شبكة المضيف تزيل حدّ الجسر، ما يجعل الخدمات المعتمدة على البث أسهل، لكنه يلغي أيضًا نشر منافذ Docker والفصل بين مساحات أسماء الشبكة. ويُعد هذا التنازل أكثر أهمية من معدل النقل الخام في معظم عمليات تثبيت Home Assistant.

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

ينجح وضع شبكة المضيف عندما تفوق بساطة الاكتشاف أهمية عزل مساحة الأسماء

في وضع المضيف، يرتبط Home Assistant مباشرةً بمكدس شبكة المضيف. ولا توجد طبقة لربط منافذ Docker، كما ترى الحاوية واجهات المضيف بطريقة تتوافق عادةً بصورة أفضل مع الاكتشاف المحلي. لكن تكلفة ذلك هي ضعف عزل الشبكة، وضرورة إدارة تعارضات المنافذ على مستوى المضيف.

يصل شرح عملي لتصميم Home Assistant عبر Docker إلى النتيجة الشرطية نفسها: يُبسّط وضع المضيف اكتشاف mDNS وUPnP، بينما يجعل وضع الجسر حدود الشبكة والمنافذ المنشورة أكثر وضوحًا.

اختر وضع المضيف عندما تتكرر أعطال الاكتشاف، ويكون الخادم مضيفًا منزليًا موثوقًا يضم مجموعة خدمات خاضعة للتحكم. لا تستخدم وضع المضيف لمجرد إخفاء مشكلة اتصال غير معروفة. فإذا ظل جهاز ما يفشل مع شبكة المضيف، فقد يكون السبب قواعد VLAN أو عزل عملاء Wi-Fi أو DNS المحلي أو أذونات الجهاز أو مشكلة على مستوى التكامل، وليس جسر Docker.

ينجح وضع الجسر عندما تكون للتكاملات إمكانية وصول محددة

يمنح وضع الجسر الحاوية عنوان Docker خاصًا، ويتيح لك نشر منافذ Home Assistant التي ينبغي الوصول إليها فقط. ويمكن للحاويات الأخرى الاتصال عبر شبكات Docker المُسمّاة، بينما تصل أجهزة الشبكة المحلية إلى منفذ المضيف المنشور. ويشكّل ذلك حدًا أنظف عندما لا يكون الاكتشاف أساسيًا أو عندما تمرّر حركة البث المتعدد عمدًا عبر وكيل.

يفيد مستخدمو Home Assistant الذين يقارنون بين إعدادات الجسر وmacvlan بأن الجسر العادي قد يعقّد mDNS، بينما تعيد تصميمات الشبكة البديلة إظهار الشبكة المحلية مباشرةً. ويتمثل الدرس المفيد من سلوك الاكتشاف في شبكة الجسر في اختبار البروتوكول الذي تحتاج إليه بدلًا من افتراض أن منافذ TCP المنشورة تنقل أيضًا اكتشاف البث المتعدد.

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

-15% OFF

تحقق من الاختيار باستخدام مصفوفة التكامل نفسها بعد إعادة التشغيل

أنشئ اختبارًا من خمسة صفوف: الوصول إلى لوحة التحكم المحلية، وجهاز واحد عبر mDNS أو SSDP، وتكامل واحد عبر IP صريح، ووسيط أو بوابة راديو واحدة، ومسار الوكيل العكسي أو VPN المعتاد. اختبر بعد إعادة إنشاء الحاوية وإعادة تشغيل المضيف، وليس فقط بعد تغيير Compose مباشرةً، لأن بيانات الاكتشاف المخزنة مؤقتًا قد تخفي وضع شبكة سيفشل لاحقًا.

يوضح استكشاف ZimaSpace لمشكلة إمكانية الوصول إلى الشبكات الفرعية في Docker الحد نفسه: فتوافر التطبيق وإمكانية الوصول إلى شبكة الحاوية اختباران مختلفان، حتى عندما يعمل كلاهما على الخادم الفعلي نفسه.

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

الدعم والنصائح

المزيد للقراءة

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.