Mikrotik - Ubuntu Server VLAN - Docker mit macvlan
Hallo zusammen,
Ich bin gerade etwas ratlos wie ich mein Vorhaben umsetzen kann.
Auf dem Mikrotik habe ich zwei VLANs angelegt mit ID 20 (Adresse 172.16.20.1) und 30 (Adresse 172.16.30.1).
Diese beiden IPs leite ich an einen Ubuntu Server weiter, der dort ebenfalls die beiden VLANs konfiguriert hat.
ID20: 172.16.20.2
ID30: 172.16.30.2
Im Docker auf dem Ubuntu-Server habe ich jetzt macvlans angelegt:
VLAN20: Network 172.16.20.0/24 Gateway 172.16.20.1
VLAN30: Network 172.16.30.0/24 Gateway 172.16.30.1
und zwei Test-Container hinzugefügt:
Container 1: VLAN 20 IP: 172.16.20.100
Container 2: VLAN 30 IP: 172.16.30.100
Allerdings kommen jetzt logischerweise alle Anfragen an den Mikrotik-Router mit "Unknown" rein, weil dieser ja nicht weiß was mit den IP-Adressen anzufangen ist.
Wie muss ich das konfigurieren, dass der Router die IP-Adressen der Container kennt?
Geht das überhaupt?
Ich bin gerade etwas ratlos wie ich mein Vorhaben umsetzen kann.
Auf dem Mikrotik habe ich zwei VLANs angelegt mit ID 20 (Adresse 172.16.20.1) und 30 (Adresse 172.16.30.1).
Diese beiden IPs leite ich an einen Ubuntu Server weiter, der dort ebenfalls die beiden VLANs konfiguriert hat.
ID20: 172.16.20.2
ID30: 172.16.30.2
Im Docker auf dem Ubuntu-Server habe ich jetzt macvlans angelegt:
VLAN20: Network 172.16.20.0/24 Gateway 172.16.20.1
VLAN30: Network 172.16.30.0/24 Gateway 172.16.30.1
und zwei Test-Container hinzugefügt:
Container 1: VLAN 20 IP: 172.16.20.100
Container 2: VLAN 30 IP: 172.16.30.100
Allerdings kommen jetzt logischerweise alle Anfragen an den Mikrotik-Router mit "Unknown" rein, weil dieser ja nicht weiß was mit den IP-Adressen anzufangen ist.
Wie muss ich das konfigurieren, dass der Router die IP-Adressen der Container kennt?
Geht das überhaupt?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667847
Url: https://administrator.de/contentid/667847
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
36 Kommentare
Neuester Kommentar
alle Anfragen an den Mikrotik-Router mit "Unknown" rein, weil dieser ja nicht weiß was mit den IP-Adressen anzufangen ist.
Das ist unsinnig. Warum sollte, er deiner Meinung, nicht wissen was er damit anfangen soll??Beides sind doch IP Adressen aus Netzen die direkt an ihm selber angeschlossen sind. Er weiss also durch diese direkt Verbindung sehr wohl was er damit anfangen soll!
Um eine Kommunikation im gleichen L2 Netz aufbauen zu können muss der Mikrotik, wie auch alle anderen Router auf der Welt, die Mac Adresse des Endgeräts kennen das mit ihm im gleichen Netz ist. Dazu ARPt der Mikrotik ins Netz mit einem Broadcast an alle und damit auch an deine beiden Containerhosts 172.16.20.100 und 172.16.30.100. Diese empfangen den ARP Request Broadcast, erkennen ihre IP und antwortem dem Mikrotik mit einem ARP Reply und ihren Mac Adressen. Daraufhin startet der Mikrotik dann den Datentransfer im Netz zum Endgerät.
Ein klassisches Verhalten im Layer 2 wie bei Milliarden anderen Endgeräten auch.
Wie kommst du also zu deiner o.a. Behauptung bei direkt am MT angeschlossenen IP Netzen?? 🤔
Man kann hier nur vermuten das deine interne Layer 2 Kommunikation also das Bridging zw. Host und Containern etc. falsch oder fehlerhaft ist so das die Container keine L2 Kommunikation zum entsprechenden VLAN haben. Hier solltest du also sinnvollerweise mal ansetzen statt unnötigerweise am Mikrotik zu suchen.
Das dann eine Netz Verbindung scheitert muss einen dann nicht groß wundern!
Ob deine VLAN Setups generell korrekt sind kannst du im Mikrotik VLAN Tutorial und auch im Host VLAN Tutorial nachkontrollieren. Da entsprechende Hostkonfigs und Router Setups hier fehlen kann man nur frei raten.
docker network create -d macvlan \
--subnet=172.16.20.0/24 \
--gateway=172.16.20.1 \
-o parent=eth0.20 macvlan20
docker network create -d macvlan \
--subnet=172.16.30.0/24 \
--gateway=172.16.30.1 \
-o parent=eth0.30 macvlan30
Gruß
Dann ist deine Config fehlerhaft. Wir kennen weder deine Ubuntu Config noch die deines Mikrotik.
Klappt hier im Test einwandfrei, Config folgt.
Klappt hier im Test einwandfrei, Config folgt.
Mikrotik Setup (nur der relevante Teil für die VLANs, ohne Bridge)
# vlan ifs erstellen
/interface vlan add name=vlan20 vlan-id=20 interface=ether2
/interface vlan add name=vlan30 vlan-id=30 interface=ether2
# IP-Adressen zuweisen
/ip address add address=172.16.20.1/24 interface=vlan20
/ip address add address=172.16.30.1/24 interface=vlan30
Mikrotik Setup falls auf dem Mikrotik eine VLAN-Bridge aktiv ist dann so
# vlan ifs erstellen
/interface vlan add name=vlan20 vlan-id=20 interface=bridge-local
/interface vlan add name=vlan30 vlan-id=30 interface=bridge-local
# IP-Adressen zuweisen
/ip address add address=172.16.20.1/24 interface=vlan20
/ip address add address=172.16.30.1/24 interface=vlan30
# Port zur Bridge hinzufügen
/interface bridge port add bridge=bridge-local interface=ether2
# VLANs auf dem Port in der bridge taggen
/interface bridge vlan add bridge=bridge-local tagged=bridge-local,ether2 vlan-ids=20
/interface bridge vlan add bridge=bridge-local tagged=bridge-local,ether2 vlan-ids=30
Generic Linux Setup
# vlans anlegen
ip link add link eth0 name eth0.20 type vlan id 20
ip link add link eth0 name eth0.30 type vlan id 30
ip link set eth0.20 up
ip link set eth0.30 up
# Docker networks anlegen
docker network create -d macvlan \
--subnet=172.16.20.0/24 \
--gateway=172.16.20.1 \
-o parent=eth0.20 macvlan20
docker network create -d macvlan \
--subnet=172.16.30.0/24 \
--gateway=172.16.30.1 \
-o parent=eth0.30 macvlan30
# test container im Network macvlan20 mit IP 172.16.20.10 starten, darin kannst du dann das entsprechende Gateway erfolgreich pingen, anderes Netzwerk dito ...
docker run --rm --name macvlantest -ti --network macvlan20 --ip 172.16.20.10 alpine /bin/sh
Zitat von @Thor2605:
Danke schön dann probiere ich das mal.
Hatte mich im netplan versucht, aber das scheint irgendwie nicht so ganz zu klappen.
Bzw. mach ich da was falsch und weiß nicht was...
Das ist auch nicht schwer dort mehrere VLANs auf ein Interface zu packen ...Danke schön dann probiere ich das mal.
Hatte mich im netplan versucht, aber das scheint irgendwie nicht so ganz zu klappen.
Bzw. mach ich da was falsch und weiß nicht was...
network:
version: 2
ethernets:
ens33:
dhcp4: true
vlans:
vlan.20:
id: 20
link: ens33
vlan.30:
id: 30
link: ens33
Korrigiert. Danke.
Zitat von @Thor2605:
Ich glaube mein Fehler war den vlans im netplan noch eigene IP Adressen zu geben und auf das gateway zu routen?
Das ist irrelevant ob du da eine IP drauf bindest oder nicht, nötig sind sie nicht. Das MACVLAN wird ja quasi physisch auf das VLAN-Interface gemappt und kommuniziert direkt auf Layer-2 des VLAN-Interfaces, der Host ist so also nicht in die IP-Kommmunikation der Container involviert, der Container nutzt eine eigene MAC.Ich glaube mein Fehler war den vlans im netplan noch eigene IP Adressen zu geben und auf das gateway zu routen?
Da der Traffic schon von der falschen Absender-IP kommt liegt das Problem schon auf dem Ubuntu. Du hast vermutlich eine fehlerhafte SRC NAT Regel auf dem Ubuntu welche sämtlichen Traffic auf die 172.16.1.100 ausgehend NATed
Btw. hier stimmt die Zuweisung zu den Zonen nicht, alles WAN ...
/interface list member
add interface=vlan-10-NAS list=WAN
add interface=vlan-50-Home list=WAN
add interface=vlan-60-Gast list=WAN
add interface=vlan-70-Entertainment list=WAN
add interface=vlan-91-IoT-Web list=WAN
add interface=vlan-20-Docker-Infrastruktur list=WAN
add interface=vlan-30-Docker-Security list=WAN
add interface=vlan-40-Docker-HomeAutomation list=WAN
add interface=vlan-55-Sonos list=WAN
add interface=vlan-80-Docker-Apps list=WAN
Zitat von @Thor2605:
Das sind die VLANs die erst mal auf den Uplink ins Internet dürfen... Oder hab ich da was falsch verstanden?
Wenn du die Default-Listen nutzt ja, dann ist "WAN" nur für echte WAN-Ports und "LAN" für LAN-Ports gedacht.Das sind die VLANs die erst mal auf den Uplink ins Internet dürfen... Oder hab ich da was falsch verstanden?
Dachte damit kann ich Listen definieren, die dann als Firewall Input-List verwendet werden können...
So ist es ja auch.
Schau dir die IPs der Container auf der Konsole an indem du dich direkt per interaktivem Terminal in die Container schaltest ...
Vergleiche auch mal die MAC Adressen aus dem Mikrotik LOG mit denen auf dem Ubuntu Server. Die Container sollten eigene MAC Adressen nutzen (auch per Terminal direkt in die Container schauen und per
Hast du die macvlan Netzwerke überhaupt den Containern korrekt zugewiesen?
Strategisch vorgehen dann findest du den Übeltäter.
Firewalls sollte man bei der Fehlersuche immer erst mal auf Durchzug schalten um diese ausschließen zu können.
ip a
zeigen lassen)!Hast du die macvlan Netzwerke überhaupt den Containern korrekt zugewiesen?
Strategisch vorgehen dann findest du den Übeltäter.
Firewalls sollte man bei der Fehlersuche immer erst mal auf Durchzug schalten um diese ausschließen zu können.
Ist eventuell die default Route schuld?
Nein, innerhalb von den Containern wird automatisch das GW gesetzt das im jeweiligen Docker-Netzwerk angegeben ist. Du scheinst das MACVLAN-Prinzip noch nicht ganz verstanden zu haben wenn du das fragst. Bei einem MACVLAN bekommt der Container eine eigene MAC-Adresse mit der er direkt am physischen parent Interface des HOSTs eingehängt wird somit hat der HOST selbst nichts mehr mit dem IP-Forwarding des Containers zu tun, das macht der Container dann direkt über Layer-2.Wie gesagt per Terminal direkt in den Container verbinden und nachschauen ...
Und vor allem erst mal das Prinzip und die Voraussetzungen von MACVLAN verstehen
https://docs.docker.com/engine/network/drivers/macvlan/
Hab testweise die Routen zu den einzelnen VLAN Interfaces in Ubuntu zugewiesen
Never ever do this, der Host kennt auf im angelegte VLANs selbst somit Bullshit hier Routen zu erstellen ...Ist eventuell die default Route schuld?
Du meinst die von Ubuntu und seinen Containern?Nein, die kann es nicht sein. Zumal es dort ja auch keinerlei "Routen" in dem Sinne gibt, denn der Server hängt ja direkt am MT und seinen Netzen. Geroutet werden muss da also nix! Wenn überhaupt gibts da nur nur Default Gateways bzw. eine Default Route.
Und auch nur DIE sind relevant!
Bei den Containern zeigen die immer auf die MT IP Adresse im jeweiligen VLAN in dem sie betrieben werden. Das sollte dann logischerweise auch immer anpingbar sein!
Hab testweise die Routen zu den einzelnen VLAN Interfaces in Ubuntu zugewiesen
Das ist falsch und kontraproduktiv, also besser wieder löschen. Es gibt keine spezifischen Routen dort sondern einzig nur die Default Route.Die Container und auch der Server sind ja im Layer 2 direkt am MT und seinen Netzen dran folglich müssen die Container auch immer vom MT und vice versa pingbar sein.
Allerdings bekomme ich nichts zurück.
Firewall ist was?? Dein Mikrotik?Wenn ja ist das nicht weiter verwunderlich, denn da gibts laut deiner Schilderung ja nur die 2 IP VLANs .20.0 und .30.0. 🤔
Aber auch wenn solltest du den goldenen Rat von oben befolgen: "Firewalls sollte man bei der Fehlersuche immer erst mal auf Durchzug schalten um diese ausschließen zu können!!"
Zitat von @Thor2605:
Dann sollte ich doch eigentlich den Ping von meinem Docker-Container an meinen Laptop durch bekommen oder warum bekomme ich da keine Antwort?
Dann sollte ich doch eigentlich den Ping von meinem Docker-Container an meinen Laptop durch bekommen oder warum bekomme ich da keine Antwort?
Klassiker, die Windows Firewall blockt per Default ICMP aus fremden Subnetzen, also das erst mal freischalten...
Zitat von @Thor2605:
Danke das muss man wissen....
Vielen Dank läuft jetzt alles, aber leider ohne traefik.
Sobald ich das proxy-netzwerk (Bridge, 172.18.0.0/16) zu meinem Home-Assistant-Docker Container hinzufüge läuft alles unter VLAN ID 1.
Aber ehrlich gesagt verstehe ich nicht warum das passiert.
Hast mir da auch eine Idee?
Danke das muss man wissen....
Vielen Dank läuft jetzt alles, aber leider ohne traefik.
Sobald ich das proxy-netzwerk (Bridge, 172.18.0.0/16) zu meinem Home-Assistant-Docker Container hinzufüge läuft alles unter VLAN ID 1.
Aber ehrlich gesagt verstehe ich nicht warum das passiert.
Hast mir da auch eine Idee?
RTFM ist da wie immer dein bester Ratgeber
Restrict the Scope of Service Discovery
Restrict the Scope of Service Discovery¶
By default, Traefik creates routes for all detected containers.
If you want to limit the scope of the Traefik service discovery, i.e. disallow route creation for some containers, you can do so in two different ways:
the generic configuration option exposedByDefault,
a finer granularity mechanism based on constraints.