IP Adressbereiche aufteilen

[0815]

Hallo zusammen.

Hab da, hoffendlich nur ein kleines, Problem mit unserem Netzwerk und dessen Konfiguration.
In meiner Firma existieren im Büro ca. 20 CAD Arbeitsplätze die mit mehreren Servern, alles Debian, verbunden sind.
Diese sind, die Server ausgenommen, von einem DHCP-Server mit IPs im Bereich 128.100.0.x versorgt.
Die Server haben feste IPs. Zusätzlich gibt es 2 DSL und einen LTE Router, diese haben 128.100.0.1-3.
Kurzum, im Büro läuft alles im Bereich 128.100.0.0

Im Nebengebäude gibt es nun zusätzlich einen Bereich mit mehreren PC den ich mit einer WLAN-Brücke einbinde.
Dies sind zwei Accesspoint die im Bridge-Modus laufen. Funktioniert prima im Bereich 128.100.0.0
Auch der DHCP-Server verwaltet diesen Bereich prima.
Nun möchte ich diesen Bereich aber gerne ins Netz 128.100.1.0 legen damit er vom Büro getrennt ist.
Ein Server aus dem Bereich 128.100.0.0 soll nun zusätzlich auf den Bereich 128.100.1.0 reagieren und
ich brauche eine Routing zu den Routern 128.100.0.1-3.
Also mehr als das Internet und dieser eine Server soll für den Bereich nicht erreichbar sein.

Irgendwie finde ich nicht die richtige Antwort darauf. Vielleicht liegt es auch daran, dass ich nicht weis
wonach ich suchen muß. Beschäftige mich nun schon sehr lange mit Linux und Netzwerken. Aber immer
nur so viel wie man im privaten Bereich gebrauchen kann. Auch in der Firma hat es bislang immer gereicht.

Es besteht auch die Möglichkeit die WLAN Bridge an eine separate Netzwerkkarte in diesen einen Server anzuschließen.
Dieser Netzwerkkarte könnte ich ja die IP 128.100.1.x geben. Dann fehlt mir immer noch das Routing zu den Routern.

Oder doch lieber gleich IPfire mit mehreren Netzwerkkarten?

Gruß
Helmut

[Cae]

Vorneweg, du bis nicht zufaellig an der "University of Toronto"? Falls nein: Du verwendest da oeffentliche Adressen, deren Server du aus deinem Subnetz nicht erreichst. Verwende eins der dafuer vorgesehenen privaten Netze wie 10.0.0.0/8.

Also, dein Netz sieht so aus?

Code: Alles auswählen

   +----------------------(         )
   |    +-----------------(Internetz)
   |    |    +~~~~~~~~~~~~(         )
   |    |    |
   |.1  |.2  |.3    R
   |    |    |      |
 ,----------------. v                            ,----------------.
 [ 128.100.0.0/24 ]---[ AP ]~~~Bridge~~~[ AP ]---[ 128.100.0.0/24 ]
 |                |                              |                |
 |   20 Clients   |                              |    n Clients   |
 |    n Server    |                              |                |
 | Hauptgebaeude  |                              | Nebengebaeude  |
 `----------------'                              `----------------'

Die Standardgateways von den ganzen Maschinen stehen momentan auf einem oder verschiedenen Plastikrouter(n)?

Ich wuerde an der Position R einen Router dazwischen stellen, der von dem Client-Netz Anfragen entweder auf einen der drei Uplinks verteilt oder an den "extra" Server weiterleiten. Alternativ koennte man das auch mit den Plastikroutern machen, die kennen auch alle das passende Netz. Allerdings hast du dann keine harte Trennung zwischen den Netzen; jeder Client kann mit dem anderen Gebaeude reden, z.B. ueber Broadcasts oder indem er sich einfach eine IP aus dem "ortsfremden" Netz gibt. Das bekommt man nur mit einer Firewall auf R in den Griff.

Gruss Cae

[0815]

Hallo Cae.

Die Grafik gibt schon sehr gut her wie ich mir das vorstelle.
War auch meine Befürchtung, dass ich da mit "Hausmitteln" nicht weiter komme.

Kurz einmal zur Erklärung:
Der IP Bereich 128.100.x.x. beruht auf eines unserer CAD Systeme die auf UNIX aufgebaut waren und
derren Datenbank nur in diesem Bereich funktioniert. War so mal vom Hersteller vorgesehen.
Trennen müssen wir die Bereiche weil es zwei GmbHs sind.
Aus Datenschutzgründen dürfen diese Bereiche nicht miteinander Verbunden sein.
Das DSL ist hier aber unter aller Sau und über LTE sind wir Volumenbegrenzt.
Daher wollen wir die Daten über einen, eigens dafür geschaffenen, Server austauschen
was man sonst über das Internet per FTP macht.

Überlegung:
Wenn ich dem Nebengebäude das Netz 192.168.0.0 gebe und den AP direkt an diesen Server anschließe und
dieser 2 Netzwerkarten hat, von denen die eine im Netz 192.168.0.0 und die andere 128.100.0.0 liegt,
sollte es dann nicht auch funktionieren?
Das Gateway von diesem Server kann ich dann doch auf 128.100.0.1 legen.
Wie sieht es aber mit dem Internet aus?
Was braucht dieser Server um diese Anfragen aus 192.168.0.0 an 128.100.0.1 zu schicken?
Freigaben auf diesem Server wären ja aus beiden Netzen erreichbar.

Gruß
Helmut

PS: Die IPs werden per DHCP vergeben und setzen das Gateway auf die .2
Die .1 hat eine externe feste IP für unsere Kunden.
Die .3 (LTE) nutzen wir für unsere Up- und Downloads sowie Konferenzen.
Auf dem Maschinen ist ein Proxy zu Squid eingerichtet.
Dieser ist so eingerichtet, dass er versucht die Router 1-3 gleichmäßig auszulasten.
Konferenzen und VOIP haben aber immer Priorität.

[Cae]

Mein Router R von oben kann prinzipiell auch ein ganz normaler Server mit zwei NICs sein, dem steht nix im Wege (auch wenn mir persoenlich aus Sicherheitsgruenden separate Hardware mit moeglichst wenig Zusatzsoftware lieber waere).

Was braucht dieser Server um diese Anfragen aus 192.168.0.0 an 128.100.0.1 zu schicken?

Nur seine Standardroute und aktiviertes Routing [1]. Das Problem wird eher sein, dass die Plastikrouter nicht wissen, wohin die Antwort gehen soll ("Rueckroute"). Da gibt es zwei Moeglichkeiten, entweder man sperrt das 192.168/24er Netz in ein NAT, dann sehen alle Anfragen so aus, als kaemen sie vom vom "Server mit zwei NICs". Oder man macht's besser und traegt die Rueckrouten haendisch auf den Plastikroutern ein; allerdings sind die manchmal kuenstlich beschnitten und lassen keine statischen Routen zu. Dann kann man nur NATten oder sie austauschen.

Gruss Cae

[1]

Code: Alles auswählen

# echo 1 >/proc/sys/net/ipv4/ip_forward

zum Testen, fuer dauerhafte Eintragungen aber besser

Code: Alles auswählen

# echo net.ipv4.ip_forward=1 >/etc/sysctl.d/ip_forward.conf
# sysctl -p /etc/sysctl.d/ip_forward.conf

[wanne]

allerdings sind die manchmal kuenstlich beschnitten und lassen keine statischen Routen zu.

Allerdings nicht zu früh verzweifeln. Meistens ist die Option nur gut versteckt.