macvlan Zugriff auf den Host

[Solear]

Hallo,

mit der Netzwerktechnik macvlan kann man ja für seine Dockercontainer eigene IPs vergeben. Der Nachteil ist jedoch, dass man von dem Container nicht auf den Host zugreifen kann weil die physikalische Netzwerkschnittstelle (bei Synology eth0) mit dem macvlan gekoppelt ist.

Wie könnte man das trotzdem hinbekommen?
Es gibt für Debian eine Anleitung, wo man einfach die IP des Hostes auch in das macvlan packt. So "sehen" sich wieder alle und der Zugriff ist möglich.
Quelle: https://blog.wyraz.de/allgemein/docker-container-mit-eigener-statischer-lan-ip-ausfuehren/

Die Seite sagt:

auto eno1
iface eno1 inet manual

auto macvlan0
iface macvlan0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.254
dns-nameservers 192.168.1.254
pre-up ip link add link eno1 name macvlan0 type macvlan mode bridge

eno1 ist bei der Synology eth0.

Meint ihr, man kann das mit der Synology auch machen oder brickt es dann den DSM und ich muss alles ganz neu aufsetzen?
Die Einstellung gibt in dem Beispiel der physikalischen Netzwerkkarte eno1 keine IP mehr, stattdessen läuft das über macvlan.
Weiß jemand aus dem Kopf, in welcher Datei bei DSM die Netzwerkeinstellungen liegen?


Eine ALternative wäre, den zweiten LAN Port (eth1) ebenfalls mit dem Switch zu verbinden, eine zweite IP zu vergeben und macvlan quasi an die zweite Netzwerkkarte zu binden. Dann sollte der Zugriff vom Container zum Host (mit einem Umweg über den Switch) funktionieren, oder?

 

[haydibe]

Ohne den Link gelesen zu haben (Ich hasse es Links erst lesen zu müssen, um zu verstehen was gewollt ist) kann es sich dabei nur das erzeugen einer logischen Netwerzkkarte handeln, die dann als Parent-Interface für das macvlan verwendet. Aus Sicherheitsgründen darf ein Macvlan-Interface NICHT mit seinem Parent-Interface kommunizieren.

Um mit dem Host zu kommunizieren, muss vorher eine Bridge als Parent-Interface für das Docker Macvlan Netzwerk angelegt werden und dann verwendet werden.

ip link add mac link eth0 type macvlan mode bridge
ip addr add 100.98.26.38/24 dev mac0
ifconfig mac0 up

Man MUSS die IP vom eigentlich eht0 Interface nicht löschen. Die angelegt bridge ist flüchtig und muss nach jedem Restart des NAS neu erzeugt werden, bpsw. als Scheduled Task beim Start des NAS.

Siehe: https://collabnix.com/2-minutes-to-docker-macvlan-networking-a-beginners-guide/

 

[Solear]

Danke! Das hat tatsächlich geklappt. Wobei ich anstatt 100.98.26.38/24 meinen für Container reservierten Adressraum benutzt habe (192.168.1.240/28).
Steile Lernkurve habe ich

Vielen Dank!


PS: Für Anfänger wie mich ist dieser Link leichter zu verstehen:
https://collabnix.com/2-minutes-to-docker-macvlan-networking-a-beginners-guide/

 

[christofk]

Hi,
ich habe die gleiche Anleitung genutzt und komme nicht zum Ziel.
Zum einen heißt mein Interface ovs_eth0 (dieses Interface bekommt eine IP Adresse) - eth0 hat keine IP Adresse, zum anderen habe ich in einem parallel Thread gelesen, dass Macvlan und VMM (wegen openvswitch) nicht zusammen funktioniert.

Kann man mit meiner Konfiguration eine Docker<->Host Kommunikation mittels macvlan realisieren?

Für jeden Tip dankbar....
Christof

 

[Waldschrat]

Ich hab das so realisiert:
Im Portainer ein Netzwerk konfigurieren, driver "bridge".
Der Adressraum ist beliebig. Allerdings stellt die IP im Feld Gateway (in meinem Fall 172.20.10.11) die Verbindung zur Syno (Host) her.
Dann dem ioBroker-Container hinzufügen (das geht auch im laufenden Betrieb). Damit hab ich Zugriff auf MariaDB auf die ich Werte aus dem ioBroker ablege.

 

[haydibe]

Die oben beschriebene Nutzung adressiert eine andere Fragestellung.

Docker bindet ein Portmapping immer gegen alle Interfaces (egal ob physisch oder logisch) auf dem Host. Daher ist das verhalten keine große überraschung.
Wo soll hier der Mehrwert liegen?

 

[Waldschrat]

Der Nachteil ist jedoch, dass man von dem Container nicht auf den Host zugreifen kann weil die physikalische Netzwerkschnittstelle (bei Synology eth0) mit dem macvlan gekoppelt ist.

Wie könnte man das trotzdem hinbekommen?

Ich habe mich auf den Threadersteller bezogen, und da ich selbst kein Experte bin und viele Stunden verwenden musste um auf eine zufriedenstellende Lösung zu kommen, dachte ich es könnte helfen eine funktionierende Lösung aufzuzeigen. Ich hätte mich gefreut eine solche zu finden.

Die Erkenntnis, dass meine Antwort am Thema vorbeigehen soll entzieht sich meinen Fähigkeiten.

 

[haydibe]

Deine Lösung ignoriert den Kontext des Problems:
statt einer aus dem ganzen Netzwerk als Standalone-Gerät erkannten IP und MAC-Adresse verwendet Du eine Bridge, die nur dem NAS bekannt ist.

Ist im Endeffekt ist es aber auch wurscht: hauptsache Deine Lösung funktioniert für Dich und hilft ggf. anderen weiter.

 

[Freakk]

ip link add mac link eth0 type macvlan mode bridge
ip addr add 100.98.26.38/24 dev mac0
ifconfig mac0 up

Man MUSS die IP vom eigentlich eht0 Interface nicht löschen. Die angelegt bridge ist flüchtig und muss nach jedem Restart des NAS neu erzeugt werden, bpsw. als Scheduled Task beim Start des NAS.

Ich bekomme das mit dem Script irg. wie nicht gebacken. Wenn ich den Code in den Aufgabenplaner eingebe und zum Testen auf "Ausführen" gehe, werden die entsprechenden Einträge wohl schon gesetzt, aber ich kann keine IPs anpingen. Versuche ich den Code im Anschluss manuell via Terminal einzugeben, erhalte ich die Meldung, dass der entspr. Eintrag schon vorhanden ist. Wenn ich dann Docker neu starte und die exakt gleichen Befehle direkt ins Terminal eingeben funktioniert der Ping einwandfrei.

Was mache ich falsch?

 

[freddey]

http://www.stueben.de/iobroker-im-docker-auf-der-synology-diskstation-im-gleichen-subnet/

 

[Freakk]

Danke für den Link - funktioniert jetzt!

 

[Telefisch]

Ich hab das so realisiert:
Im Portainer ein Netzwerk konfigurieren, driver "bridge".
Der Adressraum ist beliebig. Allerdings stellt die IP im Feld Gateway (in meinem Fall 172.20.10.11) die Verbindung zur Syno (Host) her.
Dann dem ioBroker-Container hinzufügen (das geht auch im laufenden Betrieb). Damit hab ich Zugriff auf MariaDB auf die ich Werte aus dem ioBroker ablege.
Anhang anzeigen 50452

Anhang anzeigen 50453

Ich kapiere es einfach nicht.
Habe die gleiche Problematik, MariaDB auf dem Host zu erreichen.
Host Adresse ist 192.168.178.2, Docker-ioBroker ist 192.168.178.4.
Was muss ich in dei drei Felder eintragen?
Hab gefühlt alle sinnvollen Kombinationen durch aber ich finde irgendwie keine Lösung.

 

[plang.pl]

Hier gibs ein gutes Video dazu.

 

[Didi2505]

Ich nutze bei mir auf der NAS den NGINX Proxy Manager der einen MACVLAN Netzwerkadapter hat. Musste es bei mir mit folgendem Skript lösen.

Zum Verständnis mal beispielhaft die IP Adressen die ich verwende:

NGINX Proxy Manager: 192.168.1.205 (MACVLAN Netzwerkschnittstelle)
Für die Brücke: 192.168.1.210

Dieses Skript habe ich im Aufgabenplaner als Ausgelöste Aufgabe beim Hochfahren als Benutzer root hinzugefügt.

sleep 60
ip link add macvlan0 link NETZWERKADAPTER type macvlan mode bridge
ip addr add 192.168.1.210/32 dev macvlan0
ip link set macvlan0 up
ip route add 192.168.1.205 dev macvlan0

Den Netzwerkadapter kann man im Terminal mit "ifconfig" auslesen. Wenn man aber den Virtual Machine Manager nutzt wird dabei der Netzwerkadapter nicht "eth0" heißen, sondern "ovs_eth0". Liegt dabei an den Open vSwitch der für VMM benötigt wird.

Hoffe das kann den einen oder anderen helfen...

 

[haydibe]

Anmerkung: die IP 192.168.1.210 ist nicht die IP der Bridge, sondern die eines Macvlan Child-Netzwerkinterfaces.

Du fügst der Macvlan-Bridge (quasi ein logisches private Switch) ein neues Macvlan Child-Netzwerkinterface zu (Z2). Dann gibst du diesem Child-Netzwerkinterface eine IP (Z3), setzte sie auf aktiv (Z4) und fügst dann eine Route zur Erreichung der ip 192.168.1.205 über die Macvlan-Bridge zu (Z5).

Man Umgeht damit das Kernel-Sicherheitsfeature, welches verbietet das Macvlan Parent- und Child-Interfaces direkt miteinander kommunizieren können, in dem man dem Host ein zusätzliches Child-Netzwerkinterface verpasst das an dieselbe Macvlan-Bridge angeschlossen ist und deswegen nicht von dieser Einschränkung betroffen ist. Der Host nutzt es wegen der gesetzten Route automatisch, und wenn ein Container mit dem Host über die 192.168.1.210 spricht, dann ist er ebenfalls nicht davon betroffen. Was nach wie vor nicht geht ist das Macvlan Parent-Interface (ovs_eth0) über seine IP von einem Container aus zu erreichen,.

 

[Telefisch]

Ich hab in allen Tutorials und Tipps völlig verpeilt, dass der Portainer und seine bridge zum Host völlig andere IP Kreise haben und dass der Container sowohl dem Macvlan als auch der Bridge beitreten muss.
Läuft bei mir jetzt mit der Standard Bridge

 

[Didi2505]

Anmerkung: die IP 192.168.1.210 ist nicht die IP der Bridge, sondern die eines Macvlan Child-Netzwerkinterfaces.

War falsch ausgedrückt von mir. Ist ein Child-Netzwerkinterface aber ist ja irgendwie eine Brücke womit ich meine Container und andere Dienste erreiche. Hab lange Zeit herumexperimentiert und immer wieder ist irgendwas abgebrochen und das war jetzt die Lösung die bei mir ohne Probleme lief.

 

[Raabi]

Kann es sein das das ganze auswirkungen auf die bridge hat???

so weit geht alles als host oder mcvlan aber die container mit der bridge bekommen keine verbindungen zum internet

 

[EDvonSchleck]

Das MacVlan macht meiner Meinung mehr Fhler als es nutzt. Bei mir laufen 2 Container als "Host" der Rest in den Bridge-Netzwerken. Das ganze MacValan wird doch nur von ein paar Docker-Synology-Youtbe-Versteher mit Portainer gehypt. Einer davon hat sogar mitbekommen und liefert einen längeren Workaround dafür.

 

[plang.pl]

Verbindung zum Internet sollten die Container im MACVLAN haben. Nur eine Kommunikation mit dem Host ist nicht möglich. Prinzipiell bin auch ich kein Fan davon, alle Container in ein MACVLAN zu packen, nur weil man es kann. Bei manchen Containern macht es aber Sinn. Ich zum Beispiel nutze adguard und unbound auf einer DS. Beide nutzen Port 53. Das kann man dann entweder hinbasteln oder eben halt ein MACVLAN nutzen. Ich habe Letzteres gemacht, da ein Umbiegen der Ports bei DNS-Anfragen eher fehleranfällig ist. Der Workaround funktioniert aber sehr gut. Man muss nur eine Bridge "bauen" und dann kann der Host wieder mit den Containern reden und auch umgedreht.