26
Ubuntu Server 2 NICs - 2 VLANs - Netplan
Hallo Freunde,
ich bin mittlerweile am Verzweifeln.... ich habe Google durchforstet, Netplans Beispielseite durchforstet und bekomme es trotzdem nicht gebacken...
Die Anforderung ist Folgende:
Ein Ubuntu 22.04 Server auf VMWare ESXi installiert. Zwei Netzwerkkarten wurden zugewiesen. Eine in VLAN1 die Andere in VLAN2. Im ersten Step würde ich dem Server gerne jeweils eine IP-Adressen im jeweiligen VLAN geben. Der Traffic soll auf Linux nicht zwischen beiden Netzwerken geroutet werden können.
Hintergrund ist Folgender.... der Server soll für Docker Container bereitgestellt werden. Einige der Container sollen in VLAN1, andere in VLAN2, damit wir den Zugriff über die Firewall sauber restriktieren können.
Alles was ich im Internet finde, bezieht sich am Ende auf eine andere Config, als die, die ich suche. Es wird immer was von Routing Tabellen erzählt und blabla, aber das möchte ich ja nicht. Er soll die VLAN1 getaggten packete durch den vorgesehenen NIC leiten und wieder zurück. Das Gleiche soll er mit VLAN2 machen und gut ist.
Ich bin darüber verwundert, dass es so komplex ist. Ich bin echt kein Windows Fan, aber dort kann ich ohne Probleme eine zweite NIC zuweisen, eine zweite IP mit zweitem Gateway vergeben und schon ist die Sau am Fliegen.
Meine Config bisher:
Ich möchte anmerken, dass die Abstände in der YAML Datei eingehalten wurden, daran kanns schon mal nicht liegen. Wenn ich die YAML teste, bekomme ich folgende Fehlermeldung:
"Problem encountered while validating default route consistency.Please set up multiple routing tables and use `routing-policy` instead.
Error: Conflicting default route declarations for IPv4 (table: main, metric: default), first declared in ens02 but also in ens01"
Die Problematik ist klar, er kann nicht mehrere Gateways haben, weil er vermutlich nicht weiß wie er Routen soll. Aber wie erwähnt.... ich sehe keine Notwendigkeit mit Routing Tabellen zu Arbeiten, denn ich will ja, dass die Pakete da raus gehen, wo sie herkamen. Ich dachte durch Angeben des Gateway wäre das für Linux klar.
So langsam bin ich mit meinem Latein am Ende. Habe ich einen Denkfehler?
vg Mr.Robot
ich bin mittlerweile am Verzweifeln.... ich habe Google durchforstet, Netplans Beispielseite durchforstet und bekomme es trotzdem nicht gebacken...
Die Anforderung ist Folgende:
Ein Ubuntu 22.04 Server auf VMWare ESXi installiert. Zwei Netzwerkkarten wurden zugewiesen. Eine in VLAN1 die Andere in VLAN2. Im ersten Step würde ich dem Server gerne jeweils eine IP-Adressen im jeweiligen VLAN geben. Der Traffic soll auf Linux nicht zwischen beiden Netzwerken geroutet werden können.
Hintergrund ist Folgender.... der Server soll für Docker Container bereitgestellt werden. Einige der Container sollen in VLAN1, andere in VLAN2, damit wir den Zugriff über die Firewall sauber restriktieren können.
Alles was ich im Internet finde, bezieht sich am Ende auf eine andere Config, als die, die ich suche. Es wird immer was von Routing Tabellen erzählt und blabla, aber das möchte ich ja nicht. Er soll die VLAN1 getaggten packete durch den vorgesehenen NIC leiten und wieder zurück. Das Gleiche soll er mit VLAN2 machen und gut ist.
Ich bin darüber verwundert, dass es so komplex ist. Ich bin echt kein Windows Fan, aber dort kann ich ohne Probleme eine zweite NIC zuweisen, eine zweite IP mit zweitem Gateway vergeben und schon ist die Sau am Fliegen.
Meine Config bisher:
# This is the network config written by 'subiquity'
network:
version: 2
ethernets:
ens01:
dhcp4: false
dhcp6: false
accept-ra: false
link-local: []
match:
macaddress: "00:XX:XX:XX:XX:XX"
driver: vmxnet3
set-name: ens01
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [ "192.168.50.10", "192.168.50.20" ]
search: []
ens02:
dhcp4: false
dhcp6: false
accept-ra: false
link-local: []
match:
macaddress: "00:XX:XX:XX:XX:XX"
driver: vmxnet3
set-name: ens02
addresses:
- 192.168.2.100/24
routes:
- to: default
via: 192.168.2.1
nameservers:
addresses: [ "192.168.50.10", "192.168.50.20" ]
search: []
vlans:
vlan1:
id: 1
link: ens01
vlan2:
id: 2
link: ens02Ich möchte anmerken, dass die Abstände in der YAML Datei eingehalten wurden, daran kanns schon mal nicht liegen. Wenn ich die YAML teste, bekomme ich folgende Fehlermeldung:
"Problem encountered while validating default route consistency.Please set up multiple routing tables and use `routing-policy` instead.
Error: Conflicting default route declarations for IPv4 (table: main, metric: default), first declared in ens02 but also in ens01"
Die Problematik ist klar, er kann nicht mehrere Gateways haben, weil er vermutlich nicht weiß wie er Routen soll. Aber wie erwähnt.... ich sehe keine Notwendigkeit mit Routing Tabellen zu Arbeiten, denn ich will ja, dass die Pakete da raus gehen, wo sie herkamen. Ich dachte durch Angeben des Gateway wäre das für Linux klar.
So langsam bin ich mit meinem Latein am Ende. Habe ich einen Denkfehler?
vg Mr.Robot
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 61881986797
Url: https://administrator.de/contentid/61881986797
Ausgedruckt am: 23.11.2024 um 06:11 Uhr
26 Kommentare
Neuester Kommentar
er kann nicht mehrere Gateways haben
Genau DAS ist dein Denkfehler!Du kannst logischerweise keine 2 Default Routen haben auf der Maschine. Wie sollte das iptechnisch auch gehen?
Lass eine Default Route weg auf einem Adapter, das löst dein Problem.
Die 2te Unsauberkeit ist das du das VLAN 1 benutzt. Das ist etwas ungeschickt, denn das ist in allen Switches meist das Default VLAN und damit immer auch das PVID bzw. Native VLAN was damit dann UNtagged an Trunks anliegt. Du solltest da besser eine andere VLAN ID wählen um nicht in Tagging Problematiken zu kommen.
1
Moin,
der Fehler liegt auch nicht an der Konfig.
Du kannst nicht zweimal ein Default Gateway nutzen. Auf einer NIC musst du es entfernen.
Desweiteren ist natürlich die Frage ob zwei NICs so viel Sinn machen.
Gruß
Spirit
der Fehler liegt auch nicht an der Konfig.
Du kannst nicht zweimal ein Default Gateway nutzen. Auf einer NIC musst du es entfernen.
Desweiteren ist natürlich die Frage ob zwei NICs so viel Sinn machen.
Gruß
Spirit
1
Zitat von @aqui:
Du kannst logischerweise keine 2 Default Routen haben auf der Maschine. Wie sollte das iptechnisch auch gehen?
Lass eine Default Route weg auf einem Adapter, das löst dein Problem.
er kann nicht mehrere Gateways haben
Genau DAS ist dein Denkfehler!Du kannst logischerweise keine 2 Default Routen haben auf der Maschine. Wie sollte das iptechnisch auch gehen?
Lass eine Default Route weg auf einem Adapter, das löst dein Problem.
Soweit war ich auch schon. Wenn ich das aus mehreren Internetposts richtig verstanden habe, wird meist 0.0.0.0/24 als zweite Default Route angegeben, dann nimmt er aber den Gateway der ersten NIC als Route. Und das ist falsch für Pakete aus dem anderen VLAN.
Zitat von @aqui:
Die 2te Unsauberkeit ist das du das VLAN 1 benutzt. Das ist etwas ungeschickt, denn das ist in allen Switches meist das Default VLAN und damit immer auch das PVID bzw. Native VLAN was damit dann UNtagged an Trunks anliegt. Du solltest da besser eine andere VLAN ID wählen um nicht in Tagging Problematiken zu kommen.
Die 2te Unsauberkeit ist das du das VLAN 1 benutzt. Das ist etwas ungeschickt, denn das ist in allen Switches meist das Default VLAN und damit immer auch das PVID bzw. Native VLAN was damit dann UNtagged an Trunks anliegt. Du solltest da besser eine andere VLAN ID wählen um nicht in Tagging Problematiken zu kommen.
Die VLANs haben bereits andere IDs. Ich hab das hier lediglich der Einfachheit halber und der Anonymisierung wegen umbenannt.
es kann nur eine Default-Route geben. Punkt.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Ich glaub dein weiterer Denkfehler ist, dass du meinst pro NIC eine Route zu brauchen.
Das ist natürlich für anliegende Netze nicht der Fall.
Edit: Genau genommen ist meine Aussage nicht ganz richtig. Du könntest die Metric ändern. Dann wäre es wohl möglich.
Mehr als ein Fallback ist das dann nur nicht.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Ich glaub dein weiterer Denkfehler ist, dass du meinst pro NIC eine Route zu brauchen.
Das ist natürlich für anliegende Netze nicht der Fall.
Edit: Genau genommen ist meine Aussage nicht ganz richtig. Du könntest die Metric ändern. Dann wäre es wohl möglich.
Mehr als ein Fallback ist das dann nur nicht.
1 wird meist 0.0.0.0/24 als zweite Default Route angegeben
Welch' ein Blödsinn mit dieser Maske. Solch einen (Internet) Unsinn muss man sicher nicht weiter kommentieren... 
Kollege @Spirit-of-Eli hat ja schon alles zu der Thematik gesagt.
Zitat von @Spirit-of-Eli:
es kann nur eine Default-Route geben. Punkt.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Ich glaub dein weiterer Denkfehler ist, dass du meinst pro NIC eine Route zu brauchen.
Das ist natürlich für anliegende Netze nicht der Fall.
Edit: Genau genommen ist meine Aussage nicht ganz richtig. Du könntest die Metric ändern. Dann wäre es wohl möglich.
Mehr als ein Fallback ist das dann nur nicht.
es kann nur eine Default-Route geben. Punkt.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Ich glaub dein weiterer Denkfehler ist, dass du meinst pro NIC eine Route zu brauchen.
Das ist natürlich für anliegende Netze nicht der Fall.
Edit: Genau genommen ist meine Aussage nicht ganz richtig. Du könntest die Metric ändern. Dann wäre es wohl möglich.
Mehr als ein Fallback ist das dann nur nicht.
Okay, dann stelle ich die Frage anders. Wie kriege ich jeweilige VLAN Packete sauber durchgereicht bis zum Docker? Weil mt Netplan geht es offensichtlich nicht.
Wie hast du die Docker Container denn konfiguriert?
Die werden ja im simpelsten Fall auf eine NIC gebridged und nutzen nach außen hin die Adresse der NIC.
Ich bin kein Docker experte, aber die Konfig kannst du ja beim Start des Containers mitgeben und eben die Bindung an die NIC ändern.
Die werden ja im simpelsten Fall auf eine NIC gebridged und nutzen nach außen hin die Adresse der NIC.
Ich bin kein Docker experte, aber die Konfig kannst du ja beim Start des Containers mitgeben und eben die Bindung an die NIC ändern.
1
Wieso durchgereicht??
Deine beiden NICs sollen in VLAN x und VLAN y arbeiten und Docker bridged lediglich auf die NIC.
Du hast unter VmWare 2 Möglichkeiten:
Version 1 wäre am einfachsten umzusetzen.
Deine beiden NICs sollen in VLAN x und VLAN y arbeiten und Docker bridged lediglich auf die NIC.
Du hast unter VmWare 2 Möglichkeiten:
- Du definierst die beiden NICs der VM UNtagged und machst das direkt auf dem vSwitch des ESXi. Siehe dazu hier und auch hier.
- Du verwendest das funktionelle VLAN 4095 und reichst die VLAN Tags durch den vSwitch durch.
Version 1 wäre am einfachsten umzusetzen.
Zitat von @Spirit-of-Eli:
Wie hast du die Docker Container denn konfiguriert?
Die werden ja im simpelsten Fall auf eine NIC gebridged und nutzen nach außen hin die Adresse der NIC.
Ich bin kein Docker experte, aber die Konfig kannst du ja beim Start des Containers mitgeben und eben die Bindung an die NIC ändern.
Wie hast du die Docker Container denn konfiguriert?
Die werden ja im simpelsten Fall auf eine NIC gebridged und nutzen nach außen hin die Adresse der NIC.
Ich bin kein Docker experte, aber die Konfig kannst du ja beim Start des Containers mitgeben und eben die Bindung an die NIC ändern.
Ja korrekt. Das wäre ja theoretisch der zweite Step. Vorher müssten ja aber beide IP's am Ubuntu ankommen. Ich könnte das jetzt bewerkstelligen, indem ich beide IP's auf eine NIC lege und die jeweils mit den passenden VLANs tagge. Dann hab ich aber wieder das Problem, dass nur ein Gateway angegeben wird. Der Gateway ist in unserem Falle die Firewall. Die bekommt dann Pakete aus dem falschen VLAN.
Dann hab ich aber wieder das Problem, dass nur ein Gateway angegeben wird.
Das ist doch Quatsch. Auch dann hast du intern doch auch 2 Adapter und das du keine mehrfachen Default Gateways haben kannst liegt doch auf der Hand. Sollte ein Server dann raten oder Kaffeesatz lesen welche der zahllosen Default Routen er dann vielleicht nach Gutsherrenart verwendet?!Es ist doch völlig unerheblich ob du das über 2 NICs oder 2 virtuelle VLAN NICs löst. Das Grundproblem bleibt doch.
Die bekommt dann Pakete aus dem falschen VLAN.
Ist ja auch Unsinn. Du kannst ja über dedizierte statische Routen auf dem Server genau bestimmen was auf welcher NIC rausgeroutet werden soll. Du darfst nur nicht 2 gleichwertige Default Gateways definieren.Zitat von @aqui:
Wieso durchgereicht??
Deine beiden NICs sollen in VLAN x und VLAN y arbeiten und Docker bridged lediglich auf die NIC.
Wieso durchgereicht??
Deine beiden NICs sollen in VLAN x und VLAN y arbeiten und Docker bridged lediglich auf die NIC.
Nein, NIC1 soll in VLAN1 arbeiten, NIC2 in VLAN2. Wir reden hier von einem von mir konfigurierten ESXI Cluster mit über 70 VMs in 10 verschiedenen VLANs. Ich bin durchaus bewandert im VLAN Tagging und Konfigurieren von vSwitches. Ich denke das ist alles passend eingerichtet
Netplan bietet mir lediglich keine adäquate Option. Wieso kann ich in Windows Server zwei NICs mit jeweils einem VLAN Taggen und verschiedene Gateways angeben? Immerhin ist das auch der Sinn von einem VLAN. Packete Taggen und dann durchreichen.
Zitat von @aqui:
Es ist doch völlig unerheblich ob du das über 2 NICs oder 2 virtuelle VLAN NICs löst. Das Grundproblem bleibt doch.
Dann hab ich aber wieder das Problem, dass nur ein Gateway angegeben wird.
Das ist doch Quatsch. Auch dann hast du intern doch auch 2 Adapter und das du keine mehrfachen Default Gateways haben kannst liegt doch auf der Hand. Sollte ein Server dann raten oder Kaffeesatz lesen welche der zahllosen Default Routen er dann vielleicht nach Gutsherrenart verwendet?!Es ist doch völlig unerheblich ob du das über 2 NICs oder 2 virtuelle VLAN NICs löst. Das Grundproblem bleibt doch.
Die bekommt dann Pakete aus dem falschen VLAN.
Ist ja auch Unsinn. Du kannst ja über dedizierte statische Routen auf dem Server genau bestimmen was auf welcher NIC rausgeroutet werden soll. Du darfst nur nicht 2 gleichwertige Default Gateways definieren.Entweder reden wir aneinader vorbei, oder du hast die Problematik noch nicht ganz verstanden. Naja danke trotzdem für die Bemühungen.
Wieso kann ich in Windows Server zwei NICs mit jeweils einem VLAN Taggen und verschiedene Gateways angeben?
Das ist Quatsch, denn das geht auch bei Winblows nicht!! Dort entscheidet bekanntlich die Metrik welches Default Gateway genommen wird, bei Linux übrigens auch wenn du unterschiedliche Metriken mitgibst. Ist die Metrik gleich bestimmt die Bindungsreihenfolge welches die dedizierte Default Route bzw. NIC ist für nicht lokale IP Ziele. Die andere ist dann inaktiv. route print lässt grüßen! (ip r Linux)Wie sollte denn deiner Meinung nach die VM entscheiden wenn beide Default Gateways gleiche Metriken haben welches die Absender NIC sein soll?? Vergiss den Unsinn also...IP Routing Grundschule...
Zitat von @aqui:
Wie sollte denn deiner Meinung nach die VM entscheiden wenn beide Default Gateways gleiche Metriken haben welches die Absender NIC sein soll?? Vergiss den Unsinn also...IP Routing Grundschule...
Wieso kann ich in Windows Server zwei NICs mit jeweils einem VLAN Taggen und verschiedene Gateways angeben?
Das ist Quatsch, denn das geht auch bei Winblows nicht!! Dort entscheidet die Metrik welches Default Gateway genommen wird, bei Linux übrigens auch wenn du unterschiedliche Metriken mitgibst. Ist die Metrik gleich bestimmt die Bindungsreihenfolge welches die dedizierte Default Route ist die andere ist dann inaktiv.Wie sollte denn deiner Meinung nach die VM entscheiden wenn beide Default Gateways gleiche Metriken haben welches die Absender NIC sein soll?? Vergiss den Unsinn also...IP Routing Grundschule...
Ja, vielleicht auch schwarze Magie.
Das wird es dann wohl sein!
Entweder reden wir aneinader vorbei
Ja, das macht ihrJa korrekt. Das wäre ja theoretisch der zweite Step. Vorher müssten ja aber beide IP's am Ubuntu ankommen.
Nein, das ist der erste Schritt, die IP's können nie "am Ubuntu ankommen", das kann nur die Netzwerkkarte, bzw. der Port davon. Welche IP und Gateway dann genutzt werden, entscheidet das, was auch immer an diese NIC gebunden wird.Du legst an deinem 24-Port Switch ja auch nicht IP und Gateway pro Port fest, sondern wenn überhaupt ein VLAN und steckst dann einen Client dran.
1
Ich weiß schon, wieso ich die Frage besser in einem englischen Forum gestellt hätte xD..... Deutschland setzen 6. Habe die Lösung mittlerweile gefunden.
Zitat von @Mr.Robot:
Ich weiß schon, wieso ich die Frage besser in einem englischen Forum gestellt hätte xD..... Deutschland setzen 6. Habe die Lösung mittlerweile gefunden.
Ich weiß schon, wieso ich die Frage besser in einem englischen Forum gestellt hätte xD..... Deutschland setzen 6. Habe die Lösung mittlerweile gefunden.
Sehr schön, teilst du sie uns dann auch mit oder wolltest du nur nochmal nachtreten?
2
Selbstverständlich, will ja schließlich nicht nur ein "theoretischer Besserwisser" sein mein Hexenzirkel und ich haben uns beraten und haben folgendes dämonische Ritual ausgearbeitet:
Da wir in 2023 leben, lässt sich das mit Netplan über ein Source Routing lösen. Die YAML Datei muss in /etc/netplan/ liegen. Hier die Beispieldatei zum Teufelswerk:
Zwei Gateways.... verrückte Welt...
mein Hexenzirkel und ich haben uns beraten und haben folgendes dämonische Ritual ausgearbeitet:The iproute2 program, which is included in all current Linux distributions and already installed even, as a rule, can be used for the solution of this problem. Normally, a Linux system only has one routing table, in which only one default gateway can make entries. With iproute2, you have the ability to setup an additional routing table, for one thing, and allow this table to be used by the system based on rules, for another.
Da wir in 2023 leben, lässt sich das mit Netplan über ein Source Routing lösen. Die YAML Datei muss in /etc/netplan/ liegen. Hier die Beispieldatei zum Teufelswerk:
network:
version: 2
renderer: networkd
ethernets:
ens3:
addresses:
- 192.168.3.30/24
dhcp4: no
routes:
- to: 192.168.3.0/24
via: 192.168.3.1
table: 101
routing-policy:
- from: 192.168.3.0/24
table: 101
ens5:
addresses:
- 192.168.5.24/24
dhcp4: no
routes:
- to: default
via: 192.168.5.1
- to: 192.168.5.0/24
via: 192.168.5.1
table: 102
routing-policy:
- from: 192.168.5.0/24
table: 102Zwei Gateways.... verrückte Welt...
Danke für die Aufklärung.
Also genau das was @Spirit-of-Eli
und auch @aqui
schon gesagt haben.
Du kannst keine 2 default Gateways definieren. Routings und dazu passende Gateways kannst du selbstverständlich machen soviel du möchtest und du Netze hast.
Also genau das was @Spirit-of-Eli
Du kannst nicht zweimal ein Default Gateway nutzen. Auf einer NIC musst du es entfernen.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Auf der zweiten könntest du höchstens statische Route nutzen.
und auch @aqui
Du kannst ja über dedizierte statische Routen auf dem Server genau bestimmen was auf welcher NIC rausgeroutet werden soll. Du darfst nur nicht 2 gleichwertige Default Gateways definieren.
schon gesagt haben.
Du kannst keine 2 default Gateways definieren. Routings und dazu passende Gateways kannst du selbstverständlich machen soviel du möchtest und du Netze hast.
1Zitat von @Mr.Robot:
Selbstverständlich, will ja schließlich nicht nur ein "theoretischer Besserwisser" sein mein Hexenzirkel und ich haben uns beraten und haben folgendes dämonische Ritual ausgearbeitet:
Da wir in 2023 leben, lässt sich das mit Netplan über ein Source Routing lösen. Die YAML Datei muss in /etc/netplan/ liegen. Hier die Beispieldatei zum Teufelswerk:
Zwei Gateways.... verrückte Welt...
Selbstverständlich, will ja schließlich nicht nur ein "theoretischer Besserwisser" sein
mein Hexenzirkel und ich haben uns beraten und haben folgendes dämonische Ritual ausgearbeitet:The iproute2 program, which is included in all current Linux distributions and already installed even, as a rule, can be used for the solution of this problem. Normally, a Linux system only has one routing table, in which only one default gateway can make entries. With iproute2, you have the ability to setup an additional routing table, for one thing, and allow this table to be used by the system based on rules, for another.
Da wir in 2023 leben, lässt sich das mit Netplan über ein Source Routing lösen. Die YAML Datei muss in /etc/netplan/ liegen. Hier die Beispieldatei zum Teufelswerk:
network:
version: 2
renderer: networkd
ethernets:
ens3:
addresses:
- 192.168.3.30/24
dhcp4: no
routes:
- to: 192.168.3.0/24
via: 192.168.3.1
table: 101
routing-policy:
- from: 192.168.3.0/24
table: 101
ens5:
addresses:
- 192.168.5.24/24
dhcp4: no
routes:
- to: default
via: 192.168.5.1
- to: 192.168.5.0/24
via: 192.168.5.1
table: 102
routing-policy:
- from: 192.168.5.0/24
table: 102Zwei Gateways.... verrückte Welt...
Sinnfrei ist folgendes:
routes:
- to: 192.168.3.0/24
via: 192.168.3.1und auch das hier:
routes:
- to: default
via: 192.168.5.1
- to: 192.168.5.0/24
via: 192.168.5.1Die Netze liegen doch an. Also müssen die nicht per Gateway erreichbar sein!
2Die Netze liegen doch an. Also müssen die nicht per Gateway erreichbar sein!
Deshalb würde der TO auch in einem englischen Forum dafür eine 6 bekommen. Aber wenns so mit den Hosenträgern zum Gürtel beim TO rennt und er zufrieden ist, ist's doch OK.
1
Es ist die orignal Example Config von Netplan.io, ich behaupte einfach mal die wissen was sie tun weiß jetzt nicht wem ich da mehr vertrauen soll....
weiß jetzt nicht wem ich da mehr vertrauen soll....Zitat von @Drohnald:
Danke für die Aufklärung.
Also genau das was @Spirit-of-Eli
und auch @aqui
schon gesagt haben.
Du kannst keine 2 default Gateways definieren. Routings und dazu passende Gateways kannst du selbstverständlich machen soviel du möchtest und du Netze hast.
Danke für die Aufklärung.
Also genau das was @Spirit-of-Eli
Du kannst nicht zweimal ein Default Gateway nutzen. Auf einer NIC musst du es entfernen.
du kannst auch nur über eine NIC mit der Default Route in andere Netze springen.
Auf der zweiten könntest du höchstens statische Route nutzen.
Auf der zweiten könntest du höchstens statische Route nutzen.
und auch @aqui
Du kannst ja über dedizierte statische Routen auf dem Server genau bestimmen was auf welcher NIC rausgeroutet werden soll. Du darfst nur nicht 2 gleichwertige Default Gateways definieren.
schon gesagt haben.
Du kannst keine 2 default Gateways definieren. Routings und dazu passende Gateways kannst du selbstverständlich machen soviel du möchtest und du Netze hast.
Naja nicht gänzlich. Das ist nur die halbe Miete. Der entscheidende Trick ist die zweite Routingtabelle. Wir könnens auch bis zum St. Nimmerleinstag ausdiskutieren. Hier werden ja scheinbar auch Standardconfigs angezweifelt, ich wüsste nicht auf welcher Ebene wir hier noch reden xD
Vermutlich geht es um dieses Beispiel:
Ist schon strange wie die sich das vorstellen.
Allerdings geht es hier auch wirklich um das Routing zwischen den Interfaces.
How to configure source routing
In the example below, ens3 is on the 192.168.3.0/24 network and ens5 is on the 192.168.5.0/24 network. This enables clients on either network to connect to the other and allow the response to come from the correct interface.
Furthermore, the default route is still assigned to ens5 allowing any other traffic to go through it.
network:
version: 2
renderer: networkd
ethernets:
ens3:
addresses:
- 192.168.3.30/24
dhcp4: no
routes:
- to: 192.168.3.0/24
via: 192.168.3.1
table: 101
routing-policy:
- from: 192.168.3.0/24
table: 101
ens5:
addresses:
- 192.168.5.24/24
dhcp4: no
routes:
- to: default
via: 192.168.5.1
- to: 192.168.5.0/24
via: 192.168.5.1
table: 102
routing-policy:
- from: 192.168.5.0/24
table: 102Ist schon strange wie die sich das vorstellen.
Allerdings geht es hier auch wirklich um das Routing zwischen den Interfaces.
Ein simples ip route add....via... statt der Routing Frickelei in Netplan hätte es auch getan!
Und nein, damit sind keine sinnfreien Routen auf bekannte, lokal angeschlossene Netze gemeint.
Das alles was ins 5er Netz soll über 5.1 geht und ins 3er über .3.1 ist ja evident wie oben schon mehrfach gesagt, da direkt angeschlossen. Für local connectete IP Netze braucht es bekanntlich keine Routen da ja bekannt und die wären überflüssiger Quatsch.
Spannend wäre noch was die ominöse "table: 102" bewirken soll?!
Und nein, damit sind keine sinnfreien Routen auf bekannte, lokal angeschlossene Netze gemeint.
Das alles was ins 5er Netz soll über 5.1 geht und ins 3er über .3.1 ist ja evident wie oben schon mehrfach gesagt, da direkt angeschlossen. Für local connectete IP Netze braucht es bekanntlich keine Routen da ja bekannt und die wären überflüssiger Quatsch.
Spannend wäre noch was die ominöse "table: 102" bewirken soll?!
1
