Ich habe die Situation in der beigefügten Skizze mal dargestellt. Ein Server soll aus zwei Netzen erreichbar sein, ohne dass im Router 2 massig Port-Forwardings eingerichtet werden sollen. Der Server hat 2 Netzwerkkarten und die zu bewegenden Daten sind nicht so groß, dass man Teaming/Aggregation zwingend benötigt, sie können also problemlos unabhängig von einander konfiguriert werden. An den beiden Switchen (in den beiden Subnets) hängen natürlich jeweils noch weitere Geräte, ich habe die nur in der Skizze weggelassen. Genau genommen soll der Server für LAN1 als DB- und Fileserver dienen, für LAN2 soll die RDP-Funktion zur Konfiguration und Wartung von Geräten (z.B. per Browser/WebGUI oder SSH) dienen. Ich bin der Ansicht, dass das so möglich sein sollte, ein sog. Loop dürfte nicht entstehen, solange man nicht explizit eine Routig-Funktion zwischen den beiden NICs auf dem Server aktiviert (was nicht vorgesehen ist), oder?
Angehängte Dateien:
-
lan-dual-server.png
56 KB
:
Bearbeitet durch User
Ich würde die beiden Server als getrennte Maschinen (mit VMware ESXi) installieren. Dann wäre sichergestellt, dass auch die Netztrennung kein Problem. Gruss Jörg
Ich kann die IP 192.168.10.2 des Servers in der Skizze noch nicht so ganz zuordnen, die scheint mir nicht zu Deiner Beschreibung zu passen. Frank E. schrieb: > Genau genommen soll der Server für LAN1 als DB- und Fileserver dienen, > für LAN2 soll die RDP-Funktion zur Konfiguration und Wartung von Geräten > (z.B. per Browser/WebGUI oder SSH) dienen. Das sind 2 vollkommen unterschiedliche und voneinander unabhängige Funktionen. Aus Gründen der Sicherheit und für eine bessere Wartbarkeit (=Du kannst den einen Teil anpassen, ohne den anderen auch mit zu beeinflussen) wären hier 2 verschiedene Maschinen vermutlich sinnvoller. Wenn die Leistung der Hardware das hergibt, könntest Du hier z.B. auf Virtualisierung setzen.
Moin, - so richtig nachdenken will ich nicht, aber: Du hast zwei unabhaengige Gateways. Du musst Dir natuerlich Gedanken machen wie Du die zwei unabhaengige Datenstroeme zu Deinem Server routest (Sp?) und, je nach Interface, in der Firewall routen. Undankbar. Den Kunden eine andere Loesung vorschlagen. Welches Betruebssystem wird benutzt? Gruesse Th.
Warum nicht Router 2 weglassen und alles mit dem Server machen?
Kein Problem. Besonders dann nicht wenn der Server 2 Netzwerkkarten hat. Das mache ich mit meinen PC genau so. Gerd E. schrieb: > Ich kann die IP 192.168.10.2 des Servers in der Skizze noch nicht so > ganz zuordnen, die scheint mir nicht zu Deiner Beschreibung zu passen. Ich denke das ist ein Zahlendreher beim Server. Das muss da 192.168.2.10 heißen. Was funktioniert aber nicht üblich ist. Üblich ist, das die Server immer die letzte Stelle der IP ne 0 ist.
Kein Problem. Ich nehme mal an (die Info fehlt), dass Linux drauf läuft. Je eine Netzwerkkarte in ein Netzwerk, IP zuweisen. Jeweils das korrekte Gateway und Nameserver eintragen. Auf Server alle Dienst starten, die es braucht. Pro Dienst kannst in der Regel eh schon Zugriffsrechte eintragen, wer drauf darf. Zusätzlich eine Firewall z.B. Shorewall installieren, damit kannst dediziert die IPTables einstellen und definieren, wer wie wo drauf zugreifen darf. Mehr ist nicht zu tun.
Schlaumaier schrieb: > Üblich ist, das die Server immer die letzte Stelle der IP ne 0 ist. Den Satz verstehe ich nicht so ganz -- weder grammatikalisch noch fachlich. Vermutlich hängt das miteinander zusammen. @ TO: Sollte prinzipiell gehen. Du must auch etwas darauf achten, über welchen Port (d.h. IP) die jeweiligen Antwortpakete versendet werden (Beispielsweise: Ein Server aus dem Subnet .179/24 schreibt an .10.2 -- Antwort sollte eigentlich dann auch über .10.2 laufen). Das Ganze kann etwas aufwändiger zu konfigurieren sein. Ich schließe mich aber dem Rat von oben an: Wenn die beiden Dienste nichts miteinander zu tun haben, würde ich auch versuchen, sie zu trennen.
Frank E. schrieb: > Ich bin der Ansicht, dass das so möglich sein sollte, ein sog. Loop > dürfte nicht entstehen, solange man nicht explizit eine Routig-Funktion > zwischen den beiden NICs auf dem Server aktiviert (was nicht vorgesehen > ist), oder? Ja, das ist soweit korrekt. Die Dienste sollten dann sinnvollerweise auch nur an das Interface gebunden werden, das in dem Netz hängt, in dem sie gebraucht werden. Aber DB & Fileserver sollte das kein Problem sein. Was es mit dem RDP Service auf sich hat, weiß ich allerdings nicht - kenne ich nicht. Zum Thema Sicherheit: Natürlich findet kein Routing auf dem Server statt. Ein Client im Netz A kann also keine Route konfigurieren, die über den Server in Netz B führt. Aber: Wenn jemand aus Netz A Zugriff auf den Server erlangt (gewollt oder ungewollt), dann kann er von dort aus in Netz B springen. Über diesen Weg könnte man sich z.B. auch SSH Tunnel definieren, die dann zu einen Host im Netz B führen. Routing ist also ggf. nicht das einzige Risiko. Kann man natürlich auch alles als nützliches Feature sehen. Ist vielleicht die Frage, wie strikt die beiden Netze getrennt werden sollen.
Ich schliesse meine Server im allgemeinen per tagged VLAN an. Dann kann ich mir aussuchen, in welchen LANs sie etwas tun sollen. Das kann dann auch ein Dutzend werden und nicht nur 2.
Schlaumaier schrieb: > Üblich ist, das die Server immer die letzte Stelle der IP ne 0 ist. Es gibt zwei Adressen im Subnetz, die man nicht für Geräte verwendet. Die eine hat nur Einsen und steht für Broadcasts, die andere hat nur Nullen und steht für das gesamte Subnetz. Weshalb 192.168.178.0 und 192.168.178.255 bei Netmask 255.255.255.0 reserviert sind. Wie man ansonsten innerhalb seinen Netzes vorgeht ist Sache des persönlichen Geschmacks.
:
Bearbeitet durch User
Die IP 192.168.10.2 in der Grafik ist tatsächlich ein Tippfehler, muss 192.168.2.2 heissen. Ansonsten Danke für die Tips.
Cartman schrieb: > Ich schliesse meine Server im allgemeinen per tagged VLAN an. > Dann kann ich mir aussuchen, in welchen LANs sie etwas tun sollen. > Das kann dann auch ein Dutzend werden und nicht nur 2. Das setzt aber auch Switche voraus, die das unterstützen, die sind hier leider nicht installiert.
Die gezeigte Möglichkeit ist möglich, aber nicht wirklich ein Sicherheitsgewinn. Wenn ich dies so richtig sehe, hängen dann beide Netze an einem WAN (Internet?). Also sind beide Netze vergleichbar angreifbar. Ja, man könnte jetzt Haare spalten und argumentieren, dass ja ggf. nur ein Netz gehackt würde, aber: 1. Wer garantiert dir, dass nur das "weniger kritische Netz" gehackt würde? 2. Wenn alle Dienste, ohne Trennung durch VM, eh auf dem gleichen System laufen, ist das völlig wumpe, ob das offiziell "weniger kritische Netz" gehackt würde. Der Angreifer hätte im Zweifel so oder so, dann den Zugang zum ganzen System. Ja, auch VM sind nicht absolut sicher (siehe Meltdown usw.), aber wären dennoch ein Sicherheitsgewinn, da ein Ausbruch aus einer VM viel mehr Aufwand erfordert. Dann bliebe noch das Problem, dass beide Netze identisch am gleichen WAN hängen. Das kann man so eigentlich nur mit VLANs und Firewalls so trennen, dass der ganze Aufwand ein echter Sicherheitsgewinn ist. Plumper Vergleich: Du versuchst deine Luxuskarre im Ghetto dadurch zu schützen, dass du zwei verschiedene Schlösser in die Türen baust.
Michi schrieb: > Aber: Wenn jemand aus Netz A Zugriff auf den Server erlangt (gewollt > oder ungewollt), dann kann er von dort aus in Netz B springen. > Über diesen Weg könnte man sich z.B. auch SSH Tunnel definieren, die > dann zu einen Host im Netz B führen. Sind schon über den router 2 verbunden. Wenn man die Wahl hat zwischen Gammel Firmware auf router und aus VM ausbrechen lautet die Antwort fast immer Router Firmware. Zum technischen: Ein Server mit mehren Interfaces zu betreiben ist nichts besonderes. Wenn es ordentliche Netzwerkkarten sind brauchst du nicht zwei dafür sondern kannst das alles über eine laufen lassen. Wenn Router 2 gut genug ist und deine Netzwerkkarte ebenfalls reicht dir sogar nur ein Kabel vom Router 2 zum Server.
Frank E. schrieb: > Genau genommen soll der Server für LAN1 als DB- und Fileserver dienen, > für LAN2 soll die RDP-Funktion zur Konfiguration und Wartung von Geräten > (z.B. per Browser/WebGUI oder SSH) dienen. Geht. Aber obacht: Linux folgt dem "weak host model", soll heissen ein Dienst auf deinem Server, der nur auf eines der Netze lauscht, ist dennoch auch aus dem anderen Netz erreichbar. Das kann aber mit iptables abgedichtet werden. LG, Sebastian
> Das setzt aber auch Switche voraus, die das unterstützen
Wie willst du etwas virtualisieren, wenn die Infrastruktur
dafuer fehlt. VLANs sind da ein zentrales Instrument.
VLAN-faehige Switche sind seit 2 Jahrzehnten handelsueblich.
Die Trennung auf 2 Netzwerkkarten kannst du dir da dann auch sparen.
Das selbe laesst sich einfacher mit Aliasen einrichten.
Mehr Sicherheit bieten 2 Netzwerkkarten dann naemlich auch nicht.
@Frank E. Deine Idee würde ich so auch vorschlagen. Nur den 2. Router würde ich rausnehmen. Für welchen Zweck hattest Du diesen gedacht? VLan sind hilfreich, um das Netzwerk zu segmentieren, um die Buchhaltung von der Entwicklungsetage datenschutzrechtlich zu trennen. Und wenn die Räumlichkeiten vieleicht eh schon sinnvoll getrennt sind, helfen Dir die 2 Netzsegmente ungemein. 2 Nic's am Server sind auch okay. Da kann man hier bereit den Traffic trennen. Wenn nur Doc's und mails geschoben werden würde ein Lan reichen, wenn aber 'richtiger' Traffic läuft, bedankt sich der Server, dass er die Arbeit auf 2 Lan's verteilen kann. Wenn es nur ein kleines Netzwerk ist, ist das vieleich 'overdrive'. Wenn da aber >50 Teilnehmer dran hängen, wäre es wieder sinnvoll mit 2 Segmenten zu arbeiten.
Warum ist "Router 2" mit beiden Netzen verbunden?
(prx) A. K. schrieb: > Schlaumaier schrieb: >> Üblich ist, das die Server immer die letzte Stelle der IP ne 0 ist. > Es gibt zwei Adressen im Subnetz, die man nicht für Geräte verwendet. Sage besser "nicht verwenden darf", einen Host mit x.x.x.0 /24 wird man im Netzwerk niemals erreichen können. Schlaumaier haben andere Netze, da geht das :-) > Die eine hat nur Einsen und steht für Broadcasts, Ist nett für Syslog im Heimnetz: Mein Router schickt UDP an 192.168.xxx.255 /24, damit kann jeder PC im Netz dessen Ausgaben empfangen. Frank E. schrieb: > Die IP 192.168.10.2 in der Grafik ist tatsächlich ein Tippfehler, muss > 192.168.2.2 heissen. Mir ist total unklar, was Dein "Router 2" soll. Im Prinzip würde der doch beide Netze verbinden, wenn man ihm das nicht per Regelwerk untersagt. Andererseits, wenn der eh beide Netze hat, kann er diese auch routen und der Server braucht kein zweites Netz. max schrieb: > Ein Server mit mehren Interfaces zu betreiben ist > nichts besonderes. Wenn es ordentliche Netzwerkkarten sind brauchst du > nicht zwei dafür sondern kannst das alles über eine laufen lassen. Die muß nicht 'ordentlich' sein, Windows kann jeder Netzwerkkarte mehrere IPs zuweisen. Egal, ob eine oder mehrere Netzwerkkarten, man muß vermutlich manuell Netzwerkrouten anlegen. Solange man im selben Netz bleibt, ist alles gut, will man aber raus (WAN), muß der Weg definiert werden. Ich habe einen PC betrieben, der über LAN und WLAN in zwei getrennte Netze greifen konnte, ein Hexenwerk war das nicht. Es ist aber dafür gut, dass der Admin rote Flecken im Gesicht bekommt, weil es seine sichere Trennung unterläuft.
Bedenke: Auch wenn Dein Server kein Routing zwischen den beiden Netzen vornimmt und die Clients ihn nicht als Gateway in das jeweils andere Netz verwenden können, hängt der Server jedoch in beiden Netzen. Jeder, der Zugriff auf den Server erlangt, gewollt oder ungewollt, könnte ihn verwenden um von dort in das jeweils andere Netz zu springen. Beispielsweise mit einem SSH Tunnel. Sollte Deine Netztrennung also sicherheitstechnische Gründe haben, dann würde ich empfehlen, mindestens mit zwei virtuellen Maschinen zu arbeiten und die Dienste getrennt bereit zu stellen. Wenn die Netze nur aus organisatorischen Gründen getrennt sind, dann kann man das schon so machen, wie Du es oben beschrieben hast. Sinnvollerweise mit zwei Netzwerkkarten - nicht mit zwei Adressen auf einem Interface. Bei DB- und Fileserver Anwendungen ist ja auch Durchsatz gefragt...
Die Skizze im ersten Beitrag halte ich für sehr suboptimal. So wie ich das lese, soll Windows benutzt werden, weil RDP genannt wurde? -> In dem Fall würde man auf den Server per RDP zugreifen, und von dort aus per SSH Geräte warten? - Das wäre keine wirkliche Sicherheit... Es ist mir jetzt zu mühsam, die ganzen Optionen durchzugehen, deshalb stelle ich mal Prinzip vor, wie ich es selbst praktiziere: Es gibt (natürlich) ein Admin-Netzwerk, weil ja irgendwer die Geräte warten muss. Und das zeichnet sich dadurch aus, dass auf dem Rechner, von dem aus gewartet wird, natürlich kein Youtube geschaut, Emails geöffnet, oder sonstiger Humbug veranstaltet wird, sondern dass er ein stets aktualiserter, sehr schlank gehaltener Linuxrechner ist. An jedem Gerät ist eine Schnittstelle mit dem Admin-Netz verbunden, und an allen anderen Schnittstellen ist die Konfiguration geblockt. Beim Server bedeutet das natürlich, dass z.B. der BMC im Admin-Netz ist. Bei Geräten ohne separate Konfigurationsschnittstelle ist der Zugriff über einen Router möglich. Was das nun praktisch für Deinen Use-Case bedeutet: 1. Server hernehmen (am besten mit BMC, aber nicht unbedingt nötig) 2. Erste Schnittstelle für das Hostsystem nehmen (am besten ein gut gewartetes Linux, mit dem üblicherweise Server laufen) - SSH-Port offen, rest zu. (BMC-Schnittstelle und 1. Schnittstelle ans Admin-Netz. 3. Auf dem Admin-Rechner virt-manager installieren 4. Auf den Server per SSH verbinden und den Libvirt-Dienst starten und in das Image-Pool-Verzeichnis von Libvirt das ISO für die VM laden. (wget + URL) 5. Auf dem Admin-Rechner in Virt-Manager eine VM zusammenklicken und das ISO installieren. Beim Netzwerk der VM macvtap über die zweite Netzwerkschnittstelle wählen. Somit läuft der Server über Schnittstelle 1, die VM über Schnittstelle 2. Hier kann man auch die virtuelle VM-Festplatte verschlüsseln und eventuell RAM-Verschlüsselung einschalten, wenn der Prozessor das unterstützt, damit beide Systeme übereinander machtlos sind (weiß aber nicht, wie das bei virt-Manager geht.) 6. In der VM SAMBA-Server aufsetzen und Datenbank installieren. (7. Weitere Netzwerkkarte kaufen und für jeden Dienst getrennte VMs nutzen) (8. Statt VMs Docker-Container nutzen - macht in dem Fall aber nicht so viel Sinn bei nur 2 Diensten) Das ganze lässt sich folgendermaßen warten: Vom Admin-Rechner auf Server per SSH und vom Server auf die VMs per SSH. In den VMs muss natürlich die Firewall entsprechend eingestellt werden (üblicherweise FirewallD)
Kleine Ergänzung: Die VM-Images können dann jeweils nach Betriebsschluss über VPN zu einem anderen Standort gebackuped werden. (VM anhalten und rsync auf virtuelle HDD)
Läuft bei mir genauso wie auf dem Bild absolut tadellos. Unter Debian - DHCP lauscht auf beiden Nics und vergibt dort die jeweiligen IPs. Die einzigste Route die du benötigst, wenn sie die zwei Netze sehen sollen, ist zwischen den beiden Netzen. PS.: natürlich ohne VM Gequarke.
Draconix schrieb: > Läuft bei mir genauso wie auf dem Bild absolut tadellos. Unter Natürlich läuft das - es lief bisher sehr viel, was ich in meinem Leben gesehen habe, insbesondere auch Quelltext. Allerdings - bei den meisten Dingen, die irgendwie liefen, sträubten sich mir bisher die Haare zu berge, weil vorprogrammiert war, dass sie irgendwann nicht mehr laufen. Bis vor 10 Jahren war das ja auch ausreichend. Gab nicht so viele Angreifer. Heutzutage, wo fast 90% der Firmen laut Bitcom im letzten Jahr Opfer eines Angriffs auf die IT wurden, ist es nicht mehr ausreichend, wenn der Wagen rollt. Er braucht Airbags, ABS, Gurte etc. Ich schätze, dass der File- und DB-Server in einem Netz mit Windows 10-Daus hängt, zusammen mit einigen IoT-Geräten, die schon zum Kaufdatum ungepatchte Sicherheitslücken aufwiesen und nie geupdated wurden - so ist es leider meistens. Weil das eine Netz nicht vertrauenswürdig ist, würde ich das Szenario nicht empfehlen. Dann kann jemand über den DB-Server oder den Fileserver einbrechen und hat direkt Zugriff auf die komplette Hardware und kann den jeweils anderen Dienst mit lahmlegen (z.B. verschlüsseln). Fügt man Dienste hinzu (z.B. interner Doku-Webserver), multipliziert sich dieses Risiko. Ich möchte nochmal in Erinnerung rufen, dass ein Fehler im SMB-Protokoll für die WannaCry-Angriffe verantwortlich war! Außerdem können Updates auch alle Dienste zerschießen, wenn alle auf der gleichen Betriebssysteminstanz laufen. Ein Backup und Zurückspielen der Dienste ist so auch mit größerem (Zeit-)Aufwand verbunden als wenn jeder Dienst eine eigene VM (oder einen Docker-Container) hat.
Manfred schrieb: > Sage besser "nicht verwenden darf", einen Host mit x.x.x.0 /24 wird man > im Netzwerk niemals erreichen können. Schlaumaier haben andere Netze, da > geht das :-) In 192.168.2.0/23 ist die 192.168.3.0 eine gültige Adresse.
Christian H. schrieb: >> Sage besser "nicht verwenden darf", einen Host mit x.x.x.0 /24 wird man >> im Netzwerk niemals erreichen können. Schlaumaier haben andere Netze, da >> geht das :-) > > In 192.168.2.0/23 ist die 192.168.3.0 eine gültige Adresse. Klugscheißer und Nichtleseversteher! In diesem Thread sind /24-Netze benannt und ich schrieb ebenfalls /24, da geht kein Host mit 192.168.xxx.0.
Wenn es um mehr als "Ein Server mit zwei Netzwerkkarten" geht, müssten man deutlich mehr über die Funktionen der beiden LANs wissen (und warum es zwei Router mit jeweils eigenem WAN-Anschluss gibt -- und über welche Route man aus dem 192.168.2.x ins Internet-WAN kommen soll; oder das WAN von Router 2 ist nicht das Internet). Ich glaube kaum, dass eines eine DMZ und das andere das interne Netzwerk darstellen soll.
Es ist inzwischen genau so realisiert, wie im Startpost angegeben und funktioniert einwandfrei. Auf dem Server läuft ein Datenbank-Server im Netz A, der im Verwaltungsbereich des Museums benötigt wird. Zusätzlich soll der Server als Wartungsrechner für elektronische Exponate im Ausstellungsbereich im Netz B benutzt werden. In diesem Falle schalte ich mich per VPN und RDP aus Netz A auf die Maschine und kann dann problemlos Geräte per Konsole oder VNC im Netz B erreichen. Das funktioniert so, ohne dass ich fast hundert Port-Forwardings in dem Router 2 zum Netz B enrichten müsste. Ausserdem ist der Server immer an, ganz im Gegensatz zu den Büro-PCs, von denen ich ansonsten immer einen per Anydesk/Teamviewer kapern muss und der eigentliche Nutzer dann nicht daran arbeiten kann. So wie es jetzt ist, ist es perfekt ...
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.