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