Netzsegmente überbrücken

[Nemesis]

hi,
ich habe hier zwei netzsegmente (194.173. und 192.168.), nun sollen sämtliche geräte nach und nach vom ersten ins zweite umziehen. damit die server aus beiden netzen immer erreichbar sind würde ich nun gerne ein brücke mit einem linux-rechner realisieren, der die ips der jeweiligen geräte auf der anderen seite übersetzt, so dass dann alle geräte in beiden subnetzen verfügbar sind.
dafür müsste dann jedes gerät praktisch über 2 ip-adressen ansprechbar sein, ohne dass der rechner davon weiss.
sprich, es muss in beiden subnetzen vorhanden sein und die linux-box soll das realiseren.
problem ist, ich habe keine idee, wie man soetwas realisieren könnte.
ich habe schon überlegt eine gigantische routingtabelle anzulegen, in deer ich die ips aus dem ersten netz einer ip aus dem zweiten zuweise, aber ich glaube das ist auch nicht die lösung.

wäre cool, wenn mir da jemand helfen könnte

thx!

 

[T-One]

http://www.karlrupp.net/de/computer/nat_tutorial
http://tldp.org/HOWTO/IP-Masquerade-HOWTO/

Darfst dir ne Möglichkeit aussuchen

 

[Nemesis]

hm, maskieren möchte ich ja eigentlich nichts, die kiste soll ja nur hin und her übersetzen, wenn ich bestimmte ips aufrufe, sprich den servern aus dem alten netz eine ip im neuen netz "zuweisen" unter denen ich diese erreichen kann.
so ala:
ip_altes_netz <-> ip_neues_netz
damit ein server im lten netz dort seinen standort behält, und ich vorerst nichts ändern muss, er aber im neuen netz unter der neuen ip zu erreichen ist. und das ohne dass ich am server etwas ändern muss.

ich hoffe ich habe das verständlich rüber gebracht.

thx!

 

[bitmuncher]

Sowas realisiert man normalerweise mit dem Programm 'ip' aus dem iproute-Paket (bei manchen Distros auch iproute2). Damit lassen sich sehr individuelle Routing-Lösungen zusammenbasteln.

 

[NoXqs]

Hat du einen funktionierenden DNS?
Welche OS sind im Einsatz?

Ich denke, du musst nur ein Router (zwichen den subnets) konfigurieren und die neue route auf allen beteiligten Geräten bekannt machen.

 

[saeckereier]

Vllt. habe ich bitmuncher falsch verstanden, aber Routing alleine wird da nicht reichen. Wenn das ganze für Client und Server transparent sein soll, dann wirst du um NAT (nicht Masquerading) nicht herumkommen, sprich dein Gateway ins Netz müsste die IP-Adressen entsprechend umsetzen. Bsp.:
Vorraussetzung: Server 192.168.0.1 ist noch nicht umgezogen, soll später unter 194.173.0.1 erreichbar sein

Client versucht Verbindung zu 192.168.0.1: Gateway/Router leitet normal weiter, keine Änderung erforderlich
Clietn versucht Verbindung zu 194.173.0.1: Gateway/Router verändert die Zieladresse des Paketes und schickt es an 192.168.0.1. (Analog für die Antwortpakete)

Wie würdest du das mit routing lösen bitmuncher? Habe ich da was übersehen oder falsch verstanden?

 

[NoXqs]

Die Frage ist doch erstmal, ob die Server und WKSTs gleichzeitig für beide IPs konfiguriert sein sollen oder ob es reicht, dass einige schon die neue nutzen, während andere noch die alte behalten.

 

[Nemesis]

naja, es soll eben so sein, dass man nach und nach die server und workstations vom alten ins neue segment packen kann und sie aber trotzdem immer aus beiden segmenten heraus erreichbar sind.

 

[NoXqs]

naja, es soll eben so sein, dass man nach und nach die server und workstations vom alten ins neue segment packen kann und sie aber trotzdem immer aus beiden segmenten heraus erreichbar sind.

Also reicht m.E ein einfacher Router.

Also,

Router mit 2 NICs mit jeweils einer IP im entsprechenden Subnetz.
Entsprechende Route ins jeweils andere Netz auf allen Hosts im Segment bekannt machen.
DNS oder entspr. Namensauflösung nach Umzug eines Hosts auf allen Hosts aktualisieren... fertig

 

[Nemesis]

Entsprechende Route ins jeweils andere Netz auf allen Hosts im Segment bekannt machen.
DNS oder entspr. Namensauflösung nach Umzug eines Hosts auf allen Hosts aktualisieren... fertig

und genau das will ich nicht haben ... ich möchte an keinem host/server etwas ändern, desswegen soll die linux-kiste zwischen die beiden netze, dass die das übernimmt, und wenn dann dass vlt. einträge der hosts, die umgezogen sind geändert/entfernt werden.

säckereier hat das richtig erfasst:

Server 192.168.0.1 ist noch nicht umgezogen, soll später unter 194.173.0.1 erreichbar sein

Client versucht Verbindung zu 192.168.0.1: Gateway/Router leitet normal weiter, keine Änderung erforderlich
Clietn versucht Verbindung zu 194.173.0.1: Gateway/Router verändert die Zieladresse des Paketes und schickt es an 192.168.0.1. (Analog für die Antwortpakete)

 

[NoXqs]

... ich möchte an keinem host/server etwas ändern, :

naja, zumindest die IP musst du auf der Kiste ändern.
Möchtest du verraten, warum du vor einer neuen Route auf allen hosts zurückschreckst?

Wir reden hier über einen Befehl eine statische route auf jedem Host einzurichten.
Diese route bleibt bis zum kompletten Umschwung aller Rechner immer gleich und kann danach wieder entfernt werden.


Einen NAT-Dienst aufzusetzen und während des Umzugs aktuell zu halten, halte ich für deutlich aufwändiger, besonders, da er nach dem Umzug völlig überflüssig sein wird.

 

[saeckereier]

Ich sehe das wie NoXqs, ich habe dir zwar den Weg beschrieben (ist in der netfilter Doku erläutert) aber persönlich würde ich den Weg nicht beschreiten wollen. Kannst du uns nicht etwas mehr zum Hintergrund erzählen und wie das mit der Erreichbarkeit aussehen soll und warum du nicht alle auf einmal umziehst? Evtl. hat da der eine oder andere noch einen guten Tipp..

 

[bitmuncher]

säckereier hat das richtig erfasst:

Server 192.168.0.1 ist noch nicht umgezogen, soll später unter 194.173.0.1 erreichbar sein

Client versucht Verbindung zu 192.168.0.1: Gateway/Router leitet normal weiter, keine Änderung erforderlich
Clietn versucht Verbindung zu 194.173.0.1: Gateway/Router verändert die Zieladresse des Paketes und schickt es an 192.168.0.1. (Analog für die Antwortpakete)

Genau das lässt sich problemlos mittels iproute lösen. Kannst ja einfach mal einen Blick in die Manpage von 'ip' werfen, wenn du es nicht glaubst. Du legst einfach eine zweite Routing-Tabelle mit der zweiten Route an und definierst eine Regel, dass diese RT genutzt werden soll, wenn Client XY auf IP XX verbinden will. Wird z.B. auch genutzt um mehrere DSL-Leitungen synchron zu nutzen u.ä.

 

[Nemesis]

also, der grund warum ich das nicht unbedingt auf jedem client/server sondern lieber zentral ändern möchte ist der, dass es sich um eine recht grosse anzahl an hosts handelt, und es sehr aufwendig wäre. dies ist auch der grund, warum nicht alles auf einmal umzieht, sondern nach und nach.
das was bitmuncher sagt hört sich ganz gut an (danke!) ich werde mir das auf jedenfall anschauen

wenns geklappt hat melde ich mich wieder, und wenn nicht sowieso

thx!

hm, und schon gehts los:

Du legst einfach eine zweite Routing-Tabelle mit der zweiten Route an und definierst eine Regel, dass diese RT genutzt werden soll, wenn Client XY auf IP XX verbinden will.

aber wenn client xy auf ip xx verbinden möchte, dann kann er das doch auch so machen, oder ?
ich muss der linux-kiste sagen, dass wenn jemand aus dem neuen netz auf server1 im alten netz zugreifen möchte, dass er diesen nicht unter seiner ip im alten netz erreicht, sondern, dass man ihn über eine ip im neuen netz ansprechen kann. wie wenn ich ihm 2 ip-adressen zuweise, was ich natürlich nicht mache, es sieht aber für die clients im neuen netz so aus als wäre er in ihrem subnetz.

da kommt man ja ganz durcheinander

 

[saeckereier]

ähh bitmuncher, wo willst du das in welcher Routingtabelle eintragen? Ich meine was von Routing zu verstehen und verstehe nicht wie das helfen soll. Wenn ein Rechner versucht einen anderen zu erreichen und dabei die IP des Pakets nicht stimmt hilft dir doch kein Routing der Welt?

 

[bitmuncher]

Hier geht es ja scheinbar darum quasi 2 Netze zu koppeln bzw. sie für den Client so abzubilden, dass sie ihm als ein Netzwerk erscheinen und das geht am Besten mit 2 getrennten Routing-Tabellen, in denen man für jeden Client eigene Routen einträgt.

Die eine Routing-Tabelle ist dann für's alte Netz zuständig, während die neue für's neue zuständig ist. Routing-Tabelle A (laut "Cisco-Standards", die ja auch iproute verwendet, die 253) bleibt also mit den alten Routen erhalten. Zusätzlich wird eine zweite Routing-Tabelle angelegt, die auf das neue Netzwerk verweist und bei der bestimmte IPs entsprechend umgebogen werden auf die neuen IPs. Man verwendet dort also einfach andere Routing-Regeln und einen eigenen Iptables-Regelsatz. Will man einen Client umschalten, legt man ihn einfach auf die neue Routing-Tabelle um.

Der Client muss also nicht wissen welche Route er nutzen soll, sondern verwendet einfach seinen Standard-Gateway, der dann den Rest regelt. Der Gateway muss aber nicht für jeden Client extra Routen festlegen, sondern nur die zu verwendende Routing-Tabelle.

So ist zumindest die typische Vorgehensweise, wenn ein größeres Netzwerk "umziehen" soll. Ich frag mich daher eher, warum hier alle was von Routen auf den Clients definieren, NAT u.ä. erzählen. Mit 1000 Clients wäre das 999 Mal zuviel Arbeit. Es mag für kleine Netze sinnvoll sein sowas auf die Schnelle via NAT umzubiegen, aber bei grossen Netzwerken sollte man dann schon etwas effektivere Wege suchen. Iptables wird auch nicht schneller, wenn es bei jedem Paket 1000 Regeln abarbeiten muss, die nichts anderes machen als für bestimmte IPs die Target-IPs umzulegen. Von der notwendigen Rechenleistung mal ganz abgesehen, die bei einem so umfangreichen Regelwerk und angenommenen 1000 Clients auch nicht gerade gering wäre.

 

[Nemesis]

Hier geht es ja scheinbar darum quasi 2 Netze zu koppeln bzw. sie für den Client so abzubilden, dass sie ihm als ein Netzwerk erscheinen

genau darum gehts

nur blöd, dass wir routing noch nicht durchgenommen haben
kennst du da ein gutes howto ?

 

[saeckereier]

@bitmuncher: Verzeih bitte meine evtl. dummen Nachfragen, aber ich kenne mich eben nur soweit damit aus, wie ich das zu Hause in meinem Netzwerk kennengelernt habe und durchs Studium eben die Grundlagen von IP Netzen. Wo würden diese Tabellen angelegt? Auf dem Gateway, dass in/aus diesen Netzen führt? Legt das Routing nicht nur fest wohin das Paket geschickt wird? Wenn ich jetzt ein Paket habe in dem eine Zieladresse 194.173.x.x steht und der Rechner aber die IP 192.168.x.x hat, dann ist es doch egal wie ich es route, der entsprechende Server wird das Paket doch ihnehin nicht annehmen? Das scheitert doch schon daran, dass der letzte Router auf dem Weg keine Antwort auf sein ARP bekommt...
Vielleicht übersehe ich ja auch was, aber ich würd's gerne verstehen.

 

[bitmuncher]

@saeckereier: Stelle es dir einfach vor wie mehrere Router in einem. Natürlich ist Voraussetzung, dass der empfangende Rechner auch die IP hat, die der Router "kennt". Beim Standard-Routing wird immer die Routing-Tabelle 'default' verwendet. Er leitet also als Vermittler Paket von Rechner A zu Rechner B. Zusätzlich kann man aber weitere Routing-Tabellen definieren (/etc/iproute2/rt_tables) und z.B. dann eine Route setzen, die besagt "Leite Pakete von Rechner A über Rechner C zu Rechner D, wenn dieser nach Rechner B fragt.", wobei Rechner C dann das NAT übernimmt. Natürlich ist zusätzlich ein NAT notwendig, aber es sind eben nicht tausend NAT-Regeln für jeden einzelnen Client notwendig, sondern lediglich eine für die Routing-Tabelle, womit die Abarbeitung des Regelsatzes natürlich wesentlich schneller und ressourcensparender funktioniert. Man erspart sich aber dadurch auch das Legen von statischen Routen auf dem Client.

@Nemesis: Such im WWW nach 'iproute' oder Cisco-Firewall-Grundlagen.

 

[saeckereier]

Aber wie sähe denn dann das NAT auf C aus? Das braucht doch trotzdem für jeden Rechner einen Eintrag?