linux-l: Umstellung von Klasse B auf Klasse C Netz mit Zwischenlösung

Steffen Dettmer steffen at dett.de
So Jul 1 20:26:34 CEST 2001


* Peter Becker wrote on Mon, Jun 25, 2001 at 11:58 +0200:
> > .1.1 ist so ne schöne IP - zum DHCP Verheizen viel zu schade :)
> 
> Stimmt schon. aber im B-Netzwerk ist 1.1 auch nur eine IP, wie jede
> andere... ;-)

Nein, es ist die, die man sich am besten merken kann ;)

> > na iiihh... Nee, mach das lieber nicht...
> 
> Wieso nicht?
> Habe gehört, daß es kein Problem gibt, wenn man B und C netz
> zusammen über ein Netzwerk laufen lässt. Die sollen sich
> eigenltich nicht in's Gehege kommen.

Bloß blöd, wenn Dein C Netz in genau diesem B Netz liegt oder so.
Ist doch hier gar nicht nötig, oder? Na, egal.

> Will ich ja machen. Der Linux-Server soll alle Anfragen von
> schon umgestellten Rechnern im B-Netz zum alten C-Netz
> maskieren und wieder in's Netzwerk schmeißen. 
> Genauso umgekehrt. Von den alten C-Netzwerk Workstations sollen
> Anfragen an das neue B-Netz ebenfalls maskiert und wieder in's
> Netz geschmissen werden...

Na ja, solche Dinge muß man sich mindestens aufmalen, um nix zu
übersehen, dazu hab ich jetzt aber keine Lust :) Normalerweise
braucht man in diesem Fall jedoch sowas überhaupt nicht. Die
Server haben dann eben einfach alle zwei IPs, ne alte und ne
neue, und die alte wird dann irgendwann weggeschmissen.

> Und dem Gateway und Proxy-Server kann ich ja jeweils 2 IPs geben.
> Gateway: eth0: 192.0.0.1/24
> Gateway: eth0:0: 192.168.0.1/16
> Proxy: eth0: 192.0.0.2/24
> Proxy: eth0:0: 192.168.0.2/16

Ja, sowas fände ich auch besser. 

> > > Der Linux-Server, der den DHCP macht bekommt für die Zeit eine 2.
> > > Netzwerkkarte.
> >
> > Zweite IP reicht, wird in dem Fall eh nicht schneller (es sei
> > denn, Du hast ein gut geswitchtes Netzwerk)
> 
> Will ich meinen. Wir haben da einen Glasfaser-Backbone

Na ja, wenn der Performance-Gewinn in dieser Umstellungsphase
wichtig ist, dann eben so.

> > Sicher das? Geht spätenstens bei internem FTP usw. schief. Und ob
> > Windoofs mit sowas klarkommt?
> 
> Mmmh... Der FTP-Server ist ja die Linux-Kiste mit den zwei Netzwerkkarten.
> Darauf will ich ja nun auch den DHCP und Masq-Router einrichten.
> so sollte es eigentlich gehen.

Ach so, Dein Gateway ist auch FTP server? Glück gehabt, wie :) 

> > Netzwerke sind geduldig :)
> 
> *g* Was soll denn das heíßen?

Na: Gehen tut immer viel (außer, wenn Win im Spiel).

> > Du hast ein Problem, und zwar Windoofs. Win nimmt man natürlich
 [...] 
> 
> Na was habe ich für ein Glück...
> Der DNS-Server vom gesammten Netzwerk liegt zufällig auch auf
> genau diesem Linux-Server. Damit ist das Prob doch gelöst, oder?

Nein. Windows verwendet immer erstmal Broadcasts. Wenn jemand im
Netz browsen will, reicht DNS nicht aus, da braucht man
mindestens sowas wie WINS. 

> Oder muß ich dann dort jeden Rechner einzeln in die /etc/hosts
> eintragen?

Das nützt ja nu gar nix. Unix nimmt schon ordentlich DNS und
alles geht. Nur eben Windows nicht. Dann kannst Du Deine
Maschinen zwar anpingen, aber keine Laufwerke davon holen und
solchen Mist. Kann echt ärgerlich werden, Fehlermeldungen sucht
man sowieso vergeblich usw. Macht dann keinen Spaß mehr.

> Äh.. wie, was, wo... äh... wofür ist denn ein WINS-Server?

Um Windows-Namen (erstmal: der ganze Windows-Mist ist so gesehen
eigenlich nicht route-bar) über broadcast domains hinaus zu
verteilen. Weil das Windows-Konzept so krank ist, braucht man
sowas eben. Siehe Samba Doku.

> Das sich die Win-Rechner untereinander sehen und auch Freigaben
> austauschen können ist eigentlich schon wichtig.

Eben. Dann stellt man in der Praxis oft fest, das X ein Laufwerk
von Maschnine X verwendet, was jeder vergessen hatte, und
plötzlich dann doch wichtig ist usw. Ach, das ist alles nervig
ohne Ende. Ach so, natürlich geht es denn _machnmal_ zum Kompott
auch noch (meistens natürlich dann, wenn man vor Ort ist). Ach,
nee, zu Win frag lieber jemand anders...

> Ich kenne nur keine Lösung zu dem Problem... *lol*
> Aber das ist halt Windoofs... Kann man nix machen...

Na ja, die Leute, die es draufhaben, und wirklich mal die ganze
Samba-Doku gelesen haben, die kriegen es ja hin. Ist ja nicht so,
daß es unmöglich ist, ist nur eben umständlich, unlogisch (2x
IMHO) und ganz anders als bei Unix.

> > Wäre ich in Win Netzen äußert vorsichtig... Vielleicht geht's
> > aber auch, wer weiß...
> 
> Inwiefern soll ich da vorsichtig sein?
> Wenn ich das nicht mache (NAT), dann haben die Rechner ja gar
> keine Möglichkeit, 

Doch, normales Routeing über den default-Gateway eben. Kann mir
nicht vorstellen, daß man den ganzen Win-Kram durchs Masquerading
kriegt, weiß ich aber nicht genau.

> > > Wäre ECHT SPITZE, wenn ihr mir die ipchains-Befehle nennen könntet,
> womit
> > > ich das hinkriege.
> > ipchains -A forward -s $source -d $dest -i $dev -j MASQ
> > $dev ist dabei das "ausgehende" (!).
> > also für:
> > > eth0: 192.0.0.105 /24
> > > eth1: 192.168.0.105 /16
> > > Damit soll er Masquerading verrichten.
> > > Alles aus Adressbereich 192.168.0.x oder 192.168.1.x ankommt
> > > soll von eth1 nach eth0 geleitet und maskiert werden.
> >
> > ipchains -A forward -s 192.0.0.105 -d 192.168.0.0/16 -i eth1 -j MASQ
> > und:
> > ipchains -A forward -d 192.0.0.105 -s 192.168.0.0/16 -i eth0 -j MASQ
> 
> VIELEN Dank...
> Dann müsste doch der komplette Austausch so aussehen, oder?
> 
> ipchains -A forward -s 192.0.0.105 -d 192.168.0.0/16 -i eth1 -j MASQ
> ipchains -A forward -d 192.0.0.105 -s 192.168.0.0/16 -i eth0 -j MASQ

> ipchains -A forward -s 192.168.0.105 -d 192.0.0.0/24 -i eth0 -j MASQ
> ipchains -A forward -d 192.168.0.105 -s 192.0.0.0/24 -i eth1 -j MASQ

Wieso jetzt wieder drei Netze? Ach, ist mir zu verwirrend, sorry.

> Dann müsste doch jede Anfrage von 192.0.0.x zu 192.168.x x als
> 192.168.0.105 

"als x.x.x.x maskieren" gibt's nicht. Du kannst nur genau auf
die eigenen IP des Routers maskieren.

> Oder habe ich da jetzt was falsch verstanden?

Vermutlich. Schau mal ins Firewall-HOWTO und NET-*-HOWTO.

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.



Mehr Informationen über die Mailingliste linux-l