Bitte nicht prügeln: knxd in Docker Container

[aldaris]

Guten Tag,

[Disclaimer]
Nach dem was ich bis hier gelesen habe, kann man trefflich darüber streiten, ob das eine gute Idee ist, was ich hier vorhabe. Ich würde gerne versuchen diese Diskussion nicht zu führen. Ich will das nicht nur ans laufen kriegen sondern auch was lernen.
Nochwas: Mein Container Setup hatte einige Images, Webserver, Datenbanken u.v.m.. Daher läuft auch ein Reversy Proxy. network_mode: host möchte ich also vermeiden.

Also:
Ich habe einen alten Raspberry Pi auf dem KNXD läuft. Er kommuniziert über IP mit dem KNX Interface und wird auf dem Rechner mit knxtools bedient. Dabei gelten folgende Parameter:

-e 1.1.245 -E 1.1.246:8 --no-tunnel-client-queuing -B single -b ipt:192.168.178.39 -c -DTRS

Der funktioniert und läuft auch noch mit.

Jetzt soll das KNXD in einen Docker Container auf einem Raspberry Pi 5, daher habe ich zwei Aufgaben: A) Kommunikation knxd zu KNX IP und B) knxtools zu knxd

Starten wir mit A):
Hier könnte ich eigentlich keine Probleme erwartet, da knxd ja "raus" ruft. Ich habe es also naiv mit den gleichen Paramentern probiert (Adresse angepasst um nicht doppelkt zu vergeben)

-e 1.1.244 -E 1.1.246:8 --no-tunnel-client-queuing -B single -b ipt:192.168.178.39 -c -DTRS

Antwort ist:

The option '--no-tunnel-client-queuing' is obsolete.
Please use '--send-delay=30'.
​

Gesagt, getan:

-e 1.1.244 -E 1.1.246:8 --send-delay=30 -B single -b ipt:192.168.178.39 -c -DTRS

Geht aber leider auch nicht.

F00000105: [ 6:A.ipt] Link down, terminating

und mit -t 9

Layer 3 [ 6:A.ipt/Conn      0.000] registerLink: 6:A.ipt
Layer 3 [ 6:A.ipt/Conn         0.000] Start: cfg:A.ipt
Layer 0 [ 7:A.ipt/ipt          0.000] Open
Layer 0 [ 7:A.ipt/ipt          0.000] Opened
Layer 0 [ 7:A.ipt/ipt          0.000] Send(026): 06 10 02 05 00 1A 08 01 AC 1B 00 02 DC 7C 08 01 AC 1B 00 02 DC 7C 04 04 02 00
Layer 0 [ 7:A.ipt/ipt          10.008] Close D
F00000105: [ 6:A.ipt] Link down, terminating

Hat jemand einen Tipp für mich?

[henfri]

Ich kann nur beitragen, dass ich es ohne Net=host nicht geschafft habe.
Daher würde ich damit starten.
Danach kannste ja noch immer versuchen net=host los zu werden.

[aldaris]

Hi, das hatte ich schon gelesen. Mit net = host startet es und man sieht nen Art Busmonitor. Das klappt also Dein Image auf hub.docker.com hätte ich genommen, ist aber amd64.

[henfri]

Nochwas: Mein Container Setup hatte einige Images, Webserver, Datenbanken u.v.m.. Daher läuft auch ein Reversy Proxy. network_mode: host möchte ich also vermeiden.

das hab ich nicht ganz verstanden

[aldaris]

Hi,

war auch etwas flapsig geschrieben, sry:

Auf dem Raspberry Pi laufen einige Container, u.a. Webserver, die an das Internet angebunden sind. Als Schuz habe ich u.a. den Port 443 vom Raspberry Pi auf einen NGINX Reverse Proxy umgeleitet, von dort geht es dann an die Container weiter (Reverse Proxy).

Mit der Portweiterleitung im docker-compose habe ich so einen Überblick, welche Ports wie weitergeleitet werden. Wenn jetzt ein Container "host" macht, ist diese Trennung, nach meinem Verständnis, aufgehoben. Oder?

[meti]

Ich nehme an du musst NAT Mode aktivieren wenn du nicht net=host machst.

[henfri]

Ja, aber die Firewall des Router ist ja noch zwischen dir und den bösen Buben

letztlich ist es ohne Net=host bezüglich des Netzwerks nicht anders als hättest du docker auf dem host installiert.

Da spricht ja nix gegen.

[Smurf]

Wenn jetzt ein Container "host" macht, ist diese Trennung, nach meinem Verständnis, aufgehoben.

Irgendwie habe ich das Gefühl, als ob hier alle dächten, dass "bridge" und "host" die einzigen Alternativen wären.

Dem ist mitnichten so. "macvlan" bietet sich an. Siehe https://docs.docker.com/network/drivers/

[aldaris]

Das sieht in der Tat spannend aus. Werde das mal heute abend intensiv lesen.

Bis dahin habe ich den Code mal auf GitHub gesetzt:
https://github.com/AAPohl/docker_knx...cker-image.yml

Ich möchte ja gerne verstehen, wie das funktioniert. Bei mir "lokal" sehe ich wie gesagt mit "host" Nachrichten vom Bus, ohne startet er nicht. In der Docker Action geht auch host nicht mit gleichem Fehler, irgendwas scheint also zu fehlen auf "virtuellen" Maschinen. Kann man sagen, was das ist?

Nach meiner Interpretation:
Bei mir lokal mit Host: "Ich habe einen phyischen Rechner mit Netzwerkkarte, die mit dem Docker geteilt wird" => Geht
Bei mir lokal ohne Host: "Der Container ist rein virtuell, hat ein "Netzwerk" => Geht nicht
Auf Github mit Host: "Der Basisrechner ist selbst virtuell, teilt das mit Docker => Geht nicht

[aldaris]

Ok, ich habe jetzt mehr Verständnis von macvlan. Es ist aber trotzdem nicht das, was ich suche. Ich verstehe, warum es darüber funktioniert, weil der container ja als gleichwertiger Teilnehmer im Netzwerk auftaucht.

Ist es nicht doch denkbar, die relevanten Pakete in den Container zu bringen. Wenn nicht über Portbindung, dann über eine andere Möglichkeit? Socket übertragen o. Ä.?

Gibt es Infos, die die Pakete aufgebaut sind?

[henfri]

Es ist aber trotzdem nicht das, was ich suche

In wiefern?

[aldaris]

In dem Ansatz ist die Maschine ja "vollständig" mit dem Netzwerk verbunden. Potentielle "Angriffe" sind leichter, die Isolation geriner. Sicher hier akademisch, aber ich find den Ansatz spannend, nur das an Informationen zu teilen, was relevant ist.

[Smurf]

Ja. Nett. Du hast einen Container. In dem gibt es genau einen Port, der offen ist, nämllich der vom knxd. Wie zum Geier soll da bitte ein Angreifer irgendwas ausrichten können, das er mit Portforwarding nicht genauso ausrichten könnte?

Ich weiß ehrlich nicht, was du sonst noch willst.

[aldaris]

Wenn ich aufmacvlan gehe, erhalte ich leider die gleichen Fehler wie ohne net: host.

Konfiguration:

knx:
    image: knxd2
    container_name: knxd
    command: knxd -e 1.1.245 -E 1.1.246:8 -D -T -R -S -f 9 -t 1023 -B single -b ipt:192.168.178.39
    networks:
      docker_net:
        ipv4_address: 192.168.178.230
​...
networks:
  docker_net:
    driver: macvlan
    driver_opts:
      parent: wlan0
    ipam:
      driver: default
      config:
        - subnet: 192.168.178.0/24
          gateway: 192.168.178.1
          ip_range: 192.168.178.232/27

Ergebnis:

knxd           | Layer 1 [12:A.ipt/ipt          10.007] Connect timed out
knxd           | Layer 0 [12:A.ipt/ipt          10.007] Close D
knxd           | Layer 5 [11:A.ipt/Conn         10.007] >up => error
knxd           | Layer 4 [11:A.ipt/Conn         10.007] link state changed: error
knxd           | F00000105: [11:A.ipt] Link down, terminating
knxd           | Layer 4 [11:A.ipt/Conn         10.008] R Stopping
knxd           | Layer 5 [11:A.ipt/Conn         10.008] error => >down
knxd           | Layer 4 [11:A.ipt/Conn         10.008] link state changed: error
knxd           | Layer 2 [12:A.ipt/ipt          10.009] Close A

Was hingegen startet und am Bus horcht:

  knx:
    image: knxd2
    container_name: knxd
    command: knxd -e 1.1.245 -E 1.1.246:8 -D -T -R -S -f 9 -t 1023 -B single -b ipt:192.168.178.39
    network_mode: host

Ergebnis:

knxd           | Layer 1 [12:A.ipt/ipt          30.073] Heartbeat
knxd           | Layer 1 [12:A.ipt/ipt          30.073] Send(010): 40 00 08 01 C0 A8 B2 C8 DC 8A
knxd           | Layer 0 [12:A.ipt/ipt          30.073] Send(016): 06 10 02 07 00 10 40 00 08 01 C0 A8 B2 C8 DC 8A
knxd           | Layer 0 [12:A.ipt/ipt          30.076] Recv(008): 06 10 02 08 00 08 40 00
knxd           | Layer 1 [12:A.ipt/ipt          30.076] got Connection State Response

Falls relevant: Ich verwende das Dockerfile:https://github.com/ReneHezser/knxd, nur gosu für arm64 statt amd64.

Hat jemand einen Tipp, wie ich mich dem Fehler nähern kann, um macvlan zu nutzen?

[meti]

Damit geht das bei mir unter macOS:

docker-compose.yml

version: '3.4'
services:
  knxd:
    image: renehezser/knxd
    container_name: knxd
    volumes:
      - ./config.ini:/config.ini
    ports:
      - 6720:6720
      - 3671:3671​

config.ini

[A.iptn]
debug = debug-A.iptn
driver = ipt
filters = single
ip-address = 10.1.0.41
nat = true
nat-ip = 0.0.0.0
data-port = 0
[debug-A.iptn]
error-level = 0x9
trace-mask = 0x3ff
[debug-server]
name = mcast:knxd
[main]
addr = 1.0.245
client-addrs = 1.0.246:8
connections = server,A.iptn
systemd = systemd
[server]
debug = debug-server
discover = true
router = router
server = ets_router
tunnel = tunnel​

Das ist deine

command: knxd -e 1.1.245 -E 1.1.246:8 -D -T -R -S -f 9 -t 1023 -B single -b ipt:192.168.178.39

umgewandelt in eine config.ini und zusätzlich "nat-ip" und "data-port" auf 0 gesetzt. Warum das bei "nat = true" oder "-iptn" nicht per default gemacht wird kann ich nicht sagen.