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 :-)
Angehängte Dateien:
-
netzwerk.png
29 KB
iptables oder ufw wäre ein Kandidat dafür. Oder allgemein "Linux Router", denn genau genommen baust du da einen Router.
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.
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?
Schreib doch mal was zu deinem Router - selbst bei den DAU-kompatiblen Fritten kann man lokale Subnets und ihre Gateways eintragen..
... 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.
Beitrag #6649791 wurde von einem Moderator gelöscht.
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.
Beitrag #6650507 wurde von einem Moderator gelöscht.
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).
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?
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: > 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.
Angehängte Dateien:
-
IMG_20210409_213510.jpg
230 KB
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.