Ja, genau das sage ich doch. Worin widerspricht jetzt dein Aussage meiner Aussage??
Ja, aber du hast von Problemen berichtet, die nicht sein können… Wenn du zwei unterschiedliche IPs und im Falle von Macvlan sogar zwei unterschiedliche MACs hast, kannst du keine Portkonflikte haben. Und wie meinst du das, das die Macvlans in der Docker-compose file erstellt werden? Die sollten immer statisch vorhanden sein und nur die Container drangehängt werden…
Und man legt auch normalerweise (unter normalem Docker, kann sein dass das wieder eine Sonderlocke von OMV ist) die Macvlans nicht per „ip link add“ an
Guten Morgen,
ich habe keine Probleme mit meinen laufenden Dockern mit MacVLAN. Ich hätte diese (Port-Konflikt-)Probleme nur, wenn ich MacVLAN nicht verwenden würde.
Es hat auch gute Gründe, wieso ich die MacVLAN in den Docker Compose Files definiere und nicht extern. Das hatte ich versucht und ist daran gescheitert, dass ein solches statisches MacVLAN nicht damit klarkommt, dass sich die IP-Adressen meines DSL-Anschlusses jede Nacht dynamisch ändern. Das Update zu IPV64 DynDNS lieferte immer falsche IP-Adressen. Ist wohl eine bekannte Einschränkung von Docker. Anyhow… Die Erfinder von Docker geben mir die Möglichkeit einen anderen Weg zu gehen also nutze ich diesen auch. Das ist aber wieder ein Off-Topic Thema.
Einzige Herausforderung meines Setups: Ich habe parallel zwei vollkommen voneinander unabhängige Docker Compose Setups mit zwei vollkommen voneinander unabhängigen MacVLAN. Beide sind im Netz der Fritz!Box unterwegs. Für eines der MacVLAN habe ich die IP-Adresse der Fritz!Box als Internet-Gateway angegeben. Leider erlaubt mir Docker nicht, diese IP-Adresse ein zweites Mal als Gateway für ein anderes MacVLAN zu verwenden.
Dafür hatte ich bisher mein „Workaround-Skript“ erstellt, um sowas wie ein zweites Gateway „künstlich“ zu erzeugen. Hat mir nie wirklich gefallen, hat aber jetzt gut ein Jahr prima funktioniert. (Wichtig: Das Skript hat nichts mit dem Anlegen der MacVLANs zutun!) Mit dem Umzug der MacVLAN hinter OpenWRT funktioniert das mit dem Skript nun nicht mehr. (Gründe sind ja bekannt. 
)
Also, meine einzige fundamentale Frage: Woher bekomme ich ein zweites Internet-IPv4-Gateway für mein zweites MacVLAN? (Aktuell im Netz der Fritz!Box, zukünftig dann im Netz von OpenWRT.)
That’s all…
Danke und Grüße
Mic.
Ich werde das heute Nachmittag erstmal testen, aber normalerweise geht das.
Sonst: ein zweites GW (was ja dieselbe MAC-Addresse haben muss) ist nicht mal so eben…
Und das zweite Script was du gepostet hast, setzt ja quasi einen Routing-Layer zwischen physischem Netzwerk und den Docker-CTs… Und wie, das hat nichts mit dem erstellen der Macvlans zu tun? Da wird doch in den 1. Zeilen bereits ein „ip link add macvlanB“ ausgeführt? Damit wird ein Macvlan erstellt
Ja, vergiss dieses Skript bitte. Das war doof. Es erzeugt noch ein MacVLAN nur um einen Gateway für ein bestehendes MacVLAN zu haben.
Aber ich verstehe nicht, warum du überhaupt 2 Macvlans brauchst…
Denn diese Geschichte mit dem falschen Updaten der IP bei IPv64 wird nicht am Macvlan liegen.
Aus Sicherheitsgründen: Ich möchte AdGuard Home nicht in dem gleichen VLAN laufen haben, wo ich meine Web-Dienste drin habe und umgekehrt.
Nein, es liegt nicht am MacVLAN selbst, sondern an der Art wie Docker sie als „statische, externe“ MacVLAN definiert/anlegt.
Tut aber bei meiner Frage auch nichts zur Sache: Docker bietet mir die Möglichkeit mehrere MacVLAN anzulegen. Ich habe diese Möglichkeit genutzt… und nun brauche ich für IPv4 zwei Gateway mit zwei IP-Adressen im gleichen Netz. Für IPv6 kann man komischerweise für mehrere MacVLAN die gleiche IPv6-Adresse als Gateway angeben.
Gibt es da eine intelligentere Möglichkeit als meine o.g. Skripte auf dem Host-PC?
Ähm, momentan bringt das gar nichts, weil du ja am Ende trotzdem im gleichen Netzwerk landest. Du hast ja nicht mehrere VLANs.
Hängen beide Macvlans auf derselben physischen Schnittstelle?
Ja, so richtig toll ist die Lösung echt nicht. Beide MacVLAN laufen über Eth.3 in meinem Bild vom Anfang.
Ich habe aber in OpenWRT eine elegantere Möglichkeit gefunden, die ich ausprobieren möchte. Man kann einer LAN-Schnittstelle (br-lan) zwei IPv4-Bereiche 192.168.xxx.1/24 zuweisen, wobei nur das erste in der Liste DHCP unterstützt. So habe ich mir jetzt einen IPv4-Bereich für den einen Docker mit MacVLAN und einen zweiten IPv4-Bereich für den zweiten Docker mit MacVLAN definiert. IPv6 habe ich erst einmal weggelassen. AdGuard Home (oder Pi-hole) als DNS kommen offensichtlich auch ohne IPv6-Anbindung in einem IPv4/IPv6-Heimnetz zurecht. Ich hoffe, dass Docker die beiden Gateways akzeptiert.
Ich habe jetzt erst einmal meinen Windows-Laptop dran gehängt. Er kommt über beide Gateways ins Internet. Und in meiner Fritz!Box habe ich zwei statische Route zu den Gateways definiert. So kann ich sie auch aus dem Netz der Fritz!Box anpingen.
Also das mit diesen beiden Macvlans für angebliche Trennung, die dann auch noch auf dem gleichen Interface, wo es gar nicht getrennt werden kann und sowieso im gleichen Netz landet. Das ist unlogisch deine Begründung und du machst dir das Leben viel komplizierter wie du merkst
Jupp. Habe ich gemerkt… aber wieder so eine Sache: Es läuft gut so, wie es ist und ich möchte beides aktuell nicht vermischen.
Meine Idee beide in einen anderen IPv4-Bereich als Gateway zu stecken, müsste die Sache doch vereinfachen und auch „sinnvoller“ machen. Müsste doch funktionieren… oder?
Ich verstehe nur jetzt nicht ganz, wieso ich in Docker mehrere MacVLAN separat definieren kann, die aber dann am Ende doch ein VLAN sind. 
Du hast, glaube ich, Macvlans insgesamt nicht verstanden
Die Dinger machen nicht automatisch VLAN nur weil sie so heißen…
Das muss man entsprechend konfigurieren und das geht auch nur wenn man an der anderen Seite des physischen Ports wiederum Hardware hat, die auch VLANs (802.1Q) versteht.
Deswegen sage ich ja die ganze Zeit, es ist keine wirkliche Trennung da, die du haben willst… Also kannst du dir dieses Geraffel und Verkomplizierung auch sparen
Ja, gut so richtig ist das nicht isoliert. Da bräuchte ich dann auf beiden Seiten einen Switch/Router, der das VLAN entgegen nimmt. Es ist halt das VLAN-Gedöns, was mir Docker bietet.
Ein paar Vorteile sehe ich trotzdem:
- Meine Docker-Container bekommen eigene IP-Adressen
- Ich habe keine Port-Konflikte (gerade Port
:53hat sich OMV7 selbst geblockt und so brauche ich das MacVLAN für AdGuard Home) - Ich kann (in der Fritz!Box) dediziert Ports für die Web-Dienste freigeben (da eigene IP-Adresse und eigene MAC-Adresse)
- Es isoliert meine Web-Dienste im Docker vom Host-PC
Das was Docker dir bietet hat nichts mit VLANs im klassischen Sinne zu tun…
Aber die Punkte, die du gesagt hast, sind ja auch richtig, aber da du ja sowieso es nicht wirklich getrennt hast, würde ich vorschlagen, bevor das alles nicht vernünftig mit dem OpenWRT und einem Macvlan läuft, erstmal das zweite (welches ja überflüssig ist) liegen zu lassen
Ja, dass das, was Docker als MacVLAN anbietet, kein VLAN ist, wie man es in einem kompletten Netzwerk machen würde, ist sogar mir klar. 
Ich denke, ich bleibe aber jetzt trotzdem mal bei meinen zwei Docker Compose Containern, die je eine eigene MacVLAN-Definition (was auch immer das richtige Wort dafür ist) beinhalten. Es läuft ja momentan gut und das möchte ich dann 1:1 auf das Setup mit OpenWRT übertragen. Zumindest für IPv4 bietet mir OpenWRT ja eine sehr komfortable Möglichkeit, ein zweites Netz (192.168.xxx.1/24) was auch immer das richtige Wort dafür ist) bereitzustellen.
Wenn du meinst, dass das hilft 
Es wird komplizierter ohne Nutzen. Aber: Deine Sache
Ich sehe nach wie vor Nutzen für mich. Das System läuft so gut ein Jahr stabil und reproduzierbar. Wenn ich dir jetzt sagen würde: Mach alles anders! würdest du das auch nicht über den Haufen werfen.
Ich habe heute einen ganz guten Teilerfolg geschafft. Ich habe testweise in einem Docker mit einem IP-Netz an OpenWRT AdGuard Home als DNS zum Laufen gebracht und in einem zweiten Docker mit einem zweiten IP-Netz hinter OpenWRT meine Web-Dienste zum Laufen gebracht.
In OpenWRT habe ich eingestellt, dass OpenWRT ein IPv6-Präfix /62 an die nachgeschalteten Geräte delegiert. Was ich nicht wusste: Man kann in Docker MacVLAN solch ein delegiertes Präfix nutzen und daraus ein weiteres Sub-Netz erzeugen. So konnte ich beiden MacVLAN einen eigenen IPv4-Gateway und einen eigenen IPv6-Gateway zuordnen, was die MacVLAN wirklich trennt. Außerdem musste ich AdGuard Home per IPv6 erreichbar machen, da mein China-Handy ohne einen DNSv6 den Dienst verweigert.
Das sieht dann sinngemäß so aus:
# Docker MacVLAN AdGuard Home
IPv4-Gateway: 192.168.xxx.1/24
IPv6-Gateway: fe85:abcd_cdba:x::/64
# Docker MacVLAN Web-Dienste
IPv4-Gateway: 192.168.yyy.1/24
IPv6-Gateway: fe85:abcd_cdba:y::/64
Über die lokalen IP-Adressen sind die einzelnen Dienste (soweit sie es aus Sicherheitsgründen zulassen) damit erreichbar. Das DnyDNS-Update bei IPV64.net hat damit auch funktioniert. Es werden Adressen aus dem IPv6-Subnetz fe85:abcd_abcd:y::/64 an IPV64.net gesendet.
Jetzt musste ich aber erst einmal aufhören, weil ich die Portfreigaben in OpenWRT nicht hinbekommen habe. Sobald ich eine Freigabe für Port :443 darin einrichte, stürzt die OpenWRT-Firewall ab und OpenWRT ist nicht mehr erreichbar. Das habe ich als Frage im OpenWRT-Forum gepostet.
Schauen wir mal weiter…
Danke und Grüße
Mic.
Du hast glaube ich nicht verstanden, was Netztrennung bedeutet…
Aber ich blicke auch langsam nicht mehr durch mit diesem Hin und her da