ElabNET Technik Forum

Hi,

ich mehrere Docker mit HKKNX (Link) laufen. Diese Software stellt meine KNX-Geräte in HomeKit zur Verfügung, wodurch ich alles auch mit Sprache steuern kann.
Ich habe zwei Docker, da pro Instanz nur 150 Geräte (Limit bei HomeKit) installiert werden können.

Nun unterstützt hkknx eine sichere Verbindung und auch meine Schnittstelle (Enertex KNX IP Secure Router) unterstützt Secure Tunneling.
Also wollte ich das nun einmal umstellen, bekomme es aber mit dem TWS nicht hin.
Spoiler: Auf einem anderen Docker-Host geht es. Prinzipiell sollte es also funktionieren.

Nun ist mir beim Testen aber auch aufgefallen, dass ich im Docker aber auch die TWS-Schnittstelle nicht erreichen kann.

Es ist unerheblich, ob ich die Docker bridged oder mit MacVLAN mit eigener IP einrichte.
- TWS-Schnittstelle nie erreichbar, egal ob automatisch gesucht oder manuell angegeben (IP/Port/Protokoll)
- Den Enertex Router finden die Docker aber und auch manuell mit IP, Port 3671 und TCP oder UDP. Geht alles (unsicher)
Alles befindet sich im gleichen Subnet und mDNS ist dort aktiv.

Stelle ich nun im Docker auf sichere Verbindung, muss ich den Kanal für den Tunnel angeben, den Authentifizierungscode vom Router und das Passwort für den entsprechenden Tunnel.
Ergebnis ist, dass ich im Systemlog von hkknx "No route to [IP-VOM-KNX-SECURE-ROUTER] bekomme. Egal, ob bridged oder MacVLAN. Letzteres verwende ich ohne Probleme bei einigen Dockern.

Richte ich auf meinem Server (unraid) den gleichen Docker ein und erstelle Firewall Regeln, da dieser im Gegensatz zum TWS in einem anderen VLAN sitzt, funktioniert die sichere Verbindung auf Anhieb.

Da die Verbindung unsicher funktioniert, was den selben Port (3671) nutzt, ist das ein wenig komisch, denn erreichbar ist der Secure-Router dort ja. Ping geht ebenso. Egal ob der Router Secure Tunneling aktiv hat oder nicht und egal, ob eine sichere Verbindung gerade nicht aufgebaut werden kann von hkknx oder eine unsichere Verbindung hergestellt ist. Ping zum Router geht immer.

Im Zuge dessen ist mir dann auch aufgefallen, dass ich die TWS-Schnittstelle nicht erreichen kann. Egal, ob mit der eingestellten IP (eth0) oder 172.17.0.1 (Docker0).
Der Enertex-Router hat die 192.168.20.6, TWS hat die 192.168.20.50 und der Docker entweder 192.168.20.52 (MacVLAN) oder halt auch 192.168.20.50 (bridged).

Wie kann das sein, dass bei gleicher IP und Port eine unsichere Verbindung funktioniert, sicher aber nicht? Und wie kann es sein, dass es auf einem anderen Docker-Host funktioniert?

MacVLAN ist natürlich bei der Netzwerk-Schnittstelle aktiv, als Schnittstelle mit parent eth0 angegeben (funktioniert ja auch) und alles ist im gleichen Subnet.
Hat jemand einen Tipp für mich?

Einen Teil von oben habe ich gelöst bekommen, leider nicht alles.
Ich habe wohl nicht bemerkt, dass die TWS-Schnittstelle den Port 3700 und nicht 3671 nutzt.
Mit Portangabe 3700 und UDP (nicht mit TCP) erreiche ich die TWS-Schnittstelle.
Und auch nur mit der eth0-IP und nicht mit der docker0-IP (172.17.0.1). Die hatte ich nämlich mit UDP und Port 3700 ursprünglich angegeben, da diese in der Edomi in der Basis-Konfiguration auch so angegeben ist (App). Hauptsache Verbindung geht allgemein, aber wundern tut es mich halt.

Die Tatsache (oben), dass ich den Docker Container hkknx nur secure nutzen kann, wenn ich diesen nicht auf dem TWS betreibe, sondern auf einem anderen Host, bleibt leider bestehen und ärgert mich weiter. Diesen Umstand würde ich gerne ändern.
Hat jemand dafür einen Rat?

Nachdem ich nach meiner Knie-OP nun eh ans Sofa und Bett gefesselt bin, habe ich mich einmal umfangreich um mein Netzwerk gekümmert.

Aus Faulheit waren immer noch einige Geräte im "normalen" Netzwerk, die eigentlich in ein IoT-Netzwerk oder ein anderes separiertes VLAN gehören. KNX Router, TWS etc. sind aber noch nicht verschoben.
Ich habe so viel verschoben und geändert, dass ich der Einfachheit halber alle Firewall-Regeln komplett neu angelegt habe.

Nachdem ich nun also gerade wieder gut im Thema drin bin, wollte ich mich dem Problem mit HKKNX widmen, bekomme es aber nicht hin. Langsam glaube ich, dass es ein Problem mit Portainer sein könnte.

Worum gehts also? Der Docker stellt eine HomeKit Brücke für KNX zur Verfügung, braucht also eine Anbindung an KNX. Die unverschlüsselte Verbindung zur Schnittstelle ist in jeder Konstellation möglich, egal wie und wo ich es laufen lasse. Eine sichere Verbindung geht, aber nur ausserhalb vom TWS.

Ich nutze einen Enertex KNX IP Secure Router und habe bei diesem Secure Tunneling aktiviert. In HKKNX muss ich dann den Kanal angeben, das Passwort für diesen und das Authentifizierungspasswort. Ich bekomme aber auf dem TWS keine Verbindung. Das Log sagt nur "dial gateway: no route to 192.168.20.6:3671".
Der Ping geht aber und die unsichere Verbindung auch.

Der Einfachheit beschränkte ich mich auf 2 Systeme zum Testen. Timberwolf Server 3500XL mit Portainer und unraid Server (V. 6.12.14, Intel x64).
VLAN 1: 192.168.20.0/24
VLAN 2: 10.0.23.0/24
Der Timberwolf Server und KNX Router sind im VLAN 1 und unraid in VLAN 2.
Wenn HKKNX im VLAN2 läuft, erstelle ich Firewall-Regeln in beiden Richtungen zwischen HKKNX und Enertex IP Secure Router ohne Port-Beschränkung.

Der Enertex IP Secure Router hat die 192.168.20.6 und TWS die 192.168.20.50.
Bei allen der Möglichkeiten ist eine unsichere Verbindung möglich, bei der sicheren Verbindung zeigt das Log in HKKNX "dial gateway: no route to 192.168.20.6:3671". Ping aus der Konsole des Containers zum IP Secure Router ist immer möglich.
Probiert habe ich
- Netzwerk als bridge
- Netzwerk als MacVLAN (parent: eth0), IP im Netz von VLAN 1
- Netzwerk als Macvlan, tagged (parent: eth0.23), IP im Netz von VLAN 2

Egal wie, auf dem TWS mit Portainer geht die sichere Verbindung einfach nicht.

Nun auf dem unraid-Server:
Hier funktioniert alles. VM (Debian) oder Docker, im VLAN 1, wie der KNX IP Secure Router auch, in jedem beliebigen anderen VLAN mit Firewall-Regel. Eigene IP oder Bridged.
Unsichere und unsichere Verbindung möglich.

Warum bekomme ich das mit Portainer auf TWS ums verrecken nicht hin und auf anderen Hosts läuft es in jeder Konstellation?
Was ist bei der sicheren Verbindung zu KNX anders als bei der unsicheren? Ich meine, eine unsichere Verbindung klappt ja immer, eine Route zum Router sollte also immer funktionieren. TCP und UDP funktionieren beide, Port ändert sich auch nicht (3671).

Hat jemand eine Idee, warum das nicht funktioniert?

Du willst das per Tunneling oder per KNX-IP Routing erreichen?
Müsste da bei Routing nicht die KNX Multicast Adresse sein und nicht die IP vom Enertex-Router?

Ich möchte Tunnelverbindungen über KNX Secure Tunneling aufbauen. Enertex schreibt, dass Tunnelverbindungen die Multicast-Adresse nicht benötigen, also sollte die IP richtig sein (und funktioniert so auch am anderen Host).

Aber daran hatte ich in der Tat nicht gedacht bisher.

Hi Niels,

der Timberwolf Server unterstützt keine KNX Secure Tunneling Verbindungen. Nur damit es keine Missverständnisse gibt.

lg

Stefan

Das ist mir bewusst. Aber wenn eine Software in einem Docker-Container (Portainer) eine Secure Tunnelverbindung zu einem externen KNX IP Secure Router herstellen möchte, hat das doch keinen Einfluss oder?

In meinem Verständnis kann lediglich die Schnittstelle vom TWS kein Secure.
Oder muss der Host (TWS) irgendetwas unterstützen, damit das geht, was er momentan nicht tut?

Bitte dann daran denken das dann die Verbindung nicht zu einem Secure KNX Router sondern zu einem externen KNX-Secure Ip-Interface sein soll ll, das das Gerät mit der Interface-Funktionalität bei Dir dann ein KNX-Router ist ist dann eine Nebensache. Aber die Wortkombination Tunnelverbindung an einen Router ist eben verwirrend.

Aber schon spannend das die IP-Verbindung Docker Container auf TWS ins heimische LAN nicht mit KNX IPSecure zurechtkommt.

Wenn alle sonstigen Einstellungen im Portainer zu einem Container auf einem anderen Host identisch sind ist es ne spannende Frage.

Sorry, ich hatte geschrieben "Enertex KNX IP Secure Router", da das der Name des Gerätes ist. Ich kann verstehen, dass es verwirrend ist, aber es handelt sich definitiv um Secure Tunneling, was mit einer Secure Schnittstelle auch möglich wäre. Ich habe halt den Router.

Die Einstellungen sind identisch und ich habe auf beiden Hosts das ganze jeweils min. 10-15x neu angelegt und verschiedene Einstellungen getestet. In meiner (naiven?) Vorstellung müsste ich, da TCP und UDP Verbindungen (unsicher) über Port 3761 funktionieren genauso eine TCP Verbindung über den selben Port secure herstellen können (mit Passwörtern), ohne dass am Netzwerk etwas angepasst wird. IP Verbindung mit gleichem Protokoll halt nur mit etwas mehr Overhead. So meine Vorstellung