EPOS
Anmeldungsdatum: 14. April 2017
Beiträge: Zähle...
|
Ein gutes Neues Jahr allerseits. Zu meiner Problemstellung zuerst mal die Netzwerkconfig:
# eno1 bond0 mode
auto eno1
iface eno1 inet manual
bond-master bond0
# eno2 bond0 mode
auto eno2
iface eno2 inet manual
bond-master bond0
# bond0 is configured using static network information.
auto bond0
iface bond0 inet static
address 192.168.178.21
netmask 255.255.255.0
gateway 192.168.178.1
network 192.168.178.0
broadcast 192.168.178.255
dns-nameservers 192.168.178.40
hwaddress ether 0C:C4:7A:E2:03:E9
bond-mode 4
bond-miimon 100
bond-lacp-rate 1
bond-slaves eno1 eno2
# enp4s0 is configured OPNsense-AirFiber
auto enp4s0
iface enp4s0 inet static
address 20.20.20.3
netmask 255.255.255.0
gateway 20.20.20.1
network 20.20.20.0
broadcast 20.20.20.255
Beide Netzwerke (Bond 192. und 20.) funktionieren in der Config lokal einwandfrei, aber das Problem ist: 1. Mit aktivierten gateway 20.20.20.1 kann keine Domain über z.B. apt-get aufgelöst werden. 2. Mit deaktivierten gateway 20.20.20.1 ist der Server über die Adresse 20.20.20.3 nicht mehr erreichbar. Der "dns-nameservers" ist ein PiHole und ist nicht das Problem.
Wie bringe ich Ubuntu Server dazu das Internet über "address 192.168.178.21" laufen zu lassen?
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9702
Wohnort: Münster
|
EPOS schrieb: […] die Netzwerkconfig:
[…] iface enp4s0 inet static
address 20.20.20.3
netmask 255.255.255.0
gateway 20.20.20.1
network 20.20.20.0
broadcast 20.20.20.255
Ist Dir das Netzwerk 20.20.20.0/24 von einem IP-Registrar offiziell zugewiesen worden? Wenn nicht, dann missbrauche diesen Adressbereich auch nicht, sondern verwende nur die für private Verwendung freigegebenen Bereiche 10/8, 172.16/12 und 192.168/16 ! Ausschließlich zur Dokumentation kannst Du z.B. 192.0.2/24 benutzen.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
Ich gehe davon aus, dass die zwei Gateway-Zeilen eine Zeile zu viel sind. +1 zur Verwendung von privaten Adressen in privaten Netzwerken.
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
kB schrieb: Ist Dir das Netzwerk 20.20.20.0/24 von einem IP-Registrar offiziell zugewiesen worden? Wenn nicht, dann missbrauche diesen Adressbereich auch nicht ...
Was spielt das Lokal für eine Rolle?
Die 10er 172er und 192er sind nur von der IANA festgelegte Andressen die einer Empfehlung gleich kommen, haben aber keinen funktionalen Wert im privaten Netzwerk. Selbst wenn ich ein 10er zuweise ist das Problem das selbige. Welcher IP-Bereich ist daher vollkommen wurscht. Cranvil schrieb: Ich gehe davon aus, dass die zwei Gateway-Zeilen eine Zeile zu viel sind.
Ja. Grundsätzlich ist standartmäßig nur ein gateway gesamt erlaubt und müsste dem entsprechen, ich hab es mal aufs wesentliche reduziert:
...
iface bond0 inet static
address 192.168.178.21
netmask 255.255.255.0
gateway 192.168.178.1
dns-nameservers 192.168.178.40
...
# enp4s0 is configured OPNsense-AirFiber
auto enp4s0
iface enp4s0 inet static
address 20.20.20.3
netmask 255.255.255.0 Ich habe gerade aber einen Artikel gefunden, der auch 2 Gateways erlaubt. https://www.thomas-krenn.com/de/wiki/Zwei_Default_Gateways_in_einem_System Dies scheint eher die Lösung des Problems zu sein, bin aber gerne für andere Vorschläge offen.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 9702
Wohnort: Münster
|
EPOS schrieb: […] Was spielt das Lokal für eine Rolle?
Es spielt global ein Rolle.
[…] Selbst wenn ich ein 10er zuweise ist das Problem das selbige.
Mag sein, dass Dein Problem gleich bleibt. Aber der rechtmäßige Besitzer hat weniger Probleme, wenn Du dessen Adressbereich nicht missbrauchst.
Welcher IP-Bereich ist daher vollkommen wurscht.
Nein. Auch Du darfst Rücksicht auf andere üben.
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
kB schrieb: EPOS schrieb: […] Was spielt das Lokal für eine Rolle?
Es spielt global ein Rolle.
Es ist mein Netzwerk Lokal und nicht Global.
[…] Selbst wenn ich ein 10er zuweise ist das Problem das selbige.
Mag sein, dass Dein Problem gleich bleibt. Aber der rechtmäßige Besitzer hat weniger Probleme, wenn Du dessen Adressbereich nicht missbrauchst.
Da ich lokal der Besitzer bin, missbrache ich auch nichts. Es ist ja keine öffentliche Adresse!
Welcher IP-Bereich ist daher vollkommen wurscht.
Nein. Auch Du darfst Rücksicht auf andere üben.
Nochmal, es ist mein internes Netzwerk. Leider bringen deine Beiträge auch keine Hilfe sondern nur sinnfreie Grundsatzdiskussionen. Du kannst auch gerne deine Vorstellung von IP-Aress(e)raum mit einbringen, nimm einfach an es ist die Adresse 10.0.0.3, wie schaut dann die Lösung aus?
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
EPOS schrieb: Da ich der Besitzer bin, missbrache ich auch nichts.
Das ist nur halb richtig. Es stimmt, dass du in deinem privaten Netzwerk beliebige IP-Adressen vergeben kannst. Gleichzeitig wird es eben aus verschiedenen Gründen nicht empfohlen. Nehmen wir mal dein Netzwerk 20.20.20.0/24. Dies ist ein nicht-privater IP-Adressbereich, der von der ARIN verwaltet wird und derzeit im Rahmen des Blocks 20.0.0.0/11 Microsoft gehört (ARIN Whois). Wenn du beliebige nicht-private IP-Adressen in deinem lokalen Netzwerk verwendest, steigt das Risiko, dass es zu Kollisionen mit den richtigen Adressen kommt. Im eigenen Heimnetz mit einem halben Dutzend Geräten ist es vielleicht nicht so schlimm, aber sobald man dann mal eine komplette Umstellung aller IP-Adressen in einem Unternehmen durchziehen darf, weil ein Administrator der Meinung war "Das ist mein Netzwerk, also bin ich hier auch der Bestimmer!" wird's schwer zu rechtfertigen.
Du kannst auch gerne deine Vorstellung von IP-Aressraum mit einbringen, nimm einfach an es ist ein 10.0.0.1 wenn es dir dabei besser geht, wie schaut dann die Lösung aus?
Diese nutzlose Grundsatzdiskussion soll unter anderem dazu beitragen, einen Zustand herbeizuführen, der merkwürdige Phänomene vermeiden hilft. Nochmal eine Frage zu den zwei Gateways: Hat es einen bestimmten Grund, warum du darauf bestehst, zwei Gateways auf einer Maschine zu fahren? Warum nicht ein Gateway definieren und den Rest über einfache Routen regulieren?
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
Cranvil schrieb: Diese nutzlose Grundsatzdiskussion soll unter anderem dazu beitragen, einen Zustand herbeizuführen, der merkwürdige Phänomene vermeiden hilft. Nochmal eine Frage zu den zwei Gateways: Hat es einen bestimmten Grund, warum du darauf bestehst, zwei Gateways auf einer Maschine zu fahren? Warum nicht ein Gateway definieren und den Rest über einfache Routen regulieren?
In dem Fall ist es eine nutzlose Grundsatzdiskussion, da es um ein privates LAN geht und nicht "was wäre wenn einmal" Problem ist. Funktional ist dies hier nicht maßgebend oder problematisch, ich werde daher auch nicht mehr weiter darauf eingehen. Es spielt keine Rolle ob das ein 10er oder 20er Netz ist. Es geht nicht perse darum 2 Gateways zu betreiben, sondern den Rechner erreichbar zu halten, auch ohne Gatewayadresse wenn möglich. Die Krux an der Sache ist, das richtige Routing zu definieren.
Alles aufzuzeichen würde den Rahmen sprengen, daher der notwendige Auszug: WAN <> FritzBox <> OPNsense-iNET (APU4C4)
192.168.1.1 192.168.1.2 <> WAN SERVER
192.168.178.1 <> LAN > -------------------------------------------------- > 192.168.178.21
|> 30.30.30.1 <> UPLINK |- > 20.20.20.3
| |
| OPNsense-AirFiber (APU4C4) |
| 172.16.0.3 <> AirFiber (Richtfunk, als Client am entferten Netz) |
| 20.20.20.1 <> SHARE > ----------------------------------------------|
|> 30.30.30.2 <> UPLINK
SERVER
LAN1&2 BOND: 192.168.178.1 <> 192.168.178.21 LAN
LAN3: 20.20.20.1 <> 20.20.20.3 DMZ
... um den es geht. Daher hat der Server 3 Netzwerkkarten, zwei im Bond auf 192.168.178.21 und eine 20.20.20.3. Ja sicher kann man alles in einem Netzwerk laufen lassen, aber dann fehlt die Trennung von 2 Lokalen Netzen deren Geräte nicht alle in einem laufen sollen. Auch ist dann bei lokaler Portauslastung (fast) kein Zugriff mehr von Außen möglich, daher das zweite separate Netz, eben Autark. Daher nochmals... Beide Netzwerke (Bond 192. und 20.) funktionieren in der Config lokal einwandfrei, aber das Problem ist: 1. Mit aktivierten gateway 20.20.20.1 kann keine Domain über z.B. apt-get aufgelöst werden. 2. Mit deaktivierten gateway 20.20.20.1 ist der Server über die Adresse 20.20.20.3 nicht mehr erreichbar. Wie man richtig routet mit Gatways weis ich selbst, das ganze Netz funktioniert einwandfrei ohne Loop oder sonstigen Problemen. Nur wie routet man ohne Gateway auf dem Server?
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
|
encbladexp
Ehemaliger
Anmeldungsdatum: 16. Februar 2007
Beiträge: 17524
|
Was sagt ip r zu der Sache? mfg Stefan
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Die Problematik erinnert mich an den Konflikt beim gleichzeitigen Betreiben von libvirt und docker, wie bspw. unter Docker breaks existing bridge I use for KVM/QEMU. Ich bin da nun nicht so firm drin, aber so wie ich das bisher verstanden habe, fehlt dir das manuelle setzen einer default-route (zuzüglich des masquerading, wenn du NAT brauchst). Damit zwei unterschiedliche Netzwerke miteinander sprechen, musst du die Pakete ja irgendwo routen oder zumindest ip-forwarding nutzen. Wie sieht da deine Konfiguration aus?
|
EPOS
(Themenstarter)
Anmeldungsdatum: 14. April 2017
Beiträge: 46
|
encbladexp schrieb: Was sagt ip r zu der Sache? mfg Stefan
default via 192.168.178.1 dev bond0 onlink
20.20.20.0/24 dev enp4s0 proto kernel scope link src 20.20.20.3
192.168.178.0/24 dev bond0 proto kernel scope link src 192.168.178.21 Problem ist das er bei aktiviertem Gateway 20.20.20.1 lokal alles funktioniert, aber dann keine Internetadressen mehr z.B. für Updates über 192.168.178.1 aufgelöst werden. Das 20.20.20.3 ist eh nur lokal und soll kein Internet bereitstellen/übertragen. Nehme ich das Gateway 20.20.20.1 raus, dann werden wieder anfragen in das Internet über 192.168.178.1 aufgelöst. Die Anfragen an 20.20.20.3 kommen vom Rechner 172.16.0.10. Beide Router-Schnittstellen (172.16.0.3 und 20.20.20.1) sind auf einer OPNsense (APU4C4), für Schnittstellen auf einem Board was OPNsense komplett verwaltet, müssen keine Routen gesetzt werden, laut OPNsense Wiki. Funktioniert das dann nur bei gesetzten Gateways auf den Clients/Servern Netzwerkkarten? Eigentlich soll dem Server ja nur beigebracht werden, das er Internetanfragen über 192... und nicht über 20... machen soll. Aber, konfliktfreier ist es nur ein Gateway einzutragen, daher dem 20. keines zu geben. Hm... ChickenLipsRfun2eat schrieb: ... aber so wie ich das bisher verstanden habe, fehlt dir das manuelle setzen einer default-route (zuzüglich des masquerading, wenn du NAT brauchst). Damit zwei unterschiedliche Netzwerke miteinander sprechen, musst du die Pakete ja irgendwo routen oder zumindest ip-forwarding nutzen...
Joa... das macht die OPNsense, da beide auf dem Router liegen muss hier kein routen oder forwarding eingertragen werden, laut OPNsense Wiki.
Aber ich vermute auch fast, das ich hier mal was probieren sollte.
Das Routing auf der entfernten Fritz ist Ziel:20.20.20.0 und Gateway:172.16.0.3 und funktioniert.
|
Cranvil
Anmeldungsdatum: 9. März 2019
Beiträge: 990
|
EPOS schrieb: Wie man richtig routet mit Gatways weis ich selbst, das ganze Netz funktioniert einwandfrei ohne Loop oder sonstigen Problemen. Nur wie routet man ohne Gateway auf dem Server?
🙄 Ohne ein bisschen Theorie geht's in der Regel nicht, aber ich versuche mal, mich nur auf die Routendefinitionen zu konzentrieren. 😉 Ich gehe davon aus,
dass die FritzBox alles, was sie von außen abbekommt, ungesehen an OPENsense-iNET (Exposed Host) weiterverteilt, dass OPENsense-iNET als NAT-Gateway zwischen FritzBox und den anderen, an die OPNsense-iNET angebunden, Netzwerken auftritt, Hosts im Netzwerk 192.168.178.0/24 OPENsense-iNET (192.168.178.1) als Standard-Gateway verwenden, Hosts im Netzwerk 30.30.30.0/24 OPENsense-iNET (30.30.30.1) als Standard-Gateway verwenden, Hosts im Netzwerk 20.20.20.0/24, die nicht auch Teilnehmer in 192.168.178.0/24 sind, OPNsense-AirFiber (20.20.20.1) als Standard-Gateway verwenden, Hosts im Netzwerk 172.16.0.0/16, die nicht auch Teilnehmer in einem der bereits genannten Netzwerke sind, OPNsense-AirFiber (172.16.0.3) als Standard-Gateway verwenden, die privaten IP-Bereiche grob standardkonforme Mengen an Maskenbits gesetzt haben und die nicht-privaten IP-Bereiche 24er-Netzwerke darstellen, dass es keine anderen NAT-Gateways in diesem Bereich gibt, die irgendwas seltsames machen, und dass es zunächst nur darum geht, den Server mit den Clients im AirFiber-Netz kommunizieren zu lassen.
Die Annahmen basieren auf einer grundlegenderen Annahme: Dass alle beteiligten Systeme irgendwie über deinen einen WAN-Zugang ins Internet gehen können sollen. Wollen wir mal hoffen, dass ich da richtig liege. 😉 Je nachdem, wie du den Netzwerkverkehr kanalisieren willst, hast du mehrere Möglichkeiten. Zuerst der direkteste Weg:
# auf dem Server
ip route add 172.16.0.0/16 via 20.20.20.1 Ein tcpdump sollte dir im Optimalfall zeigen, dass Clients im Netzwerk 172.16.0.0/16 bereits Pakete an den Server senden können, die Antworten jedoch keinen Rückweg finden. Nach Aktivierung der vorgenannten Route sollte die Kommunikation bereits funktionieren. Ein etwas weniger direktes Vorgehen wäre die Konfiguration der relevanten Routen auf der OPENsense-iNET (mangels besseren Wissens zu OPNsense benutze ich die bereits bekannte Notation):
ip route add 172.16.0.0/16 via 30.30.30.2 Das aus meiner Sicht Witzige an der zweiten Lösung ist die Tatsache, dass die Pakete zum Server hin einen anderen Weg nehmen als die Antworten des Servers an die Clients. Wenn beides nicht klappt, müsstest du mal nachschauen, wo deine Situation von meinen Annahmen abweicht und uns das wissen lassen.
|