HM-RPC verschiedene Adressräume

[coolhead]

@randyandy

Gibt es eine Lösung für dieses Problem. Ich habe es auch:
Zwei ioBroker mit hm-rpc in unterschiedlichen Subnetzen über frotz-vpn verbunden.
ich kann keine hm-rpc Verbindung in den anderen Adressbereich herstellen.

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

@randyandy

Gibt es eine Lösung für dieses Problem. Ich habe es auch:
Zwei ioBroker mit hm-rpc in unterschiedlichen Subnetzen über frotz-vpn verbunden.
ich kann keine hm-rpc Verbindung in den anderen Adressbereich herstellen.

hast du die callback adresse korrekt?

[RandyAndy]

@coolhead

ich habe das nicht mehr weiter verfolgt. Am Ende war das mit der VPN-Verbindung einfach zu langsam und habe dann einen zweiten ioBroker aufgesetzt.

Andreas

[coolhead]

@randyandy
was muss denn bei callback Adresse stehen?

Zur Erklärung meines Aufbaus:

ich habe zwei Subnetze an verschiedenen Orten mit jeweils einem rpi4 auf denen der ioBroker und piVCCU im lxc läuft. Jeder Standort für sich funktioniert lokal gut.

Da die beiden Standorte über fritz-vpn verbunden sind (jeweils unterschiedliche Sub-Netze) , möchte ich über den ioBroker von Standort A auf Standort B zugreifen.
Standort A : iobroker 192.168.20.22, piVCCU 192.168.20.24, Gateway 192.168.20.99
Standort B : iobroker 192.168.40.22, piVCCU 192.168.40.24, Gateway 192.168.40.99

Der vpn-Zugriff geht auch von A nach B (z.B. ssh, Web-Zugriff auf die remote ccu).

Um aus ioBroker von A auf die piVCCU in B zuzugreifen starte ich nun in A eine 2. Instanz von hm-rpc und hm-rega und trage die IPs von B ein. Bei Callback, was kommt da rein?

Die 2. hm-rpc-Instanz bei A bekommt momentan keine Verbindung zur CCU von B. Sobald ich die hm-rpc Instanz bei A starte ist auch der Web-Zugriff von A nach B auf die remote CCU nicht mehr möglich und die CCU muss per ssh neu gestartet werden.
Die Firewall der piVCCU (B) ist auf Vollzugriff eingestellt. Bei iptabels bzw. nft sehe ich auch nichts auffälliges.

Was muss ich bei der 2. hm-rpc Instanz bei A einstellen, damit der Zugriff auf die CCU (B) klappt?
Ist bei der CCU (B) oder im Container noch etwas freizugeben?

Welche logs oder config Dateien könnten Aufschluss geben?

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

was muss denn bei callback Adresse stehen?

die IP unter der die CCU deinen iobroker erreichen kann.

[coolhead]

@homoran
Danke, habe ich schon probiert (also die 192.168.20.22) - geht aber trotzdem nicht.

[Homoran]

@coolhead sagte in HM-RPC verschiedene Adressräume:

@homoran
Danke, habe ich schon probiert (also die 192.168.20.22) - geht aber trotzdem nicht.

lxc ist etwas anders gestrickt
ich nutze so was deswegen nicht, glaube aber da muss der Host adressiert werden, der routet dann in den Container

[coolhead]

@homoran
HMM - ich kann den lxc-Container in B aber direkt von A über das vpn adressieren, d.h. wenn ich die 192.168.40.24 anspreche, dann reagiert der Container wie erwartet (wie ein 2. virtueller Rechner mit einer eigenen IP).
Mit z.B. ssh, Web-Zugriff auf die piVCCU, ping sowieso. Ist da möglicherweise noch ein Fierwll-Problem für den Port? Oder kommt da etwas mit den Port durcheinander?

[paul53]

@coolhead sagte: ein Fierwll-Problem für den Port?

Vergrößere mal das Subnet in der CCU.

[coolhead]

@paul53

Wo mache ich das? bei meiner CCU kann ich nur die eigene IP und die Subnetzmaske eingeben.

[paul53]

@coolhead sagte: nur die Subnetzmaske eingeben

Dann gib dort mal 255.255.192.0 ein.

[coolhead]

@paul53
Danke - hab ich gemacht. Was trage ich bei Callback Adresse ein?

[paul53]

@coolhead sagte: Was trage ich bei Callback Adresse ein?

Nichts oder die ioBroker-IP-Adresse.

[coolhead]

@paul53
Dauert immer etwas, da ich bei jedem Fehlversuch die CCU per ssh neu starten muss, falls der rpc-Call falsch läuft.
Jetzt nach mehrfachen Neustarts per ssh komme ich nicht mehr per http auf die remote ccu - wahrscheinlich wegen der neuen subnetzmaske??

die ccu netconfig sieht jetzt so aus:
MODE=MANUAL
CURRENT_IP=192.168.40.24
CURRENT_NETMASK=255.255.192.0
CURRENT_GATEWAY=192.168.40.99
CURRENT_NAMESERVER1=8.8.8.8
CURRENT_NAMESERVER2=1.1.1.1
IP=192.168.40.24
NETMASK=255.255.192.0
GATEWAY=192.168.40.99
NAMESERVER1=8.8.8.8
NAMESERVER2=1.1.1.1
CRYPT=0

[paul53]

@coolhead sagte: wegen der neuen subnetzmaske??

Keine Ahnung. Dann ändere es wieder zurück.
Gibt es in der CCU nicht auch Firewall-Einstellungen, bei denen der IP-Adressbereich angegeben wird? Ich muss fragen, da ich keine CCU mehr verwende, sondern nur noch den rfd aus der OCCU.

[coolhead]

@coolhead
So, nun per ssh die Netzmaske wieder auf 255.255.255.0 gesetzt und http auf die ccu geht wieder. Nach meinem Verständnis ist diese Netzmaske ja auch richtig, denn alles was nicht im 192.168.40-er Adressbereich bleibt, soll ans Gateway und damit übers vpn, wenn es in den 20-er Bereich geht, oder?

[coolhead]

@paul53
ja, in der CCU gibt es auch Firewalleinstellungen. Die sind aber alle auf Vollzugriff. Ich hoffe, im Container gibt es nicht noch andere bösen Geister, die an den iptables / nft schrauben. Da kenne ich mich nicht so aus.

[paul53]

@coolhead sagte: soll ans Gateway

Hast Du dessen IP-Adresse (192.168.40.99) mal als Callback-Adresse eingegeben?

[paul53]

@homoran sagte: lxc ist etwas anders gestrickt
ich nutze so was deswegen nicht

Du nutzt kein piVCCU?

[coolhead]

@paul53
hab ich eben gemacht. Beide Adapter werden grün aber nach 90 sek kommt der Timeout bei hm-rega, dass er nichts lesen kann.

hm-rega.1
2022-06-19 15:13:22.677 error CCU 192.168.40.24 unreachable
hm-rega.1
2022-06-19 15:13:22.676 error post request error: Aborted due to timeout
hm-rega.1
2022-06-19 15:13:22.674 warn "!# datapoints.fn 1.9!#!# Dieses Homematic-Script gibt eine Liste aller Datenpu" timed out after 90 seconds
hm-rega.1
2022-06-19 15:11:52.601 info request state values
hm-rega.1
2022-06-19 15:11:51.888 info time difference local-ccu 1s
hm-rega.1
2022-06-19 15:11:51.733 info ReGaHSS 192.168.40.24 up