Router ist die die IP 192.168.178.1
Server ist mit eno1 - 192.168.178.2 mit Router und Switch 1 verbunden
Server ist mit eno2 - 192.168.1.1 mit Switch 2 verbunden
Mobile Geräte, Desktop PCs und Drucker sind im Subnetz 1 - 192.168.178.0
3D Drucker, Desktop PCs und diverse Arbeitssachen sind um Subnetz 2 -
192.168.1.0
Der Server verteilt alle DHCP in beiden Subnetzen. Er läuft unter Ubuntu
Server 20.04LTS.
Ich würde gerne Subnetz 2 (192.168.1.0/24) auf eno2 den Zugriff auf das
Internet über den Router im Subnetz 1 (192.168.178.1) auf eno1 gewähren.
Die Rechner sollen jedoch nicht auf das Subnetz 1 (und vice versa)
zugreifen dürfen.
Wie stelle ich das um dümmsten an, nach was muss ich suchen oder
googlen.
Lieben Dank :-)
Was Du willst, ist genau keine Brücke (bridge) sondern ein Router.
Dazu musst Du IP-forwarding aktivieren und die Routen-Tabelle
entsprechend einrichten, so dass aller Verkehr, der nicht durch andere
Routing-Einträge abgedeckt wird (= default route), an Deinen
Internet-Router 192.168.178.1 geht, der für das Subnetz 2 über
192.168.1.1 als Gateway fungiert.
"Linux" + "router" oder "Linux" + "routing" ist da das richtige
Suchmaschinen-Stichwort, "man route" (veraltet) oder "man ip-route"
könnte Dir auch weiter helfen.
Mit iptables (veraltet) oder nftables kannst Du Dir dann eine Firewall
bauen, falls Du die zwischen den Subnetzen brauchst. ufw setzt auf
iptables auf und macht Dir die Verwaltung der firewall etwas leichter.
Np R. schrieb:> so dass aller Verkehr, der nicht durch andere> Routing-Einträge abgedeckt wird (= default route), an Deinen> Internet-Router 192.168.178.1 geht, der für das Subnetz 2 über> 192.168.1.1 als Gateway fungiert.
Der Edge-Router 192.168.178.1 wird Requests aus 192.168.1.0/24 nicht
korrekt ins Internet routen, wenn sie aus seiner Sicht aus
192.168.1.0/24 kommen, da sie nicht aus dem ihm bekannten lokalen Netz
kommen und folglich kein NAT stattfindet.
Im Server muss also per NAT alles aus 192.168.1.0/24 auf Quelle
192.168.178.2 abgebildet werden. Zudem wird er alles mit Ziel in
192.168.178.0/24 direkt ins Netz schicken, nicht an den Edge-Router. Das
will er aber vermeiden.
Routing alleine reicht also nicht. Eine Firewall wird sich kaum
vermeiden lassen, sie löst beide Probleme.
Dem anderen Topic nach
Beitrag "Linux: CFG Dateien mit Variablen befüllen" riecht es
nach ganz anderen Problemen.
Sieht nach einer zerschnittenen Umgebung aus.
Die Clients im Subnet 1 hängen im roten Netz, hinter einer Fritte? Der
Arbeitsbereich hinter dem Server im Subnet 2.
Wie wäre es mit ein wenig Struktur - z.B. OPNsense als Router und dem
"Server" eine NAS Konfiguration zu verpassen.
Ansonsten finde ich den Vorschlag zum 2. Thema mit Ansible sehr gut.
Rene K. schrieb:> Der Server verteilt alle DHCP in beiden Subnetzen
In Edge-Routern (hier 192.168.178.1) ist DHCP meist von Haus aus
eingeschaltet. Hier hoffentlich nicht.
Mister A. schrieb:> Sieht nach einer zerschnittenen Umgebung aus.
Es sieht nach 2 Varianten aus. Hier mit 2 getrennten Netzwerken am
Server und im Nachbarthread nach Netzumschaltung des Servers per
Stecker.
Man wird wohl folgendes brauchen:
- PRENAT um das 2. Netz in das 1. Netz abzubilden, und
- POSTNAT + Masquerading um auf Netze hinter der Fritzbox
zu kommen.
PRENAT ist in dem Sinne tueckisch, weil alle Zugriffe
auf eine IP abgebildet werden.
Falls Linux das mittlerweile kann: waere ein NAT Pooling
u.U. eine bessere Loesung.
... schrieb:> Falls Linux das mittlerweile kann
Nur rein interessehalber und nicht um einen Flamewar zu starten: Was
meinst Du mit "falls" und "mittlerweile"? Ist das nicht steinalt?
... schrieb:> - PRENAT um das 2. Netz in das 1. Netz abzubilden, und> - POSTNAT + Masquerading um auf Netze hinter der Fritzbox> zu kommen.
Er braucht für die clients im SN2 nur die route für 0.0.0.0 zum
192.168.1.1 (das Gateway über den DHCP verteilen).
Am 192.168.1.1 dann nur noch 2 outgoing Regeln für dest:80 und :443 zum
passieren über 192.168.178.1.
Und das forwarding nicht vergessen.
Ich würde meinen clients (keinen) einfach so den Freifahrtschein zum
Gateway geben. Die müssen alle durch den OPNsense router/filter durch.
Quatschen dürfen sie innerhalb ihrem Subnet und mit der Firewall. Nix
Cloud und so...
Mister A. schrieb:> Am 192.168.1.1 dann nur noch 2 outgoing Regeln für dest:80 und :443 zum> passieren über 192.168.178.1.
Aber:
Rene K. schrieb:> Die Rechner sollen jedoch nicht auf das Subnetz 1 (und vice versa)> zugreifen dürfen.
Wird das nicht explizit per Regelwerk verboten, ist es möglich.
> Nur wenn er zulassen will, dass jemand von aussen ins Netz 2 darf.
Mein Vorschlag inkludiert natuerlich auch obligatorisch passend
gesetzte SRC- und DST-Filter. Muss man die nun extra erwaehnen?
Die ergeben sich doch aus dem Context dessen was man tun will.
Und natuerlich kann man auch PRE- und POST-NAT mit den falschen
Schrauben versehen.
> Ist das nicht steinalt?
Ein Cisco-Enterprise IOS 10.3 konnte nicht mal NAT.
Immer lustig wenn Jungspunde von steinalt reden...
... schrieb:> Immer lustig wenn Jungspunde von steinalt reden...
Aha, demnach bist Du also wesentlich älter als ich. Dann hast Du sicher
die letzten 10 Jahre in der Cryo-Kammer verbringen müssen, was auch
erklärt, weshalb Du von "mittlerweile" schreibst.
Ganz ehrlich... ich schrieb doch "nicht um einen Flamewar zu starten".
Konntest Du nicht einfach ganz sachlich antworten, wieso Du meinst, dass
da erst "mittlerweile" ein Feature kürzlich hinzugekommen ist? War das
so schwer? Vielleicht meinst Du ja etwas ganz anderes als ich oder
tatsächlich ein neues Detail.
(prx) A. K. schrieb:> Wird das nicht explizit per Regelwerk verboten, ist es möglich.
Da hast Du Recht. Er braucht also auch netfilter.
(prx) A. K. schrieb:> Wird das nicht explizit per Regelwerk verboten, ist es möglich.
Das Grundprinzip beim Design einer jedem Firewall besteht darin alles zu
schließen (letzte Regel) und nur benötigte Ports für Dienste zu öffnen.
Regeln werden daher immer als allow angesehen.
Nicht umgekehrt. Als wäre es ein Sieb, wo man Löcher schließt bis es
vielleicht dicht wird.
Warten wir ab bis sich der TO wieder meldet. Die Wahrscheinlichkeiten
und Möglichkeiten wurden schon alle durchgespielt.
Und wie sieht ein solches ausschliesslich auf "allow" basierendes
Regelwerk aus, wenn - wie hier gewünscht - voller ausgehender
Internet-Zugang aus Netz 2 möglich sein soll, ohne dabei aber auf das
Netz 1 zugreifen zu können?
Du kannst natürlich altenativ dem TE vorschreiben, was er zu wollen hat.
Mister A. schrieb:> Das Grundprinzip beim Design einer jedem Firewall besteht darin alles zu> schließen (letzte Regel) und nur benötigte Ports für Dienste zu öffnen.> Regeln werden daher immer als allow angesehen.
Solche Prinzipien sind Leitregeln, keine religiösen Dogmen. Es ist (bei
uns) kein praktikabler Ansatz, wenn ein Anwender für jede einzelne URL
eine positive Freischaltung seitens der IT erbitten muss.
Hat man beispielsweise eine konkrete Liste von inakzeptablen Zielen,
Protokollen oder Anwendungen, dann werden die oben abgeblockt, die
allgemeiner gehaltenen zulässigen Ziele mittendrin zugelassen, bevor
unten alles abgeblockt wird, was übrig bleibt.
# sudo ufw default allow outgoing # alles darf hinaus; oder nur
3
sudoufwallowdns
4
sudoufwallowhttp
5
sudoufwallowhttps
6
sudoufwenable
Rene K. schrieb:> Ich würde gerne Subnetz 2 (192.168.1.0/24) auf eno2 den Zugriff auf das> Internet über den Router im Subnetz 1 (192.168.178.1) auf eno1 gewähren.> Die Rechner sollen jedoch nicht auf das Subnetz 1 (und vice versa)> zugreifen dürfen.
Das ganze kann man sich nach Belieben anpassen, weiter zudrehen oder
lockern.
(prx) A. K. schrieb:> Du kannst natürlich altenativ dem TE vorschreiben, was er zu wollen hat.
Das tu ich gar nicht.
Mister A. schrieb:> Application Firewall (content filter) nicht mit Service Firewall (ports)> verwechseln.
Wobei der TE weder Ports noch Applications erwähnt, sondern IP-Adressen.
Wie nennt sich diese Sort Firewall?
In Firewalls jenseits einfacher Filter hat man es sowieso mit all dem
zusammen zu tun, also mit Content, Ports und Adressen. Gerne auch alles
zusammen in einer Regel. Was hat man davon, wenn man für diese eine
Regel die Begriffe Content-, Service- und Address(?)-Firewall einführt?
Nützlicher ist eine Differenzierung zu Application-Proxies, die teils in
Firewalls integriert sind, sich aber verfahrenstechnisch erheblich davon
unterscheiden können.
(prx) A. K. schrieb:> Wobei der TE weder Ports noch Applications erwähnt, sondern IP-Adressen.> Wie nennt sich diese Sort Firewall?
IP Adressen als Internet-Ziel sind generell tabu. Außnahmen (eigener
Server, Cloud etc.) gibt man frei. Alles andere filtert man durch
blacklists.
Erwähnen tut er, er möchte http+https hinaus haben. Das ist :80+443+53
via 192.168.178.1. Also outgoing deny !192.168.178.1
Mister A. schrieb:> Dafür gibt es ein schönes Teil: PiHole
PiHole ist im Home-Szenario prima, hat aber wenig mit dem Thread zu tun.
Obendrein ist der meist ein Beispiel für einen selektiven Negativfilters
(deny/drop) für Werbung und anderes Unerwünschte. Es entspricht also
nicht deinem Grundprinzip eines Positivfilters (allow). Oder willst du
im PiHole ausschliesslich bestimmte Sites freigeben, alles andere
blocken.
Mister A. schrieb:> Erwähnen tut er, er möchte http+https hinaus haben. Das ist :80+443+53> via 192.168.178.1. Also outgoing deny !192.168.178.1
Dummerweise haben wir in der Firma ein paar Sites mit Port 8080. An die
kommt er dann schon mal nicht ran.
Obendrein haben Pakete, die über den Edge Router hinaus ins Internet
gehen, nicht die Zieladresse 192.168.178.1, sondern beispielsweise
172.67.70.44. Sie werden nur über den Edge Router geleitet. Dessen
innere IP steht aber nicht im Paket drin.
(prx) A. K. schrieb:> Dummerweise haben wir in der Firma ein paar Sites mit Port 8080. An die> kommt er dann schon mal nicht ran.
und wie lautet die Regel dafür?
Mister A. schrieb:> (prx) A. K. schrieb:>> Dummerweise haben wir in der Firma ein paar Sites mit Port 8080. An die>> kommt er dann schon mal nicht ran.> und wie lautet die Regel dafür?
Bei uns: ClientBrowser => ProxyServer:ProxyPort => Internet:allePorts.
Den Versuch, ausgehende Browser-Zugriffe auf das weltweite WWW in
zulässige und unzulässige Ports aufzudröseln, überlasse ich Sisyphos.
Sicherheit bringt das sowieso keine. Dank HTTPS kommt man mit
Content-Analyse ohne Decryption mittlerweile auch nicht sehr weit
(anderes Thema, etwa Tunnel von Fremdprotokollen über erlaubte :80 oder
:443).
Für den TE? Das in ufw zu formulieren überlasse ich gerne dir, hab zu
wenig Übung darin (andere Produkte). Sinngemäss:
allow eno2 => 192.168.178.1:443, für Router-Config aus Netz 2
deny eno2 => 192.168.178.x/24, blockiert Netz 1 aus Netz 2
allow eno2 => alles, wenn freier Zugriff ins Internet gewünscht
Aber das geht gegen deine Prinzipien. Kommt natürlich noch NAT dazu.
Und was ist mit Port 9080, und ...? Willst du ernsthaft dem ganzen
weltweiten Internet vorschreiben, dass Webserver ausschliesslich auf 80,
443 und ausnahmsweise auch 8080 konfiguriert sein dürfen? Tipp: ist es
nicht.
Mister A. schrieb:> Erwähnen tut er, er möchte http+https hinaus haben
Du verwechselst hier Protokolle und Ports.
HTTP(S) sind Protokolle, keine Ports.
Ich schreibe gar nichts vor.
Unterscheiden zwischen Port und Protokoll kann ich sehr wohl. http ist
kein Protokoll sondern ein Dienst. tcp wäre das Protokoll.
Du machst es mir echt schwer. Möchtest du nicht die o.g. urls zum Thema
kurz durchlesen. Vielleicht erübrigen sich einige Fragen.
Ohne jetzt alles gelesen zu haben, von dem sicher viel wahr ist, wie
wäre es:
An der Fritzbox einfach GästeLAN auf LAN4 aktivieren? Okay die IP ist
glaube ich nicht änderbar?
Mister A. schrieb:> http ist kein Protokoll sondern ein Dienst. tcp wäre das Protokoll.
Protokolle gibts auf allen OSI-Layern, hübsch gestapelt.
Das "HyperText Transport Protocol" ist eines davon.
Ausformuliert ist beispielsweise ein Apache Webserver ein Dienst
(Service), der das Protokoll HTTP spricht und vielleicht httpd heisst.
Sven L. schrieb:> An der Fritzbox einfach GästeLAN auf LAN4 aktivieren? Okay die IP ist> glaube ich nicht änderbar?
Stimmt, das wäre auch eine Möglichkeit.
Wobei, wenn ich auf Firewall-Regel-Orgien verzichten müsste, eher den
PiHole auf den Server klatschen würde. Dort einfach das SN1 sperren oder
auch nicht.
Den DNS Server (also 192.168.1.1) via DHCP an SN2 verteilen würde.
Mann müsste sich nicht herumquälen und hätte auch noch einen filter
(content filter mit white/blacklist) für die Surferei. Würde auch gleich
sehen wohin die clients so herumtelefonieren :)
Und nochmal: ich schreibe gar nichts vor, teile nur Ideen und
Möglichkeiten.
(prx) A. K. schrieb:> Protokolle gibts auf allen OSI-Layern, hübsch gestapelt.> Das "HyperText Transport Protocol" ist eines davon.
Gegen dich kommt man nicht an. Auf Stierkämpfe habe ich keinen Bock.
Ich könnte nun fragen, wie die Regel lauten würde um eine Verbindung auf
tcp zu beschränken oder es einfach sein lassen. Jetzt sind wir schon bei
den Layern angekommen. Ob das dem TO hilft?
Der Pi-hole ist ein DNS-Server. Von Zugriffen, die direkt auf die IP
gehen, oder den Namen per Hosts-File übersetzen, kriegt der nichts mit.
Die werden folglich dadurch nicht blockiert.
Mister A. schrieb:> (prx) A. K. schrieb:>> War immer noch ein DNS-Server.> Schön für dich. Bei mir ist es ein DNS Filter.
Immerhin sind wir uns darüber einig, dass er mit DNS zu tun hat. Und das
bedeutet, dass er bei http://192.168.178.80 nicht mitspielt, es somit
nicht verhindert.
Mister A. schrieb:> Schön für dich. Bei mir ist es ein DNS Filter.
Trotzdem, hat prx recht. Der Pi hängt mit einem Bein im LAN, dh der
Traffic muss nicht durch ihn gehen.Man kann ohne Firewall jede IP direkt
erreichen.
Ich gehe davon aus, dass er die Software Pi-hole auf dem Server
installieren will, und nicht einen Raspberry oben aufs Server-Gehäuse
klatschen will. ;-)
Mister A. schrieb:> eher den PiHole auf den Server klatschen würdeSven L. schrieb:> Der Pi hängt mit einem Bein im LAN
Im Prinzip ist das kein Hinderungsgrund. Mit VLANs wachsen auch
Einbeinigen weitere virtuelle Beine, also mit Netztrennung. Aber auch
dann reicht ein DNS Server/Filter alleine nicht aus. Ein IP-Filter auf
dem RPi oder auf dem Server hingegen schon. Ob man das schon Firewall
nennt, ist ein anderes Thema.
(prx) A. K. schrieb:> Technisch gesehen ist das kein Hinderungsgrund. Mit VLANs kriegt er> virtuelle Beine mit Netztrennung. Aber auch dann reicht ein DNS> Server/Filter alleine nicht aus.
Das wird aber schwierig zum Umsetzen, für jemanden der einen Thread
aufmacht um zu fragen, wie er zwei Subnetze miteinander verbindet.
Vom dem her.
Aber wenn er einen Server hat, könnte man auch einen Proxy Server mit
entsprechenden ACL aufsetzen.
Naja Möglichkeiten gibt es viele.
Alles kein Grund hier zu streiten.
Sven L. schrieb:> Trotzdem, hat prx recht. Der Pi hängt mit einem Bein im LAN, dh der> Traffic muss nicht durch ihn gehen.Man kann ohne Firewall jede IP direkt> erreichen.
Muss und kann nicht. Wenn man das SN1 sperrt kommen auch verirrte
Clients nicht ins SN2 rüber. Einbahnstraße.
Sie müssen einen DNS (ihren 192.168.178.1 od. einen aus 178.0/24)
kontaktieren.
So halte ich den SmartTV+Androids fern und eingesperrt. Die suchen sich
erstaunlicher weise immer wieder Wege hinauszukommen.
Sven L. schrieb:> Das wird aber schwierig zum Umsetzen, für jemanden der einen Thread> aufmacht um zu fragen, wie er zwei Subnetze miteinander verbindet.
Das stimmt allerdings.
> Aber wenn er einen Server hat, könnte man auch einen Proxy Server mit> entsprechenden ACL aufsetzen.
Und Routing zwischen den Netzen weglassen. Ja, das ginge. Kommt dann
ohne Filter und ohne NAT aus.
Mister A. schrieb:> Sie müssen einen DNS (ihren 192.168.178.1 od. einen aus 178.0/24)> kontaktieren.
Sie müssen überhaupt kein DNS kontaktieren, wenn sie mit IP-Adressen
oder Hosts-File arbeiten.
Und sobald dein TV smart genug ist, DNS-over-HTTPS zu verwenden, und
sich dafür bei z.B. Cloudflare oder Google bedient, wirds haarig. Ist
bei Android in Arbeit. DNS-over-TLS ist schon drin. Addiere certificate
pinning, und der Pi-hole hat ganz schlechte Karten. Würde ich den
TV-Bauern jederzeit zutrauen.
(prx) A. K. schrieb:> Ist> bei Android in Arbeit.
Aha, da habe ich schon was gesehen, konnte es noch nicht ordentlich
zuordnen.
Einigen clients (Android) hängen sich den .local Suffix dran und
kontaktieren domain.tld.local.
Bisher habe ich alle *.*.local Domains geblacklisted.
Habt ihr einen Tipp wie damit umgehen?
@ Np R:
> NAT Pooling
verteilt das, was beim Masquerading a la Linuxschen iptables
ueber eine IP-Adresse und eine Connection/Masqueradingtable
laeuft auf mehrere/viele Adressen eines Pools.
Portnummern gibt es halt nicht so viele. (< 65536)
Und wenn es nicht nur eine einstellige Zahl an Clients ist,
wird es da sehr schnell eng.
Typisches Einsatzfeld: Edgerouter vom Mobilfunk
> Aha, demnach bist Du also wesentlich älter als ich.
Moeglicherweise.
Fuer das Szenario des TO bieten sich viele Loesungen an.
Ein PRENAT seines Netzes 2, das zusaetzlich ein DST-filter
auf die 192.168.178.1 beinhaltet, waere wohl das einfachste.
Fuer HTTP und HTTPS kein Problem.
VOIP, als bidirektionales Protokoll, wuerde hingegen nicht
funktionieren.
Fritzboxen benutze ich nicht und kenne sie demzufolge auch nicht.
Ein einfaches Routing koennte moeglicherweise Probleme machen.
Mindestens muesste man wohl fuer das LAN2 eine statische Route
eintragen.
Geraete bei denen DNS over HTTPS nicht abschaltbar ist,
wuerde uebrigens ich nicht kaufen. Ganz einfach.
Uh uh uh, ein Tag nicht da und es geht hier los :-D
Ja im Grunde muss ausschließlich HTTP/S übertragen werden.
Die Route ins Netz ist ganz einfach durch einen Eintrag in die IPTABLES
geschehen.
Dies persistent gemacht und es klappt wunderbar.
Damit ist natürlich SN2<->SN1 noch möglich. Und die Ports sind alle
Richtung Netz offen. Ich habe mich gestern mal ein wenig mit der UFW
befasst. Eine DENY ALL -> OPEN SELCETED Regel finde ich da ganz gut. Da
kann ich explizit öffnen wenn ich einen Port benötige. Es ist ja jetzt
noch so das ich keinen Zugriff auf den Router und das Netz hätte, wenn
ein Port hinzukommt / weg kann.
Unter UFW würde ich dann mit folgendem Routen - an den Filterregeln
bastel ich noch:
1
*nat
2
:POSTROUTING ACCEPT [0:0]
3
-A POSTROUTING -s 192.168.1.0/24 -o
4
eno1 -j MASQUERADE
5
COMMIT
Ich danke dennoch vielmals für die angeregte Diskussion, da bekommt man
viel Anregungen.
p.s.: Die beiden Switch sind übrigens Managed Netgear GS716T ProSafe.
Eventuell wäre eine 'Firewall' darüber auch möglich.
Hier sind die meisten wohl besoffen, anders ist es nicht zu erklären,
dass hier fast jeder die wildesten NAT-Geschichten pfuschen will.
(prx) A. K. schrieb:> Der Edge-Router 192.168.178.1 wird Requests aus 192.168.1.0/24 nicht> korrekt ins Internet routen, wenn sie aus seiner Sicht aus> 192.168.1.0/24 kommen, da sie nicht aus dem ihm bekannten lokalen Netz> kommen und folglich kein NAT stattfindet.
Das ist schon mal grundsätzlich falsch.
Auf dem Internet-Router findet ein Source-NAT (SNAT) bzw. Masquerading
auf dem WAN-Interface statt. Und das geschieht grundsätzlich bei
Outbound-Verkehr auf dem (WAN-)Interface, da spielt die Source-Adresse
des Pakets keine Rolle. Beim SNAT wird die Source-Adresse durch eine
fixe Adresse ersetzt, und beim Masquerading eben durch die Adresse des
(Outbound-)Interfaces.
Rene K. schrieb:> Router ist die die IP 192.168.178.1>> Server ist mit eno1 - 192.168.178.2 mit Router und Switch 1 verbunden> Server ist mit eno2 - 192.168.1.1 mit Switch 2 verbunden
Dazu bedarf es lediglich auf dem Router (192.168.178.1) eine einfache
statische Route (oder entsprechenden Eintrag in der Web-Oberfläche):
1
ip route add 192.168.1.0/24 via 192.168.178.2
Für den Server muss man höchstwahrscheinlich nichts machen, da er eh
schon eine Default-Route auf den Router hat. Falls die Default-Route
fehlen sollte:
1
ip route add default via 192.168.178.1
Mit diesem simplen Kindergarten-Routing funktioniert der
Netzwerk-Verkehr völlig problemlos.
Fehlt nur noch:
> Ich würde gerne Subnetz 2 (192.168.1.0/24) auf eno2 den Zugriff auf das> Internet über den Router im Subnetz 1 (192.168.178.1) auf eno1 gewähren.> Die Rechner sollen jedoch nicht auf das Subnetz 1 (und vice versa)> zugreifen dürfen.
Das kann man mit handgeschrieben iptable-Einträgen machen, oder
irgendwelchen Firewall-Scripts von obscur bis maximal kompliziert, oder
am einfachsten mit zwei simplen Policy-Routing-Einträgen:
1
ip rule add from 192.168.178.0/24 to 192.168.1.0/24 iif eno1 prohibit
2
ip rule add from 192.168.1.0/24 to 192.168.178.0/24 iif eno2 prohibit
Fertig ist der Lack. Kein NAT-Albtraum, keine iptables-Wüste, keine
komischen Firewall-Scripts, einfach nur blankes IP-Routing.