Unraid möchte in fremden Gateway / Netzwerk problem

[EliteGroup]

Hey Leute,
ich versuche gerade mein Netzwerk in Unraid einzurichten und bin auf folgendes Problem gestoßen:

Ich habe 2 Netzwerke diese in Unraid auch eingerichtet:
LAN (192.168.1.1/24) via eth0
DMZ (192.168.2.1/24) via eth1

 

Unraid betreibe ich ohne Probleme im LAN.
Jetzt möchte ich bestimmte Docker Container im DMZ Netzwerk betreiben.

Im Container hab ich "Netzwerktyp: Custom eth1" gewählt und eine freie IP zugewisen.

 

Jetzt hat der Container aber komischerweise kein Internet..
Weiter in den Firewall-Logs habe ich den fehler endeckt:
 

block 192.168.2.10:33587 -> 192.168.1.1:53 udp
block 192.168.2.10:55707 -> 192.168.1.1:53 udp

Er geht zwar korrekt über die richtige Schnittstelle, möchte aber über einen fremden Gateway kommunizieren, in diesem Fall eine DNS (53) Anfrage. Wieso den das? Der Gateway ist ja 192.168.2.1 nicht 1.1
In der Firewall ist natürlich sämtlicher zugriff von DMZ zu LAN verboten und blockiert. Daher ist es nicht möglich mit 192.168.1.1 zu sprechen. Ich habe die Regel testweise deaktiviert und der Container hat Internet, das darf natürlich nicht sein.

In Docker Settings:

Benutzerdefiniertes IPv4 Netzwerk auf Schnittstelle eth0:

Subnetz: 192.168.1.0/24 Gateway: 192.168.1.1 DHCP Pool: nicht definiert
 

Benutzerdefiniertes IPv4 Netzwerk auf Schnittstelle eth1:

Subnetz: 192.168.2.0/24 Gateway: 192.168.2.1 DHCP Pool: nicht definiert

Wo liegt das Problem? Wieso möchte Unraid auf eth1 den Gateway von eth0 verwenden?

[Ford Prefect]

6 minutes ago, EliteGroup said:

Er geht zwar korrekt über die richtige Schnittstelle, möchte aber über einen fremden Gateway kommunizieren, in diesem Fall eine DNS (53) Anfrage. Wieso den das? Der Gateway ist ja 192.168.2.1 nicht 1.1

Das Gateway des jeweiliugen IP-Netzes ist eben nur das Gateway.

Das Default Gateway kann es aber nur einmal geben....und das ist in Deinem LAN.

 

6 minutes ago, EliteGroup said:

Wo liegt das Problem? Wieso möchte Unraid auf eth1 den Gateway von eth0 verwenden?

Wenn Dein DNS auch auf Deinen Router 192.168.1.1 zeigt, ist dies das Problem.

 

12 minutes ago, EliteGroup said:

In der Firewall ist natürlich sämtlicher zugriff von DMZ zu LAN verboten und blockiert. Daher ist es nicht möglich mit 192.168.1.1 zu sprechen. Ich habe die Regel testweise deaktiviert und der Container hat Internet, das darf natürlich nicht sein.

Tja, wenn er grundsätzlich kein Internet darf, braucht er doch auch kein "richtiges" DNS.

Du musst ihm dann einen lokalen DNS-Service im eigenen Netz anbieten.

[EliteGroup]

3 minutes ago, Ford Prefect said:

Das Gateway des jeweiliugen IP-Netzes ist eben nur das Gateway.

Das Default Gateway kann es aber nur einmal geben....und das ist in Deinem LAN.

 

Wenn Dein DNS auch auf Deinen Router 192.168.1.1 zeigt, ist dies das Problem.

Das stimmt nicht jedes getrennte Netzwerk hat seinen eigenen Gateway, nur im selben Netzwerk gibt es den default Gateway.
Der DNS Server (Unbound DNS) lauscht auf allen Netzwerken bzw auf dementsprend den Gateways. Deshalb hat ja jedes Netzwerk sein eigenen default Gateway 😉
Das problem ist das Unraid über ein Netzwerk auf ein anderes Netzwerk möchte. Das darf generell nicht sein.
 

7 minutes ago, Ford Prefect said:

Tja, wenn er grundsätzlich kein Internet darf, braucht er doch auch kein "richtiges" DNS.

Du musst ihm dann einen lokalen DNS-Service im eigenen Netz anbieten.

Das hast du falsch verstranden, der darf grundsätzlich natürlich ins Internet sonst funktioniert der Container garnicht. Er darf nicht ins LAN Netzwerk.
Unraid macht ja alles richtig, er geht über die richtige Schnittstelle (eth1), er ist im richtigen Netzwerk und hat die richtige IP Adresse (192.168.2.10), nur dann sendet er Anfragen an den falschen Gateway, und das ist nicht normal, der standard Gateway ist ja im jeweiligen Netzwerk definiert und nicht "global", Docker zeigt es auch in den Settings was der entsprechende Gateway ist:

Schnittstelle eth1:

Subnetz: 192.168.2.0/24 Gateway: 192.168.2.1

Er versucht aber mit "192.168.1.1" zu kommunizieren was logisch nicht geht

[Ford Prefect]

11 minutes ago, EliteGroup said:

Das stimmt nicht jedes getrennte Netzwerk hat seinen eigenen Gateway, nur im selben Netzwerk gibt es den default Gateway.
Der DNS Server (Unbound DNS) lauscht auf allen Netzwerken bzw auf dementsprend den Gateways. Deshalb hat ja jedes Netzwerk sein eigenen default Gateway 😉
Das problem ist das Unraid über ein Netzwerk auf ein anderes Netzwerk möchte. Das darf generell nicht sein.

Natürlich darf das sein, Du willst es aber nicht so haben

Wie ist die Routing Tabelle von unRaid und hast Du VLANs aktiviert oder einfach nur zwei Netzwerke eingestellt?

 

11 minutes ago, EliteGroup said:

Das hast du falsch verstranden, der darf grundsätzlich natürlich ins Internet sonst funktioniert der Container garnicht.

Das habe ich mir zwar gedacht, ist aber nicht das was Du geschrieben hattest.

 

11 minutes ago, EliteGroup said:

Er darf nicht ins LAN Netzwerk.

So allgemein/allumfassend auch nicht richtig, oder?

Denke Du willst vom LAN auf die DMZ, also muss der Rückweg für bestehende Verbindundgen von da/LAN auch erlaubt sein in der Firewall.

Allerdings sollte das eben über den Router gehen und nicht lokal in unRaid.

 

11 minutes ago, EliteGroup said:

Unraid macht ja alles richtig, er geht über die richtige Schnittstelle (eth1), er ist im richtigen Netzwerk und hat die richtige IP Adresse (192.168.2.10), nur dann sendet er Anfragen an den falschen Gateway, und das ist nicht normal, der standard Gateway ist ja im jeweiligen Netzwerk definiert und nicht "global", Docker zeigt es auch in den Settings was der entsprechende Gateway ist:

Schnittstelle eth1:

Subnetz: 192.168.2.0/24 Gateway: 192.168.2.1

...die Frage ist, wer das Routing hinter dem Gateway macht

 

11 minutes ago, EliteGroup said:

Er versucht aber mit "192.168.1.1" zu kommunizieren was logisch nicht geht

Bitte präzisieren...versucht er die .1.1 als Gateway zu nutzen oder eine Verbindung mit einem Service in .1..1 aufzubauen?
Er würde ja schon versuchen mit 192.168.1.1 "zu kommunizieren", wenn er diese IP, zB für eine DNS Anfrage connecten will, aber sollte auch da das Gateway .2.1 nutzen.

Hat der Docker eine CLI...über welches Gateway geht er denn raus, wenn Du ein Ping auf einen externen DNS machst?

 

Ich vermute, wenn er das falsche Gateway nutzt, dass das Routing nicht sauber funktioniert....

Bei VLANs passiert das auf jeden Fall nicht, bei einfach nur zwei Netzen kann es natürlich sein, dass "unraid Router spielt".

[EliteGroup]

35 minutes ago, Ford Prefect said:

Wie ist die Routing Tabelle von unRaid und hast Du VLANs aktiviert oder einfach nur zwei Netzwerke eingestellt?

Es sind 2 physische / getrennte Netzwerke.
Es exisitiert auch kein Routing. In der Firewall ist es so eingerichtet als wären es 2 getrennte Geräte:
Quasi als hätte ich zwei WLan Router und Unraid ist mit einer Netzwerkkarte an Router A und der anderen Karte an Router B

So jetzt möchte unraid eine DNS auflösung machen an eine IP Adresse die nicht exisiterit auf Router B (logisch)

 

36 minutes ago, Ford Prefect said:

Hat der Docker eine CLI...über welches Gateway geht er denn raus, wenn Du ein Ping auf einen externen DNS machst?

# traceroute www.google.com
traceroute to www.google.com (142.250.184.196), 30 hops max, 60 byte packets
 1  OPNsense.lan (192.168.2.1)  0.054 ms  0.146 ms  0.128 ms

Der richtige Gateway wird verwendet. Mir kommt so vor das Unraid für DNS auflösung immer den selben Gateway verwenden möchte und verwendet garnicht den Gateway der Schnittstelle.
In den Loggs ist zu sehen was passiert bei der traceroute:
1. Er möchte zuerst "www.google.com" dessen IP auflösen und zwar über 192.168.1.1
2. dann kannst du sehen wie er über den Gateway 192.168.2.1 richtig dort hin Routet.

Ich bin ein absoluter Experte in Netzwerk aber Gateway hat nichts mit DNS zu tun?
Es gibt immer 3 Einstellungen für ein Netzwerk:
Netzwerk (192.168.1.0/24)
Gateway (192.168.1.1)
DNS-Server (192.168.1.1)

Mir scheint es langsam das er den Gateway garnicht falsch nimmt er nimmt immer den DNS-Server von eth0 Das wäre ja die 192.168.1.1
Die Schnittstelle sollte aber den DNS-Server Eintrag 192.168.2.1 besitzten (Das weis ich da zb Windows es korrekt erkennt wenn man ein Geräte damit verbindet)
In Unraid Netzwerksettings sieht man auch keine konfiguration bzgl DNS-Server?

Vilt ist alleine das der fehler das er Global die DNS-Server IP von eth0 nimmt. Jetzt ist die Frage wie kann man den DNS-Server für eine Schnittstelle einstellen? Das löst vilt alle Probleme 🙂

[Ford Prefect]

4 minutes ago, EliteGroup said:

Es sind 2 physische / getrennte Netzwerke.
Es exisitiert auch kein Routing. In der Firewall ist es so eingerichtet als wären es 2 getrennte Geräte:

Sind es aber nicht aus Sicht von unraid, nur wenn Du VLANs aktivierst hättest Du das.

Du hast den unraid Host mit zwei NICs. Du hast die Sicht Deiner pfsense, nicht die von unraid.

 

Das sind keine zwei Geräte. Der Docker hängt an der Bridge (vermute br1, eth0/LAN in unraid ist auf br0) in unRaid.

Natürlich ist Routing aktiv,,,daher fragte ich ja nach der Routing Tabelle *in unraid'.

 

4 minutes ago, EliteGroup said:

# traceroute www.google.com
traceroute to www.google.com (142.250.184.196), 30 hops max, 60 byte packets
 1  OPNsense.lan (192.168.2.1)  0.054 ms  0.146 ms  0.128 ms

Der richtige Gateway wird verwendet. Mir kommt so vor das Unraid für DNS auflösung immer den selben Gateway verwenden möchte und verwendet garnicht den Gateway der Schnittstelle.
In den Loggs ist zu sehen was passiert bei der traceroute:
1. Er möchte zuerst "www.google.com" dessen IP auflösen und zwar über 192.168.1.1
2. dann kannst du sehen wie er über den Gateway 192.168.2.1 richtig dort hin Routet.

...da sprichst Du jetzt von Wem genau?. Ich sehe hier nix.

 

4 minutes ago, EliteGroup said:

Mir scheint es langsam das er den Gateway garnicht falsch nimmt er nimmt immer den DNS-Server von eth0 Das wäre ja die 192.168.1.1

Das war ja meine Vermutung.

Du hast aber behauptet, Dein unBound würde da dran hängen.

 

4 minutes ago, EliteGroup said:

Die Schnittstelle sollte aber den DNS-Server Eintrag 192.168.2.1 besitzten (Das weis ich da zb Windows es korrekt erkennt wenn man ein Geräte damit verbindet)
In Unraid Netzwerksettings sieht man auch keine konfiguration bzgl DNS-Server?

Doch, eigentlich schon.

 

4 minutes ago, EliteGroup said:

Vilt ist alleine das der fehler das er Global die DNS-Server IP von eth0 nimmt. Jetzt ist die Frage wie kann man den DNS-Server für eine Schnittstelle einstellen? Das löst vilt alle Probleme 🙂

Indem Du es in der Konfiguration je ethX als "static" mit IP=x.x.x.x einträgst oder den DNS in ein eigenes Netz hängst und die Zugriffe dort über die Firewall regelst.

 

....lad mal Deine Diagnostics.Zip hoch, bitte.

[Ford Prefect]

@EliteGroup...in Deinem Docker...was steht dort in /etc/resolv.conf drin?

 

Edit: ...das/Dein Problem ist die DNS Auflösung im Docker...hat nix mit ethX zu tun.

Die Docker-Engine rennt auf dem unRaid Host und dessen DNS ist 192.168.1.1 und idt deshalb auch der Backend DNS Resolver der Docker-Engine, wenn ein Docker über den internen Resolver (127.0.0.11) eine DNS Anfrage startet.

 

Daher ist die Lösung Deinen DNS-Resolver/Unbound in ein "neutrales" Netz zu legen, wohin Du den DNS-Zugriff auch aus Richtung der DMZ erlaubst.

Dessen IP kannst Du dann eben auch im LAN nutzen und an eth0 (und damit als Backend Resolver für Docker-DNS) nutzen.

 

Edit2: Alternative wäre, dem Docker in der DMZ eine eigene, explizite /etc/resolv.conf mit nameserver=192.168.2.1 mitzugeben.

Also im Docker-Template unter "Extra Parameters" ein "--dns=192.168.2.1" einbauen und mal versuchen.

Edited October 2, 2021 by Ford Prefect

[EliteGroup]

5 hours ago, Ford Prefect said:

Sind es aber nicht aus Sicht von unraid, nur wenn Du VLANs aktivierst hättest Du das.

Du hast den unraid Host mit zwei NICs. Du hast die Sicht Deiner pfsense, nicht die von unraid.

 

Das sind keine zwei Geräte. Der Docker hängt an der Bridge (vermute br1, eth0/LAN in unraid ist auf br0) in unRaid.

Natürlich ist Routing aktiv,,,daher fragte ich ja nach der Routing Tabelle *in unraid'.

Die 2 NICs / Netzwerke sind nicht gebrückt, sie sind getrennt in Unraid.

Docker hab ich weder im br1 noch im eth0. Ich habe "Custom: eth1" für den Container gewählt.

Ich sehe gerade, in den Unraid Netzwerkeinstellungen wird nur bei eth0 ein DNS-Server eingetragen... Für andere Netzwerke fragt er erst garnicht nach dessen DNS-Adresse
In resolv.conf ist nur die IP von eth0 also 192.168.1.1
Das habe ich so auch noch nie gesehen, für was gibt es sperate Schnittstellen in denen man eigene / andere Netzwerke + Gateway definieren kann diese "fremde" Netze dürfen keinen eigenen DNS Server besitzen?
Man sieht das Unraid richtig die IP von eth1 verwendet, er geht garnicht über eth0, er geht an den richtigen Gateway und an die richtige physische Schnittstelle, fragt aber im fremden Netzwerk an einen lokalen DNS Server aus einen anderen Netzwerk 🙄 das entzieht mir sämtlich Logik 😁 Deshalb hat jedes Netzwerk einen DNS-Server (außer man verwendet einen direkt/extern wie 8.8.8.8 etc, dann ist es unrelevant)
Wenn er als ausgangspunkt eth0 nimmt und auch dessen IP okay dann versteh ich es... Aber im eth1 eine IP aus eth0 kann nicht (sollte) nicht funktionieren.

 

5 hours ago, Ford Prefect said:

@EliteGroup

Edit2: Alternative wäre, dem Docker in der DMZ eine eigene, explizite /etc/resolv.conf mit nameserver=192.168.2.1 mitzugeben.

Also im Docker-Template unter "Extra Parameters" ein "--dns=192.168.2.1" einbauen und mal versuchen.

Das scheint gut zu funktionieren. Wenn die Schnittstelle aus Unraid "eth1" keinen DNS-Server Eintrag besitzt muss er wohl auf 192.168.1.1 zurückgreifen 😁
Mit dem Setting funktioniert das super, obwohl es schöner wäre der Schnittstelle einen DNS-Server zuzuweisen.
Lustig in "network.cfg"
Kann man die Interfaces konfigurieren außer der DNS ist "golbal":
IFNAME[0]="eth0"
IPADDR[0]="192.168.1.10"
GATEWAY[0]="192.168.1.1"

IFNAME[1]="eth1"
IPADDR[1]="192.168.2.10"
GATEWAY[1]="192.168.2.1"

DNS_SERVER1="192.168.1.1"
---
Ob hier DNS_SERVER1[1] auch funktionieren würde? Ich trau mich garnicht es zu probieren, nicht das mir das Netzwerk crasht und ich keinen Zugang mehr habe.

Mir geht es ja nur um eine Sache... Ich möchte bestimmte Container (die auch extern erreichbar sind) über ein eigenes Netzwerk abschotten. In der PfSense habe ich dieses eigene Netzwerk schon. Die Container sollen einfach in diesen Netzwerk sich befinden. Nicht mehr nicht weniger.
VLAN benötige ich nicht, ich habe eine physische Schnittstelle dafür.

Können für VLANs eigene DNS-Server eingerichtet werden?

[Ford Prefect]

1 hour ago, EliteGroup said:

Die 2 NICs / Netzwerke sind nicht gebrückt, sie sind getrennt in Unraid.

Docker hab ich weder im br1 noch im eth0. Ich habe "Custom: eth1" für den Container gewählt.

....egal wie viele NICs Du an einer Bridge hast, um mehr als einen Docker an das selbe Netzwerk anzuschliessen brauchst Du die Bridge.

Also hast Du im Moment nur diesen einen Docker an Deiner DMZ...was wenn es mehr werden sollen?.

EIne Bridge ist praktisch der Software-Switch in Linux/unraid.

 

Du kannst eben auch mehrere Bridges haben.

Daher sprach ich von br0 (standard in unraid für LAN/eth0)

Für das DMZ Netzwerk machst Du dann auch eine Bridge (wird dann br1) auf.

 

1 hour ago, EliteGroup said:

Ich sehe gerade, in den Unraid Netzwerkeinstellungen wird nur bei eth0 ein DNS-Server eingetragen... Für andere Netzwerke fragt er erst garnicht nach dessen DNS-Adresse
In resolv.conf ist nur die IP von eth0 also 192.168.1.1

Nein, der DNS-Server EIntrag ist für den HOST, nicht für das jeweilige Netz.

Du verwechselst das mit der Übermittlung des DNS-Servers bei DHCP...da bekommt ein HOST vom DHCP-Server eine IP und seinen DNS-Server "zugeteilt".

 

1 hour ago, EliteGroup said:

Das habe ich so auch noch nie gesehen, für was gibt es sperate Schnittstellen in denen man eigene / andere Netzwerke + Gateway definieren kann diese "fremde" Netze dürfen keinen eigenen DNS Server besitzen?

Klar könen sie das.

Aber nochmal, diese Konfiguration ist für den HOST, jeder HOST im Netzwerk hat einen (oder eine Liste), in der Regel haben alle Host in einem Netzwerk den gleichen.

Dabei ist es egal, ob ein/der DNS-Server eine IP im gleichen Netz hat.

 

1 hour ago, EliteGroup said:

Man sieht das Unraid richtig die IP von eth1 verwendet, er geht garnicht über eth0, er geht an den richtigen Gateway und an die richtige physische Schnittstelle, fragt aber im fremden Netzwerk an einen lokalen DNS Server aus einen anderen Netzwerk 🙄 das entzieht mir sämtlich Logik 😁 Deshalb hat jedes Netzwerk einen DNS-Server (außer man verwendet einen direkt/extern wie 8.8.8.8 etc, dann ist es unrelevant)

Nein, das ist das Gleiche. Siehe oben.

 

1 hour ago, EliteGroup said:

Wenn er als ausgangspunkt eth0 nimmt und auch dessen IP okay dann versteh ich es... Aber im eth1 eine IP aus eth0 kann nicht (sollte) nicht funktionieren.

Also bitte, wieso kann/sollte das nicht funktionieren...Du verwechselt eine Route und Default-Gateway mit DNS-Server IP.

Dein Denkfehler ist, dass DU es in Deiner DMZ so haben willst, aber einer Routing/Netzwerk-Einstellung eines Host ist es egal, ob er in einer DMZ ist oder nicht.

Das regelt allein die Fiorewall.

 

1 hour ago, EliteGroup said:

Das scheint gut zu funktionieren. Wenn die Schnittstelle aus Unraid "eth1" keinen DNS-Server Eintrag besitzt muss er wohl auf 192.168.1.1 zurückgreifen 😁
Mit dem Setting funktioniert das super, obwohl es schöner wäre der Schnittstelle einen DNS-Server zuzuweisen.

Das geht eben nicht....siehe oben.

Das/Dein "Problem" ist, wie schon in meinem Eintrag geschildet, dass der Docker die Docker-interne DNS Resultion nutz (die /etc/resolv.conf *im* Docker-Container hat als DNS 127.0.0.11.

Die Docker Engine läuft aber auf dem unraid Host, der ein HOST ist und eben nur die Nameserver seiner, in der unraid /etc/resolv.conf kennt/nutzen kann.

Mit meinem "Trick" änders Du für den Docker die /etc/resolv.conf *im* Docker-Container, weg von der Docker-internen DNS-Auflöung.

Das geht aber eben nur für Docker mit custom:IPs

 

1 hour ago, EliteGroup said:

Lustig in "network.cfg"
Kann man die Interfaces konfigurieren außer der DNS ist "golbal":
IFNAME[0]="eth0"
IPADDR[0]="192.168.1.10"
GATEWAY[0]="192.168.1.1"

IFNAME[1]="eth1"
IPADDR[1]="192.168.2.10"
GATEWAY[1]="192.168.2.1"

DNS_SERVER1="192.168.1.1"
---
Ob hier DNS_SERVER1[1] auch funktionieren würde? Ich trau mich garnicht es zu probieren, nicht das mir das Netzwerk crasht und ich keinen Zugang mehr habe.

Nein, das geht eben *nicht* Du hast den Denkfehler, das ein DNS-Server eines Netzwerkes immer auch eine IP im gleichen Netzwerk haben muss/damit einem Netzwerk zugeordnet ist...dem ist eben nicht so.

 

1 hour ago, EliteGroup said:

Mir geht es ja nur um eine Sache... Ich möchte bestimmte Container (die auch extern erreichbar sind) über ein eigenes Netzwerk abschotten. In der PfSense habe ich dieses eigene Netzwerk schon. Die Container sollen einfach in diesen Netzwerk sich befinden. Nicht mehr nicht weniger.

Das tut er doch.

Was Du aber *zusätzlich* willst ist, dass er DNS Anfragen nur nach extern sendet, nicht an den DNS im LAN.

Dein "Problem" ist, dass der DNS, den er nun abfragt "zufällig" in Deinem LAN sitzt.

 

Wie gesagt, es gibt 2 (eigentlich 3) Arten das zu "heilen".

1, dem/jedem Docker einen spezifischenm erlaubten DNS zuzuweisen (der natürlich dann in Dienem Fall im jeweiligen lokaln Netz existeiren muss)

2. Deine Firewall so zu konfigurieren, das DNS anfragen immer zum jeweiligen gewollten DSN umgebogen werden (port forwards)

3. ein weiteres, "neutrales" Netz definieren, in dem *ein* DNS-Server seinen Dienst tut, der eben nur auf *einer* IP lauschen muss und in der Firewall eben entsprechend die Weg freichalten, inkl. Routing.

Ich habe Variante #3 am Start.

Mein "LAN" ist 192.168.0.0/24, weitere LANs sind .10.0/24, 11.0/24, 20.0/24 usw.

Mein DNS für *alle* Hosts in allen Netzen ist *immer* 192.168.10.10 (der eben *nicht* im LAN ist, daher bleibt LAN für Andere zu).

 

1 hour ago, EliteGroup said:

VLAN benötige ich nicht, ich habe eine physische Schnittstelle dafür.
Können für VLANs eigene DNS-Server eingerichtet werden?

Nein, siehe oben. DNS=HOST, nicht pro NIC - unraid baut den Parameter einfach im UI nur bei eth0 ein, sonst nix.

 

Aber VLANs sind eben flexibler, wenn man nochmal weitere Netzwerke braucht.

Du könntest beliebige Netze definieren, aber Deine beiden physischen NICs in einer Bridge und einem Bond zusammenfassen.

 

Ich habe inzwischen eine 10G Karte im unraid...habe aber davor eine Quad-NIC Karte so genutzt.

 

Edit: ...und vielleicht nochmal zurück zum Wesentlichen:

• genau genommen hast Du Deine Firewall-Einstellungen nicht korrekt vorgenommen, denn den Hosts in Deiner DMZ ist es erlaubt Services in Deinem LAN zu erreichen. Eigentlch hätte die DNS Auflösung in Deinem Docker garnicht funktionieren dürfen.

Edited October 2, 2021 by Ford Prefect

[EliteGroup]

1 hour ago, Ford Prefect said:

....egal wie viele NICs Du an einer Bridge hast, um mehr als einen Docker an das selbe Netzwerk anzuschliessen brauchst Du die Bridge.

Also hast Du im Moment nur diesen einen Docker an Deiner DMZ...was wenn es mehr werden sollen?.

Ich habe 2 Docker in der DMZ installiert und beide funktionieren im Netzwerk:
Docker1:
Custom: eth1
Statisch: 192.168.2.15
Docker2:
Custom: eth1
Statisch: 192.168.2.16

jeder Docker muss halt eine eigene IP bekommen, an der selben IP funktioniert es nicht.
Die zwei Docker können untereinander kommunizieren, aber haben keinen zugriff auf 192.168.1.1 (eth0 / mein LAN) oder andere IPs in diesem Netz
(getestet in der Docker Konsole)
Ich muss halt wenn ich "Custom: eth1" wähle auch --dns= definieren wie du es mir vorgeschlagen hast 😉

 

1 hour ago, Ford Prefect said:

• genau genommen hast Du Deine Firewall-Einstellungen nicht korrekt vorgenommen, denn den Hosts in Deiner DMZ ist es erlaubt Services in Deinem LAN zu erreichen. Eigentlch hätte die DNS Auflösung in Deinem Docker garnicht funktionieren dürfen.

Das stimmt, betrifft aber nur das erstellen des Containers.
Beim erstellen wähle ich eth0 oder belasse standard Bridge, dann möchte erstmal Docker den Container herunterladen... Nach dem erstellen auf eth1 stellen und --dns=
Ist der Container erstellt arbeitet er nur noch in eth1 (Wie das mit Updates von Containern aussieht ist evtl wieder ein andere Sache)

Die pfSense macht das schon richtig, sonst wäre ich auf das Problem nicht aufmerksam geworden wenn die DMZ in die LAN DNS darf.

Ich dachte man könnte das Problem lösen das man einer Schnittstelle einen DNS Server zuweisen kann, das bin ich normal gewöhnt das kann jede Software die ich bisher verwendet habe, das eth1 die DNS-IP von eth0, ein ganz anderes Netzwerk verwenden möchte ist mir neu. Das hast du mir jetzt erklärt wie die Sache läuft.
Wie dem auch sei.

Eine Lösungsoption wäre noch:
In der PfSense kann man Virtual-IP erstellen zb 192.168.250.250
Dann hat jeder sein eigenes Netzwerk und die DMZ darf weiterhin nicht ins LAN. Aber jedes Netzwerk darf auf 192.168.250.250:53 als DNS-Server IP
Diese IP für die es quasi kein Netzwerk gibt (192.168.250.250/32) kann dan nur ein... DNS Auflösen sonst nichts... Brauche ich nur in der FIrewall einstellen das jedes lokale Netz auf diese IP darf. Wenn in Unraid im Resolver die 192.168.250.250 stehen hat darf jeder darauf DNS auflösen egal ob LAN oder DMZ.
Deine Lösung wäre in einem Netzwerk eine bestimmte IP zulassen. Ist dann quasi das gleiche, finde die Virtual-IP lösung etwas übersichtlicher da es eine statische eindeutige IP ist.

Ich sollte dann aber auch sowieso für diese Container eine Bridge erstellen. Wie gesagt ich bin erst bei der Einrichtung meines Systems und frisch und neu im Team Unraid dabei 😉
Das wichtigste ist mir das diese Dienste die ins WWW dürfen zumindest abgeschottet von meinem LAN sind und von der DMZ aus keinen zugriff darauf haben...
Nochmal auf deine AUssage zurück ich kann nur einen Docker auf eth1 betreiben ohne Bridge müsstest du wohl noch einmal testen, bei mir laufen gerade 2 🤔 Ich habe aber nichts besonders eingestellt und auch keine weitere Bridge erstellt.

Ein paar zum test installiert: alle erreichbar

Edited October 2, 2021 by EliteGroup

[Ford Prefect]

2 minutes ago, EliteGroup said:

Ich habe 2 Docker in der DMZ installiert und beide funktionieren im Netzwerk:
Docker1:
Custom: eth1
Statisch: 192.168.2.15
Docker2:
Custom: eth1
Statisch: 192.168.2.16

jeder Docker muss halt eine eigene IP bekommen, an der selben IP funktioniert es nicht.
Die zwei Docker können untereinander kommunizieren, aber haben keinen zugriff auf 192.168.1.1 (eth0 / mein LAN) oder andere IPs in diesem Netz
(getestet in der Docker Konsole)
Ich muss halt wenn ich "Custom: eth1" wähle auch --dns= definieren wie du es mir vorgeschlagen hast 😉

Ja, schon richtig...aber ohne Bridge haben alle Docker nur den 1Gbps Link untereinander...sie könnten aber die ganze CPU-Bandbreite haben  -> bridge

 

2 minutes ago, EliteGroup said:

Das stimmt, betrifft aber nur das erstellen des Containers.
Beim erstellen wähle ich eth0 oder belasse standard Bridge, dann möchte erstmal Docker den Container herunterladen... Nach dem erstellen auf eth1 stellen und --dns=
Ist der Container erstellt arbeitet er nur noch in eth1 (Wie das mit Updates von Containern aussieht ist evtl wieder ein andere Sache)

Die pfSense macht das schon richtig, sonst wäre ich auf das Problem nicht aufmerksam geworden wenn die DMZ in die LAN DNS darf.

Ich dachte man könnte das Problem lösen das man einer Schnittstelle einen DNS Server zuweisen kann, das bin ich normal gewöhnt das kann jede Software die ich bisher verwendet habe, das eth1 die DNS-IP von eth0, ein ganz anderes Netzwerk verwenden möchte ist mir neu. Das hast du mir jetzt erklärt wie die Sache läuft.
Wie dem auch sei.

Ja, ich habe die Ursache mit dem Docker-internen DNS-Resolv erstmal nicht auf dem Radar gehabt, da ich eben sowieso meinen DNS in ein eigened IP-Segment verbannt habe....hat etwas gedauert....aber nun ist das geklärt.

 

2 minutes ago, EliteGroup said:

Eine Lösungsoption wäre noch:
In der PfSense kann man Virtual-IP erstellen zb 192.168.250.250
Dann hat jeder sein eigenes Netzwerk und die DMZ darf weiterhin nicht ins LAN. Aber jedes Netzwerk darf auf 192.168.250.250:53 als DNS-Server IP
Diese IP für die es quasi kein Netzwerk gibt (192.168.250.250/32) kann dan nur ein... DNS Auflösen sonst nichts... Brauche ich nur in der FIrewall einstellen das jedes lokale Netz auf diese IP darf. Wenn in Unraid im Resolver die 192.168.250.250 stehen hat darf jeder darauf DNS auflösen egal ob LAN oder DMZ.
Deine Lösung wäre in einem Netzwerk eine bestimmte IP zulassen. Ist dann quasi das gleiche, finde die Virtual-IP lösung etwas übersichtlicher da es eine statische eindeutige IP ist.

Ja, kannst Du machen. Achte aber darauf, dass dan Firewall-Regeln die auf dem Interface basieren dann nicht unterscheiden welche IP da relevant ist.

Keine Ahnung wie Du da Regeln gebaut hast, aber bei der virteullen IP hat das gleiche Interface eben 2 IPs....also Obacht.

 

2 minutes ago, EliteGroup said:

Ich sollte dann aber auch sowieso für diese Container eine Bridge erstellen. Wie gesagt ich bin erst bei der Einrichtung meines Systems und frisch und neu im Team Unraid dabei 😉

Für die Kommunikation von Services auf unRaid ist das eben performanter...wenn der Traffic durch die Sense muss, ist es egal, dort nur die Performance nur des physischen NIC.

Denke auch, dass es für eine VM zwingend sein muss....virtuelle NICs bei Dockern sind anders als VMs mit VM/virtio, denke ich.

 

2 minutes ago, EliteGroup said:

Das wichtigste ist mir das diese Dienste die ins WWW dürfen zumindest abgeschottet von meinem LAN sind und von der DMZ aus keinen zugriff darauf haben...
Nochmal auf deine AUssage zurück ich kann nur einen Docker auf eth1 betreiben ohne Bridge müsstest du wohl noch einmal testen, bei mir laufen gerade 2 🤔 Ich habe aber nichts besonders eingestellt und auch keine weitere Bridge erstellt.

Ja, habe ich gelesen...wusste ich nicht....funktioniert dann wohl wie ein virtuelles Interface, aber über den Docker-Daemon. Habe ich selbst noch nicht probiert.

Ich habe das VLAN Setup schon vor der "Erfindung von Dockern" am Start. Vorher eben mit VMs gearbeitet, wobei ich da immer einen echten NIC durchreiche und eine Bridge sowieso immer an Start war.

Nutze VLANs ja nicht nur für unRaid...auch fürs WLAN (Kids, IoT, und DMZs haben eine eigene SSID)....das Haus hat aber nict genug echte Kabel/Dosen

[EliteGroup]

2 minutes ago, Ford Prefect said:

Ja, schon richtig...aber ohne Bridge haben alle Docker nur den 1Gbps Link untereinander...sie könnten aber die ganze CPU-Bandbreite haben  -> bridge

Das ist ein guter Hinweis!
Das könnte ich in meinem Fall aber vernachlässigen... Das Limit der DMZ Apps die ich habe ist sowieso der miese Upload vom WAN / Internetanbieter 😁
Untereinander sprechen die Container nur ab und zu per API... Also unter den Containern wird es keine Datentransfers geben.
Trotzdem gut das ich das jetzt weiß

 

5 minutes ago, Ford Prefect said:

Für die Kommunikation von Services auf unRaid ist das eben performanter...wenn der Traffic durch die Sense muss, ist es egal, dort nur die Performance nur des physischen NIC.

Denke auch, dass es für eine VM zwingend sein muss....virtuelle NICs bei Dockern sind anders als VMs mit VM/virtio, denke ich.

So wie ich das gesehen habe, haben die Docker zwar das Limit von 1Gbps ohne der Bridge, aber Kommunikation unter den Dockern auf eth1 läuft direkt ohne über den Traffic auf die Sense 🤔
Zumindest die Pings funktionieren direkt von Container zu Container auf eth1 ohne PfSense-Traffic
 

12 minutes ago, Ford Prefect said:

Nutze VLANs ja nicht nur für unRaid...auch fürs WLAN (Kids, IoT, und DMZs haben eine eigene SSID)....das Haus hat aber nict genug echte Kabel/Dosen

Ich ebenso 🙂 Mit einer 4x Intel NIC per LACP an einen VLAN-fähigen Switch. LAN, Kids, IoT / Shellys / Sonoffs etc, DMZ
Nach der Zeit sind da einige Meter Kabel gelegt worden 😁 Deshalb wirst du bestimmt mein Ärger verstehen als Unraid nicht mit meinem DMZ Netzwerk funktionierte 😅
Vor einen halben Jahr habe ich extra mal "aufgeräumt" und die Netzwerke physisch getrennt und mir eine weitere 2x Intel NIC gekauft.
Was das betrifft ist die PfSense ja super... Der ist es völlig egal ob das ein VLAN oder eine Physische Schnittstelle ist (außer WANs "sollten" am besten eine physische sein wenn es geht)

[Ford Prefect]

26 minutes ago, EliteGroup said:

So wie ich das gesehen habe, haben die Docker zwar das Limit von 1Gbps ohne der Bridge, aber Kommunikation unter den Dockern auf eth1 läuft direkt ohne über den Traffic auf die Sense 🤔
Zumindest die Pings funktionieren direkt von Container zu Container auf eth1 ohne PfSense-Traffic

Ja, logisch, da alle im gleichen IP-Segment liegen. Dann läuft der eigentliche Traffic ja nicht über IP, sondern über L2/ARP. Nur was ausserhalb ist wird zum default-GW geschickt (Deine Sense).

 

26 minutes ago, EliteGroup said:

Nach der Zeit sind da einige Meter Kabel gelegt worden 😁 Deshalb wirst du bestimmt mein Ärger verstehen als Unraid nicht mit meinem DMZ Netzwerk funktionierte 😅

Zumindest das haben wir ja jetzt mal rausgefunden.

In unRaid 6.10 sollen Docker custom NICs wohl von MAC-VLan auf IP-VLAN umgestellt werden...mal sehen, dann wird es nochmal knifflig, weil dann müsste der Host immer auf L3 routen, auch im gleichen IP-Segment.

Habe ich auch noch nicht ausprobiert.

...es bleibt spannend.

 

[EliteGroup]

5 minutes ago, Ford Prefect said:

Zumindest das haben wir ja jetzt mal rausgefunden.

In unRaid 6.10 sollen Docker custom NICs wohl von MAC-VLan auf IP-VLAN umgestellt werden...mal sehen, dann wird es nochmal knifflig, weil dann müsste der Host immer auf L3 routen, auch im gleichen IP-Segment.

Habe ich auch noch nicht ausprobiert.

...es bleibt spannend.

Auch eine gute Info, hab mir vorhin die änderungen in 6.10 angesehen, werde ich als nächstes eine Unraid 6.10-RC1 installation auf einen Test-Rechner machen um zusehen was da passiert. 😄

Edited October 2, 2021 by EliteGroup

[Ford Prefect]

...ich bin da immer etwas vorsichtiger.

Bin nur auf 6.9 gegangen, da ich multiple Pools brauchte. Mein "grosser" läuft immer noch auf 6.7.2

 

Nochmal kurz zum Thema Bridge:

Eine Bridge ist wie ein (Software-) Port-Extender, fast wie ein Switch.

Ethernet-NIc, aber auch virtio NICs einer VM oder ein custom NIC eines Docker sind Ports an dem Switch....nur das die virtuellen am CPU-Bus hängen, die Ethernet an ein physisches Medium gebunden sind. Daher können dann die virtuellen Ports an der Bridge mit ganzer CPU Bandbreite kommunizieren.

Siehe zB auch: 

 

[EliteGroup]

@Ford Prefect

Hey, ich hab ein bisscher rum gespielt und die Sache ist wohl anders als gedacht 😁

Ich habe meine zwei Docker Container auf "Custom: eth1" mit dem extra "--dns="
Bonding / Bridge habe ich deaktiviert und auch kein Docker-Bidge Netzwerk.

• Die Container auf eth1 können sich untereinander anpingen
• Die Container haben keinen zugriff auf Unraid, andere Container die nicht auf eth1 sind oder VMs (Netze außerhalb von eth1 fließen über die FIrewall, da kann geregelt werden zugriff ja oder nein)

Weiteres habe ich mit Iperf die Geschwindigkeit unter den zwei Containern getestet. Angebunden sind sie auf eth1 mit 1Gbps, untereinander habe ich eine Geschwindigkeit von 35-40 Gbps konstant getestet.

Das hießt benötigt man überhaupt noch eine Bridge? Wohl eher nur wenn man nur 1 Netz hat und bestimmte Dienste trennen möchte?
Wenn eth1 schon ein eigenes Netz ist, braucht man die Bridge garnicht und die Container untereinander agieren als Switch.

Ich weiß nicht wie hoch die Gbps sind im standard (docker0) Bridge. Müsste ich noch testen aber ich denke nicht höher als die 40Gbps?

Die Bridge hat nach meiner neuen Ansicht nur einen Vorteil:
Man hat nicht für jeden Dienst eine eigene IP sondern einfach die IP von Unraid, man muss sich "nur" den Port merken. Das geht unter eth1 nicht, jeder Docker hat eine eigene IP, aber da es sowieso ein eigenes Netz ist und ich unwarscheindlich mehr als 250 Dienste laufen lasse, reicht das /24 Netz sonst einfach /16 auch möglich.

Damit habe ich korrekt erfüllt was mein Wunsch einem separierten Netzwerk war?

• Eigenes Netzwerk abgeschottet vom rest des Systems
• Dienste auf eth1 untereinander können kommunizieren
• Dienste auf eth1 untereinander haben 40Gbps Verbindung, nach außen / zu andere Netze 1Gbps über eth1 / die Firewall

Diese Dienste kann ich ohne sorgen über das Internet freigeben. Es gibt nur einen Nachteil das mein LAN "nur" maximal 1Gbps auf diese Dienste hat (Mit einer 10Gbps Karte oder LAG könnte man das erweitern). Aber das ist anders auch garnicht möglich, sonst müssten sich diese Dienste im selben Netzwerk befinden.
In meinem / den meisten Fällen reichen also die 1Gbps vollkommen aus, nur bei Daten Shares oder VMs wäre das evtl zu gering, diese Dienste habe ich sowieso im lokalen LAN nicht in dem separierten Netzwerk.

 

Ich denke ich brauche keine Bridge und Custom: eth1 erfüllt alles benötigte. Nur --dns muss gesetzt werden wenn man den lokalen DNS Dienst auf der Firewall verwenden möchte. Hat man public DNS kann man das auch überspringen. 🙂

Edited October 5, 2021 by EliteGroup

[Ford Prefect]

1 hour ago, EliteGroup said:

Ich denke ich brauche keine Bridge und Custom: eth1 erfüllt alles benötigte. Nur --dns muss gesetzt werden wenn man den lokalen DNS Dienst auf der Firewall verwenden möchte. Hat man public DNS kann man das auch überspringen. 🙂

Hmmm...das ist interessant, dass Du da auch 40Gb rausbekommst.

Das ist so die typiche Bandbreite/Performance einer aktuellen CPU.

ich hatte ehrlich gedacht, dass es sozusagen durch den ETH bottleneck durchmuss, aber wahrscheinlich ist der Treiber schon so intelligent, das auf der Software-Layer-Ebene abzufangen.

Dann brauchst Du die Bridge nur, wenn da mehr als ein ETHx dran ist....für Deinen Fall, mit nur eth1 brauchst Du sie dann nicht.