يعمل Home Assistant عبر شبكة Wi‑Fi لكنه يفشل عبر Ethernet أو VPN

إيفا وونغ

IceWhale author

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

Home Assistant Works on Wi-Fi but Fails on Ethernet or VPN

عندما يعمل Home Assistant عبر Wi‑Fi لكنه يفشل عبر Ethernet أو VPN، فمن المرجح أن التطبيق سليم؛ وعادةً ما يكون الخلل في حالة الاتصال، أو العنونة، أو المسارات، أو السياسات، أو DNS، أو حركة المرور الراجعة، أو اكتشاف الأجهزة عبر البث المتعدد.

أبقِ مسار Wi‑Fi المعروف بسلامته متاحًا أثناء اختبار Ethernet وVPN كلٌّ على حدة. استخدم أولًا عنوان IP المباشر للواجهة المستهدفة، ثم تحقّق من البوابة والمسار الراجع، وبعد ذلك اختبر منفذ الخدمة واسم المضيف والاكتشاف. قد يؤدي تغيير عدة طبقات من الشبكة معًا إلى فقدان الوصول، كما يجعل من المستحيل تحديد سبب نجاح النتيجة.

أثبت أن واجهة Ethernet تملك عنوانًا قابلًا للاستخدام

تحقّق من الاتصال الفيزيائي، والسرعة المتفاوض عليها، وحالة الواجهة، والعنوان المعيّن، والشبكة الفرعية، والبوابة، وتأجير DHCP من مضيف Home Assistant أو المشرف الافتراضي. قارنها بعميل يعمل على شبكة Ethernet نفسها. لا تثبت مؤشرات الاتصال الضوئية وحدها صحة إعدادات الطبقة الثالثة.

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

من عميل على الشبكة الفرعية نفسها، أرسل ping إلى عنوان IP الخاص بـ Ethernet أو اختبره بطريقة أخرى، ثم اختبر المنفذ 8123 المفتوح مباشرةً. إذا تعذر الوصول إلى عنوان IP، فواصل فحص الاتصال، وVLAN، وDHCP، والشبكة الفرعية. وإذا عمل عنوان IP لكن فشل اسم المضيف، فذلك يعني أن خدمة Ethernet سليمة، ويصبح DNS هو المسار التالي للفحص.

تحقّق من اختيار المسار وسياسة جدار الحماية وحركة المرور الراجعة

افحص جدول التوجيه أثناء نشاط Wi‑Fi وEthernet معًا. حدّد المسار الافتراضي، ومقاييس الواجهات، والمسار العائد إلى العميل الذي يجري الاختبار أو إلى الشبكة الفرعية لـ VPN. قد تجعل الردود التي تخرج عبر الواجهة الخطأ الاتصالات الواردة تبدو محجوبة، حتى عندما يكون الطلب قد وصل.

اختبر مؤقتًا من VLAN نفسها قبل عبور سياسات الموجّه. إذا نجح الوصول ضمن الشبكة الفرعية نفسها لكنه فشل عبر التوجيه، فافحص قواعد جدار الحماية بين شبكات VLAN، ووضع شبكة الحاوية، وجسر المشرف الافتراضي، والشبكات المسموح بها في VPN، والمسار العكسي من جهة Home Assistant.

تساعد مقارنة ZimaSpace بين شبكات المضيف والجسر على التمييز بين حدود منفذ الحاوية أو الاكتشاف وبين فشل Ethernet الفيزيائي. احتفظ بمسار Wi‑Fi العامل حتى يجتاز المسار السلكي الاختبار بصورة مستقلة.

افصل قابلية الوصول المباشر عن DNS والاكتشاف

اختبر بالترتيب التالي: عنوان IP لـ Ethernet أو VPN، ثم منفذ الخدمة، ثم اسم المضيف المهيأ، ثم الاكتشاف التلقائي. يشير نجاح الوصول المباشر عبر IP مع فشل اسم المضيف إلى DNS أو إلى عنوان مخزّن مؤقتًا وقديم. أما نجاح واجهة المستخدم مباشرةً مع غياب الأجهزة فيشير إلى مشكلة في الاكتشاف أو في سياسة الشبكة الفرعية للأجهزة.

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

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

Featured

ZimaCube 2 سحابة شخصية منزلية NAS

ZimaCube2

طبّق إصلاحًا واحدًا للشبكة وأعد اختبار كل مسار

صحّح الطبقة المؤكدة فقط: الكابل أو منفذ المحوّل، أو حجز DHCP، أو الشبكة الفرعية أو البوابة، أو مقياس الواجهة، أو قاعدة جدار الحماية، أو المسار الراجع، أو سجل DNS، أو الشبكة المسموح بها في VPN، أو مرحّل البث المتعدد. احفظ الإعداد السابق وجهّز وسيلة وصول محلية قبل إعادة تشغيل خدمات الشبكة.

أعد اختبار عنوان IP الخاص بـ Ethernet، واسم المضيف، والأجهزة المحلية، وعميل VPN، وواجهة المستخدم البعيدة، واستقرار WebSocket، والاكتشاف بالترتيب نفسه. أعد تشغيل المضيف مرة واحدة وجدّد حالة شبكة العميل حتى لا تتسبب المسارات القديمة وDNS المخزّن مؤقتًا في نجاح مؤقت.

تحافظ النتيجة الناجحة على وصول موثوق عبر Ethernet، وتبقي مسار VPN المقصود، وتتجنب مسارات افتراضية مكررة، ولا تكتشف إلا عبر الحدود المعتمدة. تراجع عن التغيير إذا اختفى مسار Wi‑Fi العامل أو تسربت حركة المرور بين المقاطع؛ وصعّد المشكلة مع تقديم أدلة الواجهة والمسار وجدار الحماية وتدفق الحزم عندما تصل الطلبات لكن تستمر الردود في الخروج بطريقة غير صحيحة.