ARP Broadcast aus MAC VLAN

[kingkong66]

Geschätzte Experten, ich habe folgende Herausforderung:

Mehrere NAS im Netzwerk.
NAS1 mit IP 192.168.5.137 hat ein Host Netzwerk 192.168.5.0/24 mit defaultGateway 192.168.5.1 (meine Fritzbox)
NAS2 mit IP 192.168.5.50 hat ein Host Netzwerk 192.168.5.0/24 mit defaultGateway 192.168.5.1 (meine Fritzbox)
Mittels Pontainer habe ich auf NAS 2 ein MACVLan erstellt 192.168.5.208/28 mit defalt Gateway 192.168.5.1 (meine Fritzbox)
Ins MACVLan habe ich einen NGinx Container gestellt, welcher auf die IP 192.168.5.210 hört. Dieser ist im NEtzwerk Ping-bar
Die auf der Fritzbox gegen extern Internet freigegebenen Ports 80 und 443 zeigen auf den Nginx Container auf NAS2. Dort kann ich Lets Encrypt Zertifikate erstellen. Funktioniert grundsätzlich.
Auf NAS1 läuft ein Container1 welcher seine Dienste unter Port 6669 anbietet.
Im NGinx Container kann ich nun auch einen Proxy Host erstellen welcher auf Container1 zeigt. Funktioniert. Ist von extern mittels Https erreichbar
Auf NAS1 läuft ein Container2 welcher seine Dienste unter Port 6669 anbietet. (Dieselbe Funktion wie Container1).
Container2 ist im Host Netz unter http://192.168.5.50:6669/ problemlos erreichbar.
Wen ich nun auf dem NGinx Container "umschalte" und den Container2 gegen extern zugänglich machen will, dann funktioniert dies nicht. "502 Bad Gateway" erscheint.
Der NGinx Container kann den Service im Container2 nicht finden. Den Service im Container1 findet er.
Wenn ich im Netwerk "sniffe" dann fällt mir auf, dass der NGinx Container andauernd ARP Broadcast für die IP 192.168.5.50 aussendet. Jedoch sehr ich nirgends Antworten?

Habe ich en VLAN-Problem, welches ARP Broadcast in mein MACVLan verhindert?
Was muss ich machen um die Netze "ARP-mässig" zu koppeln?

Merci für Feedack

 

[JohneDoe]

Hast du nur MACVLAN eingerichtet? MACVLAN verbietet von Haus die Kommunikation von Host zu Container. Du müsstest ein Bridge einrichten, die genau dies erlaubt. Dies muss bei jedem Boot passieren.

 

[haydibe]

Was hat

Wenn ich im Netwerk "sniffe" dann fällt mir auf, dass der NGinx Container andauernd ARP Broadcast für die IP 192.168.5.50 aussendet. Jedoch sehr ich nirgends Antworten?

Pack nginx mal zusätzlich in ein Docker Bridge Network - dann sollte er über dieses Interface auch mit dem Host kommunizieren können und auch mit anderen Containern die im selben Container-Netzwerk sind.

Afaik, funktioniert Service Discovery auch nur mit Bridge (bei Swarm auch Overlay) Netzwerken, und nicht mit MACVLAN.

Ohne nginx zusätzlich an ein Docker-Bridge-Netzwerk zu hängen, wird es selbst mit dem Workaround den @JohneDoe beschreibt, nicht möglich sein, dass ein MACVLAN Kind-Interface (=192.168.5.210) mit der IP des MACVLAN Eltern-Interfaces (=192.168.5.50) kommuniziert.

Dieser Teil ist unklar:

Auf NAS1 läuft ein Container1 welcher seine Dienste unter Port 6669 anbietet.
Im NGinx Container kann ich nun auch einen Proxy Host erstellen welcher auf Container1 zeigt. Funktioniert. Ist von extern mittels Https erreichbar
Auf NAS1 läuft ein Container2 welcher seine Dienste unter Port 6669 anbietet. (Dieselbe Funktion wie Container1).
Container2 ist im Host Netz unter http://192.168.5.50:6669/ problemlos erreichbar.
Wen ich nun auf dem NGinx Container "umschalte" und den Container2 gegen extern zugänglich machen will, dann funktioniert dies nicht. "502 Bad Gateway" erscheint.

Wenn Container1 und Container2 beide auf NAS1 laufen, was hat das mit dem MACVLAN von NAS2 zu tun?
Und warum ist dann einer der beiden Container über die IP von NAS2 erreichbar?

 

[JohneDoe]

es selbst mit dem Workaround den @JohneDoe beschreibt, nicht möglich sein, dass ein MACVLAN Kind-Interface

Oh, sorry MACVLAN ist nicht mein Steckenpferd, weil ich der Meinung bin, dass es mehr Probleme bringt als es nutzt. Also in den meisten Fällen. Danke für den Hinweis.

 

[kingkong66]

Hast du nur MACVLAN eingerichtet? MACVLAN verbietet von Haus die Kommunikation von Host zu Container. Du müsstest ein Bridge einrichten, die genau dies erlaubt. Dies muss bei jedem Boot passieren.

NGinx hat nebst dem MACVLAN auch noch ein Bridge Netzwerk um mit seiner Datenbank kommunizieren zu können. Der Hinweis, dass MACVLan die Kommunikation von Host zu Container verbietet ist gut. Wusste ich nicht. Danke!

 

[kingkong66]

Pack nginx mal zusätzlich in ein Docker Bridge Network - dann sollte er über dieses Interface auch mit dem Host kommunizieren können und auch mit anderen Containern die im selben Container-Netzwerk sind.

Nginx hat nebst dem MACVLan auch noch ein Bridge Netzwerk, damit es seine DB findet. Dies ist vermutlich nicht die Lösung. (Insgesammt habe ich ein Dutzend Container und einige Raspery Pi's welche ich über den nginx ins Internet freigeben will)

 

[haydibe]

Das war nicht ganz richtig formuliert von mir: es ist natürlich nicht MACVLAN was er verbietet, sondern es sind Sicherheitsfunktionen des Linux-Kernels, die die direkte Kommunikation zwischen Kind<->Eltern Interfaces bei MACVLAN/IPVLAN verbietet. Docker erbt das Verhalten nur

 

[JohneDoe]

Ach Moment mal... Das meinte ich ja, dass es deshalb nicht geht. Mit Bridge meinte ich nicht das Docker Netzwerk Bridge sondern ein script um das zu umgehen. Sowas hier: https://discourse.nixos.org/t/help-...-systemd-one-time-script-docker-macvlan/71333

 

[haydibe]

Mir ist klar was Du meinst: Eine Bridge als zusätzliches MACVLAN-Kind Interface (bspw. mit IP 192.168.5.x) auf dem Host anlegen und darüber die Route zur MACVLAN IP-Range erreichbar machen. Damit kann der Host über sein neues MACVLAN-Kind Interface mit den MACVLAN-Kind Interfaces der Container kommunizieren.

Was nach wie vor nicht geht, ist das die MACVLAN-Kind Interfaces (der Container) direkt mit einer IP des MACVLAN-Eltern Interfaces des Hosts kommunizieren können. Sprich: ein MACVLAN Container wird mit der IP 192.168.5.50 trotzdem nicht kommunizieren können. Er kann jetzt aber mittel MACVLAN-Kind Interfaces des Hosts mit der IP 192.168.5.x kommunizieren.

 

[haydibe]

Dies ist vermutlich nicht die Lösung. (Insgesammt habe ich ein Dutzend Container und einige Raspery Pi's welche ich über den nginx ins Internet freigeben will)

Für welches Problem genau? Könntest Du noch auf die Fragen meiner ersten Antwort eingehen. Das genaue Problem ist (mir zumindest) noch nicht klar.

 

[JohneDoe]

Ah ok.... Sag ja, macht mehr Probleme als es einem nützt
Danke noch mal für das genaue erklären. Ich dachte wir hätten da vielleicht mit dem Bridge ein Missverständnis.

 

[kingkong66]

Hast du nur MACVLAN eingerichtet? MACVLAN verbietet von Haus die Kommunikation von Host zu Container. Du müsstest ein Bridge einrichten, die genau dies erlaubt. Dies muss bei jedem Boot passieren.

Genau dieses Verhalten konnte ich nun nachvollziehen. Ich habe mein altes macvlan gelöscht und ein neues erstellt. Diesmal deckungsgleich mit dem Heimnetz. Dann habe ich einen neuen container3 in dieses maclan gesetzt. Ergebnis: Ping von meinem Arbeitsgerät auf diesen container3 funktioniert. ping ab dem docker Host, welcher macvlan und container 3 beinhaltet geht NICHT! ("From 192.168.5.50 icmp_seq=16 Destination Host Unreachable").
Heisst mit macvlan kriege ich so keine Lösung hin.
==> Ich werde mich mal einlesen ob overlay etwas bringt. (kenne ich überhaupt nicht)
==> oder jemand von euch weiss eine Lösung

P.S. Meine macvlan baue ich jewels nach der Anleitung https://www.youtube.com/watch?v=mARLVbJcsmY

 

[JohneDoe]

Brauchst du denn unbedingt MACVLAN?
Wenn du es nur für den Reverse Proxy brauchst, wieso richtest du dir nicht eine kleine Debian VM ein? Dann brauchst du kein MACVLAN, musst keine Ports verbiegen und es läuft alles direkt. Und du hast eine stärkere Isolation.

 

[haydibe]

==> Ich werde mich mal einlesen ob overlay etwas bringt. (kenne ich überhaupt nicht)

Das wird dir auch nichts bringen. Docker Overlay Netzwerke erlaube Swarm Cluster-Node-übergreifende Netzwerke zu definieren. Auf einem einzelnen Host, hätte es keine Vorteile gegenüber einem Docker Bridge Netzwerk. Hätte weil ich mir nicht sicher bin, ob es ohne aktivierten Swarm Mode überhaupt nutzbar ist.

Ich warne ausdrücklich davor einen zwei Node Docker Swarm Cluster zu nutzen, da der Ausfall eines Nodes den Cluster verweisen lässt.

 

[kingkong66]

Brauchst du denn unbedingt MACVLAN?
Wenn du es nur für den Reverse Proxy brauchst, wieso richtest du dir nicht eine kleine Debian VM ein? Dann brauchst du kein MACVLAN, musst keine Ports verbiegen und es läuft alles direkt. Und du hast eine stärkere Isolation.

wäre eine Idee. Danke

 

[kingkong66]

Es gibt eine Lösung wie ich mein macvlan mit dem Host koppeln kann (wenn man denn unbedingt will):

IP des zu koppelnden containers 192.168.5.210. Dieser läuft im macvan mac0

- Mit SSH auf der Synology einstloggen
- sodu -i
auf der Synology eine Bridge-Koppelung eingeben:
(spezialdevice mac1 mit derselben Adresse wie mein Container plus route auf mein macvlan mac0)

ip link add mac1 link eth0 type macvlan mode bridge
ip addr add 192.168.5.210/32 dev mac1
ip link set mac1 up
ip route add 192.168.5.208/28 dev mac1

Die Anleitungen unter https://www.synology-forum.de/threads/macvlan-zugriff-auf-den-host.103178/ und http://www.stueben.de/iobroker-im-docker-auf-der-synology-diskstation-im-gleichen-subnet/ haben bei mir auf der 723+ mit DSM 7.3..... nicht mehr richtig funktioniert. Mit mit meinem Befehlssatz war IP 192.168.5.210 sowohl vom Host, als auch vom ArbeitsPC aus pingbar.

Diese Anpassungen verschwinden mit jedem reboot. Heisst ich muss noch ein Script "basteln" welches diesem Befehlssatz bei jedem reboot wieder neu durchführt

root@NAS723:~# ip route
default via 192.168.5.1 dev eth0 src 192.168.5.50
192.168.5.0/24 dev eth0 proto kernel scope link src 192.168.5.50
192.168.5.208/28 dev mac1 scope link
root@NAS723:~# ping 192.168.5.210
PING 192.168.5.210 (192.168.5.210) 56(84) bytes of data.
64 bytes from 192.168.5.210: icmp_seq=1 ttl=64 time=0.025 ms
64 bytes from 192.168.5.210: icmp_seq=2 ttl=64 time=0.036 ms

 

[haydibe]

Es gibt eine Lösung wie ich mein macvlan mit dem Host koppeln kann (wenn man denn unbedingt will):

Du hast jetzt die Befehle zu dem gepostet, über das wir uns hier schon die ganze Zeit unterhalten haben Gut, dass es jetzt auch hier direkt zu finden ist.

Mit mit meinem Befehlssatz war IP 192.168.5.210 sowohl vom Host, als auch vom ArbeitsPC aus pingbar.

Warum sollte das auch nicht gehen? Der Host besitzt das Interface mit der IP und verwendet es direkt, da geht nix über die MACVLAN-Eltern IP. Das die IP von anderen Geräten und auch den MACVLAN-Containern erreichbar ist, ist auch klar. Was nach wie vor nicht geht: das ein MACVLAN-Container mit der MACVLAN-Eltern IP 192.168.5.50 kommunizieren kann.

 

[JohneDoe]

Mit einer VM wärst du schon fertig und könntest alles so nutzen wie du es wolltest

 

[haydibe]

... ich bin auch null Fan von MACVLAN.

In meinem Berufsleben habe ich noch nie erlebt, dass in irgendeinem Projekt/Verfahren mit MACVLAN oder IPVLAN gearbeitet worden wäre.

 

[JohneDoe]

Das finde ich sehr interessant. Ich hab gedacht, dass es vielleicht im professionellen Umfeld mehr genutzt wird. Gerade wegen der Isolierung....
Ich komme aus der Software Ecke und da haben wir auch noch nie einen Grund gehabt das zu nutzen. Es geht alles leichter und schneller ohne MACVLAN.