MacVLAN-Adresen von Docker nicht von der Diskstation erreichbar

[Uhlhorn]

Moin,
ich habe Docker-Container über MacVALN laufen, damit sie eine eigene IP-Adresse bekommen können, z.B. für ein Pi-hole. Alle Clients können mein Pi-hole erreichen. Nur die Diskstation selbst nicht. Docker läuft auf der Diskstation.

Ich nehme an, dass ich ein Routing einrichten muss oder so. Ich weiß aber nicht wie.

MacVLAN:
Subnet: 10.0.0.0/16
Gateway 10.0.1.1
IP-Range: 10.0.100.0/24

Pi-hole: 10.0.100.1
Synology 10.0.1.65 (Bond)

Ich habe mich per SSH an der Synology angemeldet und ein ping ausgeführt:
sudo ping 10.0.100.1
From 10.0.1.65 icmp_seq=1 Destination Host Unreachable

 

[Fusion]

Kommunikation zwischen macvlan und host/parent interface ist per Design nicht vorgesehen.

Über den Umweg eines Sub-Interface aber vermutlich möglich.
https://stackoverflow.com/questions/63203538/docker-macvlan-no-route-to-host-container

 

[Uhlhorn]

Hmm, dort wird aufgezeigt wie Container to Host Communication eingerichtet wird.

sudo ip link add mymacvlan70 link eth2.70 type macvlan mode bridge
sudo ip addr add 192.168.2.10/24 dev mymacvlan70
sudo ifconfig mymacvlan70 up

mymacvlan70 ist vermutlich der Name des Links und kann von mir frei gewählt werden.
eth2.70 ist die Netzwerkschnittstelle und müsste bei mir ovs_bond0 heißen. Jedenfalls habe ich das so in Portainer als Schnittstelle eingetragen.
192.168.2.10/24 muss dann mit der Angabe ersetzt werden, die ich in IP-Range eingetragen habe.

Auf mein Beispiel angepasst von oben müsste das dann folgendermaßen aussehen:

sudo ip link add MeineDockerBridge link ovs_bond0 type macvlan mode bridge
sudo ip addr add 10.0.100.0/24 dev MeineDockerBridge
sudo ifconfig MeineDockerDienste up

Ich nehme an, das führe ich dann (via SSH) auf der Synology aus.
Oder muss ich das im Docker-Container ausführen?
Ist das so korrekt?

Muss ich das nun bei jedem Neustart der Synology ausführen oder bleibt das erhalten?

 

[DKeppi]

Ich hab mir dafür ein Shellscript gebastelt, dass über den Aufgabenplaner beim Booten als root ausgeführt wird.
Geht sonst wieder verloren!

macvlan-bridge -> Name der Bridge
ovs_eth0 -> Syno Schnittstelle
192.168.178.23 -> Syno IP
192.168.178.5 -> PiHole IP
Die Macadresse hab ich selbst gewählt muss man aber nicht machen!

#!/bin/bash
while ! /usr/local/bin/docker info >/dev/null 2>&1;
do
    sleep 5s
done

ip link add macvlan-bridge link ovs_eth0 address 76:81:fd:c2:a2:43 type macvlan mode bridge
ip addr add 192.168.178.23/24 dev macvlan-bridge
ip link set macvlan-bridge up
ip route add 192.168.178.5/32 dev macvlan-bridge

Hier noch ein Video dazu: https://youtu.be/21CTUWn4JSI

 

[Uhlhorn]

Witzig, so ein Video von Navigio habe ich auch gerade angesehen, nur neuer: https://youtu.be/Y3B0kBl5cn8

ip link add macvlan-bridge link ovs_eth0 address 76:81:fd:c2:a2:43 type macvlan mode bridge
ip addr add 192.168.178.23/24 dev macvlan-bridge
ip link set macvlan-bridge up
ip route add 192.168.178.5/32 dev macvlan-bridge

Wie kommst Du auf die /24 und die /32?

Also ich weiß, dass es eine CIDR-Notification ist. Bei /32 verstehe ich ja noch, dass es sich um eine einzelne Adresse handelt, weil die Maske 255.255.255.255 ist. Aber bei /24 müsste es doch 192.168.178.0/24 heißen, weil es eine IP-Range ist, oder? (Wobei wohl wohl egal ist was als Host-IP angegeben wird.)

 

[DKeppi]

Meine CIDR im Heimnetz ist /24 also Netzmaske 255.255.255.0.
Alle Geräte in diesem Netz haben PiHole als DNS (über den DHCP bekommen) und der Zugriff klappt, außer von der Syno selbst, wo der Docker Container läuft. Nach meiner Logik gebe ich deswegen keine 0 sondern die 23 an, damit die Bridge nur für die Syno gilt.

Ob das jetzt wirklich korrekt ist kann ich nicht sagen, aber es funktioniert so
Die Syno hat zuvor sonst immer auf das 2. PiHole zugegriffen (welches eigentlich nur als Backup fungiert wenn die Syno mal neustartet oder Probleme machen würde), welches auf einem Zimaboard läuft.
Dort bestand dasselbe Problem und konnte ich ebenfalls über diesen Shellscript Workaround beim Booten lösen.