Linux: Netzwerkbrücke zwischen zwei Subnetzen

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.

(prx) A. K. schrieb:
> nach Netzumschaltung des Servers per
> Stecker.
Genau, weil TO nicht mit dem Gateway/Routen klarkommt.

... 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...

... schrieb:
> - POSTNAT + Masquerading um auf Netze hinter der Fritzbox
> zu kommen.

Nur wenn er zulassen will, dass jemand von aussen ins Netz 2 darf.

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.

... 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.

Der erste Treffer 
https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu-20-04-de 
liefert schon ein sehr schönes Beispiel.

1

sudo ufw default deny incoming

2

# sudo ufw default allow outgoing # alles darf hinaus; oder nur

3

sudo ufw allow dns

4

sudo ufw allow http

5

sudo ufw allow https

6

sudo ufw enable

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.

1

sudo ufw default deny incoming

2

sudo ufw allow dns

3

sudo ufw allow from 192.168.178.1/0 # alles vom router annehmen

4

sudo ufw allow from 192.168.1.0/24 to 192.168.178.1 port 443 # zugriff auf router

5

# oder noch feiner

6

sudo ufw allow in on eno2 to any port 80 # vom interface eno2

7

sudo ufw allow in on eno2 to any port 443

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.

(prx) A. K. schrieb:
> wenn ein Anwender für jede einzelne URL
> eine positive Freischaltung seitens der IT erbitten muss.
Application Firewall (content filter) nicht mit Service Firewall (ports) 
verwechseln.

Dafür gibt es ein schönes Teil: PiHole

Nachtrag zu oben: 
https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands

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:
> Alles andere filtert man durch blacklists.

Eine Blocklist ist ziemlich genau das Gegenteil deines "allow". ;-)

> Mister A. schrieb:
>> Application Firewall (content filter) nicht mit Service Firewall (ports)
>> verwechseln.
Ach Menno... i mog nimma

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).

(prx) A. K. schrieb:
> Bei uns

Mister A. schrieb:
> und wie lautet die Regel dafür?

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.

Bei euch, in seiner Umgebung wäre das

1

sudo ufw allow in on eno2 to any port 8080

2

# oder zusammengefasst

3

sudo ufw allow in on eno2 to any port 80,443,8080

Die negierte Regel vorher verbietet Zugriff auf SN1, außer 
192.168.178.1.
Der Rest erledigt der Router und jagt es ins Internet.

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:
> Die negierte Regel vorher verbietet Zugriff auf SN1, außer
> 192.168.178.1.

Welche konkret meinst du?

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?

Mister A. schrieb:
> Dort einfach das SN1 sperren oder auch nicht.

Im PiHole? Wie geht das?

(prx) A. K. schrieb:
> Im PiHole???
Ja. Gehe lesen oder herumklicken, habe keine Zeit zum malen.

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.

Klick dich einfach mal durch die Menüs.

Mister A. schrieb:
> Klick dich einfach mal durch die Menüs.

Hab ich schon. War immer noch ein DNS-Server.

(prx) A. K. schrieb:
> War immer noch ein DNS-Server.
Schön für dich. Bei mir ist es ein DNS Filter.

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ürde

Sven 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?

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.

1

iptables -t nat -A POSTROUTING -o eno1 -s 192.168.1.0/24 -j MASQUERADE

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.