Home Assitant Multicast Traffic an anderes Interface leiten.

[BlueEclipse]

Hallo zusammen.

Ich habe bei mir aktuelle folgende Situation:

Home Assistant läuft auf dem Server in Netzwerk B, und dieser Server ist mit einem OpenVPN Layer-2-Tunnel mit dem Router in Netzwerk A verbunden. Auf dem Router in Netzwerk A wird das tap0-Interface (das Interface, das von OpenVPN für die Verbindung genutzt wird) mit dem LAN- und WLAN-Interface (wlo1 und eth1-4) gebridget.

Jeglicher Multicast-Verkehr aus meinem Heimnetz wird also automatisch durch den VPN-Tunnel zum Server geleitet.

Auf dem Server laufen verschiedene Dienste, unter anderem Home Assistant.

Home Assistant verwendet auch Multicast (z. B. mDNS), um Geräte automatisch zu finden.

Home Assistant sendet jedoch wahrscheinlich seine gesamten Multicast-Anfragen an enp0s6 (und damit in ein Netzwerk, in dem niemand außer dem Server und dem Router ist).

Ich habe das Ganze zwar noch nicht mit WireGuard überprüft (ich weiß aktuell auch nicht, wie, da ich nicht weiß, wie ich Home Assistant dazu bringe, nach Geräten zu suchen), aber ich vermute es anhand dieser Einstellungen, die für die Integrationen gelten:


Was möchte ich erreichen?

Ich möchte Home Assistant dazu bringen, alle seine Multicast-Anfragen an tap0 zu senden und damit an Netzwerk A weiterzuleiten.

Bisher habe ich es bereits mit

sudo ip route add 224.0.0.0/4 dev tap0

Probiert und nach einem Neustart von Home Assistant wurden tatsächlich einige Geräte gefunden.

Das Einzige, was nicht funktioniert, ist die Shelly-Integration. Diese findet a) Shelly 1 Gen nicht automatisch und b) selbst wenn ich ihm die IP-Adresse gebe, bekomme ich nur die Meldung, dass die Verbindung fehlgeschlagen ist (Wireshark zeigt mir aber, dass auf jeden Fall Verkehr zwischen Home Assistant und Shelly stattfindet, sobald ich den „Hinzufügen“-Button tippe).

Ich habe im Home Assistant Community Forum gelesen, dass bei Shelly oft mDNS das Problem ist (was eigentlich wenig Sinn macht, weil mDNS zur automatischen Erkennung (Multicast) genutzt wird und ich Home Assistant die IP von Shelly gebe, also Unicast).

Es geht mir aber weniger um das Shelly-Problem (das löst sich vielleicht ja durch die Effizienzsteigerung von selbst), sondern eher darum, ob es eventuell eine effizientere Lösung als meine gibt.

Derzeit ist es ja so, dass ich quasi mit einer Route den gesamten Multicast-Traffic an tap0 umleite.

Das Ganze ist natürlich ein wenig ineffizient, da ich auch Multicast-Traffic umleite, der beispielsweise bewusst an andere Interfaces geht (obwohl es außer dem Server und dem Router in Netzwerk B keine weiteren Geräte gibt, also besonders viel Multicast-Traffic für Netzwerk B wird dort nicht stattfinden).

Eventuell ist es ja möglich, Home Assistant dazu zu bringen, selbstständig seinen Multicast-Verkehr an tap0 zu senden.

Oben im Bild (Bild 2) sieht man die Seite, wo man in Home Assistant einen Adapter für Multicast-Verkehr (zumindest für Integrationen) festlegen kann. Aber wenn ich dort den Haken rausnehme, kann ich leider nur das Interface enp0s6 auswählen. Ich schätze mal, Home Assistant listet dort nur physische Netzwerkinterfaces auf, und tap0 ist virtuell.

Wenn ich es also hinkriege, tap0 als physisches Interface darzustellen, wird es dort eventuell angezeigt.

Eine andere Möglichkeit wäre vielleicht, nur den Multicast-Traffic von der Home Assistant IP-Adresse (ja, was ist die überhaupt? Home Assistant Supervisor läuft in seinem eigenen Docker-Bridge-Netzwerk, kennt aber wahrscheinlich wegen des Supervisors die verbundenen Netzwerkinterfaces) nach tap0 weiterzuleiten.

Was habt ihr für Ideen/was haltet ihr von meinen Ideen?

 

[BlueEclipse]

Hat niemand eine Idee?

 

[blurrrr]

Was habt ihr für Ideen/was haltet ihr von meinen Ideen?

Was ist das überhaupt für ein Tunnel, Site-to-Site, oder Roadwarrior? Wo terminiert der Tunnel auf der Server-Seite? Was läuft ggf. sonst noch auf dem Server (z.B. Virtualisierung via KVM)?

Ich bin von Natur aus faul und muss mir keine unnötige Arbeit aufhalsen, von daher wäre es bei mir vermutlich einfach ein Site-to-Site-Tunnel, welcher ggf. auch einfach auf einer virtualisierten Firewall terminiert (falls Hardware-technisch nix zur Verfügung steht). Irgendwas kostenloses, z.B. pfSense/OPNsense und dann macht man sich das restliche Leben halt einfach (unter einer OPNsense z.B. mittels entsprechendem Paket). HomeAssistant via Docker habe ich mir - nach erstmaliger Installation unter Docker - auch direkt wieder abgewöhnt (habe es aber auch nicht produktiv im Einsatz), aber so nach dem ersten Eindruck geht halt auch direkt nix über HAOS (dafür gibt es dann auch schon direkt fertige VM-Images).

Wenn Du halt eher Docker-Hardliner bist, da haben irgendwelche Leute bestimmt auch schon irgendwas an Images gebastelt (reine Vermutung, hab nicht nachgeschaut). Alternativ musst Du Dir halt selber entsprechende Dinge basteln (ob nun direkt auf der Kiste selbst, oder in Form eines selbst erstellten Docker-Images sei mal dahingestellt).

 

[BlueEclipse]

Hallo, entschuldige bitte die späte Antwort.
Ich sollte die E-Mail Benachichtigungen des Forums aktivieren .

Was ist das überhaupt für ein Tunnel, Site-to-Site, oder Roadwarrior?

Es handelt sich hierbei um einen Roadwarrior-Tunnel. Ein Site-to-Site-Tunnel würde in meinem Fall keinen Sinn ergeben, weil:

1. Im Netzwerk B (Standort B) steht nur dieses eine Gerät.


2. Ich habe keinen Zugriff auf den Router in Netzwerk B. Der Server müsste daher selbst als Router fungieren.



Der Server ist eigentlich eine VPS, also nur ein virtueller Teil eines physischen Servers, der bei einem Provider gemietet ist. Daher habe ich keinen Zugriff auf das dahinterliegende Netzwerk (also nicht auf die Infrastruktur des Providers, sondern nur auf die VPS selbst – ich denke, das ist verständlich).

Selbst wenn ich also einen Site-to-Site-Tunnel einrichten könnte, hätte das keinen Nutzen, da in diesem Netzwerk keine weiteren Geräte hinzukommen werden.

Wo terminiert der Tunnel auf der Server-Seite?

Auf der Serverseite terminiert der Tunnel auf meinem Router (einer FritzBox 7580). Das ergibt für mich Sinn, da der Router ohnehin 24/7 läuft. Andernfalls müsste ich einen separaten Server in Netzwerk A betreiben, der die Router-Funktion übernimmt, und die Geräte würden sich z.b bezüglich DHCP trotzdem nur auf den Router beziehen.

Der Router bridgt das tap0-Interface mit den Interfaces wlo0 sowie lan1-4. Dadurch werden alle Broadcast- und Multicast-Pakete über den VPN-Tunnel gesendet. Gleichzeitig werden empfangene Broadcast- und Multicast-Pakete auch an die Interfaces wlo0 und lan1-4 weitergeleitet werden.

Was läuft ggf. sonst noch auf dem Server (z.B. Virtualisierung via KVM)?

KVM kann ich auf dem Server generell nicht nutzen, da die VPS selbst eine virtuelle Maschine ist, die über KVM virtualisiert wird. Nested Virtualization ist auf diesem Server nicht aktiviert, weshalb keine weiteren KVM-Instanzen innerhalb der VPS betrieben werden können.

Auf dem Server laufen ansonsten einige Dienste in separaten Docker-Containern, wie zum Beispiel Jellyfin oder Passbolt. Zusätzlich gibt es einige Home Assistant-Plugins, die ja auch nur Docker-Container sind.

Ich bin von Natur aus faul und muss mir keine unnötige Arbeit aufhalsen, von daher wäre es bei mir vermutlich einfach ein Site-to-Site-Tunnel, welcher ggf. auch einfach auf einer virtualisierten Firewall terminiert (falls Hardware-technisch nix zur Verfügung steht). Irgendwas kostenloses, z.B. pfSense/OPNsense und dann macht man sich das restliche Leben halt einfach (unter einer OPNsense z.B. mittels entsprechendem Paket).

Derzeit läuft auf dem Server selbst keine Firewall, und die in Debian integrierte Firewall (ufw) ist deaktiviert.

Das mag zwar auf den ersten Blick wie eine große Sicherheitslücke wirken, hat aber einen bestimmten Hintergrund: Beim Anbieter, der die VPS hostet, kann ich festlegen, welcher Traffic überhaupt zur VPS durchgelassen wird.

In meinem Fall wird beispielsweise nur ICMP-Traffic und Anfragen an zwei spezifische Ports weitergeleitet. Alle anderen Dienste sind über einen Cloudflare-Tunnel freigegeben.

Der Vorteil dabei ist, dass ich teilweise gegen DDoS-Angriffe immun bin. Da der Server "nur" zwei offene Ports hat, die direkt angegriffen werden könnten, und mein Anbieter den übrigen Verkehr gar nicht durchleitet, wird eine potenzielle Überlastung der Firewall verhindert. Das Problem würde also eher beim Anbieter landen als bei mir.

Ich werde OpenSense mit dem entsprechenden Paket einmal ausprobieren. Die Firewall-Funktionalitäten von OpenSense könnte ich im Notfall auch deaktivieren, falls das nötig sein sollte. Es könnte jedoch z b aus Sicherheitsgründen sinnvoll sein, den eingehenden Traffic zu überwachen und zu sehen, wer auf den Server zugreift.

Da auf der VPS keine KVM-Nutzung möglich ist, werde ich OpenSense nicht in einer virtuellen Maschine laufen lassen können, sondern direkt auf dem Host-System installieren.

Bevor ich das tue, muss ich aber noch herausfinden, über welches Interface Home Assistant seine Daten sendet. Ich bin mir noch nicht sicher, ob das über das Docker-Interface geschieht oder über das physische esp06-Interface, wie es in den Home Assistant-Einstellungen angegeben ist(siehe letztes Bild erster Beitrag).

Wenn Du halt eher Docker-Hardliner bist, da haben irgendwelche Leute bestimmt auch schon irgendwas an Images gebastelt (reine Vermutung, hab nicht nachgeschaut). Alternativ musst Du Dir halt selber entsprechende Dinge basteln (ob nun direkt auf der Kiste selbst, oder in Form eines selbst erstellten Docker-Images sei mal dahingestellt).

Ich würde mich selbst nicht als Docker-Profi bezeichnen.

Es wird keine Docker-Images für den Home Assistant Supervisor geben, und das macht auch Sinn. Andernfalls würden Plugins in Docker-Containern laufen, die wiederum in Docker-Containern verschachtelt wären. Zudem wird das Ändern von Host-Einstellungen für Home Assistant ohne den OS-Agent schwierig.

Ich hatte auch schon überlegt, Proxmox einzusetzen. Allerdings könnte ich dort aufgrund des fehlenden KVM-Supports nur LXC-Container nutzen. Das bedeutet, dass HAOS nicht direkt laufen würde. Stattdessen müsste ich in Proxmox einen Debian-LXC-Container erstellen und dort den Home Assistant Supervisor installieren. Das erscheint mir aber etwas ineffizient.

 

[blurrrr]

Hättest Du es direkt so beschrieben (VPS bei externem Anbieter), wäre es deutlich verständlicher gewesen, da so schon direkt eine Menge Überlegungen weggefallen wären

Wie hast Du denn die VPN-Verbindung des Clients umgesetzt? So wie ich Dich verstanden habe, ist das ganze jetzt ja "nur" eine VM mit HAOS-Image. Gibt es da irgendwelche Integrationen/Addons, welche die HAOS-Installation eine VPN-Client-Funktionalität ermöglichen, oder doch eher "wie üblich" via Shell?

sudo ip route add 224.0.0.0/4 dev tap0

Probiert und nach einem Neustart von Home Assistant wurden tatsächlich einige Geräte gefunden.

Najo, dann scheint es doch zu funktionieren?

...selbst wenn ich ihm die IP-Adresse gebe, bekomme ich nur die Meldung, dass die Verbindung fehlgeschlagen ist (Wireshark zeigt mir aber, dass auf jeden Fall Verkehr zwischen Home Assistant und Shelly stattfindet, sobald ich den „Hinzufügen“-Button tippe).

Also das... scheint ja wohl wirklich ein Fall für sich zu sein, wenn sich die Dinge nichtmals via IP ansprechen lassen.

Da auf der VPS keine KVM-Nutzung möglich ist, werde ich OpenSense nicht in einer virtuellen Maschine laufen lassen können, sondern direkt auf dem Host-System installieren.

Das eignet sich in Deinem zuletzt beschriebenen Szenario dann wohl eher weniger.

Ich hatte auch schon überlegt, Proxmox einzusetzen.

Das taugt dann ja auch nicht. Ich war ursprünglich davon ausgegangen, dass Du sowieso etwas in diese Richtung laufen hast und dort dann entsprechend in einer VM HA laufen hast.

Bevor ich das tue, muss ich aber noch herausfinden, über welches Interface Home Assistant seine Daten sendet. Ich bin mir noch nicht sicher, ob das über das Docker-Interface geschieht oder über das physische esp06-Interface, wie es in den Home Assistant-Einstellungen angegeben ist(siehe letztes Bild erster Beitrag).

Das sollte dann normalerweise das entsprechende Host-Interface sein, welches bei HA unter /config/network (Netzwerkschnittstellen konfigurieren) angegeben ist. Vielleicht interessiert Dich aber auch - ganz unten - dieser Punkt:



Die Links hier hast Du schon durch?

https://www.home-assistant.io/integrations/network/
https://www.home-assistant.io/integrations/zeroconf/
https://developers.home-assistant.io/docs/creating_integration_manifest/#zeroconf