PC "vergisst" seine Routing /Gatewayeiträge bei An

[Cobra-x]

Hallo erstmal.
hier mein "heißes" Problem:

PC1 hängt zwischen PC2 und Router - und soll PC2 an den Router weiterreichen ...
laut meinen indos sind alle einträge ok - dennoch scheint er bei anfragen von PC2 alles zu vergessen ......

Schemadarstellung des ganzen :

PC2 <---> eth0 PC1 eth1 <---> PC2

Die Config :

cpu1:~ # ifconfig
eth0      Protokoll:Ethernet  Hardware Adresse 00:80:AD:46:E2:8C
          inet Adresse:192.168.2.20  Bcast:192.168.2.31  Maske:255.255.255.240
eth1      Protokoll:Ethernet  Hardware Adresse 00:13:8F:23:7D:91
          inet Adresse:192.168.2.10  Bcast:192.168.2.15  Maske:255.255.255.240

cpu1:~ # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.1     192.168.2.10    255.255.255.240 UGH   0      0        0 eth1
192.168.2.0     0.0.0.0         255.255.255.240 U     0      0        0 eth1
192.168.2.16    0.0.0.0         255.255.255.240 U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1

cpu1:~ # cat /etc/sysconfig/network/routes
192.168.2.1 192.168.2.10 255.255.255.240 eth-id-00:13:8f:23:7d:91
192.168.2.21 192.168.2.20 255.255.255.240 eth-id-00:80:ad:46:e2:8c
default 192.168.2.1 - -
cpu1:~ # cat /proc/sys/net/ipv4/ip_forward
1
cpu1:~ #

Ping von PC2 an PC1/eth0 geht ebenso an PC1/eth1
aber bei pings an den Router bekommt PC1 Amnesie ...

(auszug aus Log an eth0 via Etheral )

No.     Time        Source                Destination           Protocol Info
      2 0.999630    192.168.2.21          Broadcast             ARP      Who has 192.168.2.1?  Tell 192.168.2.21
Frame 2 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 192.168.2.21 (00:20:18:52:c9:69), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

Gateway ist eingestellt - das netz ist sauber "getrennt" und auch ipforwarding läuft - woran kanns liegen ??


( ps : arp -i eth1 -s 192.168.2.21 00:13:8F:23:7D:91 pub half auch nicht )

Am Router kann ich dazu nichts einstellen - der nimmt nur sein hauptnetz (192.168.2.x) - und via bridge wirds eher noch komplizierter - die Firewall im router ist käse - vor allem da im internen Teil VNC / NFS / CUPS laufen (sollen)

FireWall/NAT/Cache-DNS soll PC1 managen.

Weiß jemand nen Rat , wo der Fehler sitzt / sitzen kann ?? - hab nun in den vergangenen 2 Wochen so viel rumprobiert, das ganze lauffähig zu machen - ev spuckt da auch noch ne fehlerhafte Einstellung in die Suppe - aber ich sehs nich mehr

Besten Dank schon mal im voraus.

 

[Yehudi]

Wenn ich das jetzt beim rüberfliegen richtig gesehen habe, dann liegt der Fehler an den beiden Ethernetkarten mit der Subnetznummer. Bei Dir steht an beiden an dritter Stelle die 2, wenn Du jetzt bei einer Ethernetkarte die 2 gegen eine 3 austauscht, dann sind die beiden Netze von einander getrennt.
Und bei 255.255.255.240 würde ich die 240 gegen eine 0 austauschen.

 

[Cobra-x]

Hallo Yehudi

Mit dem 3er Netz habe ich schon "gespielt" (letzte Woche - hier die Ergebnisse

1. ich schiebe nur PC1/eth0 auf 192.168.3.20 und setze die Gateway für 192.168.2.21 darauf
a) Netzmaske PC1/eth0 auf 0 - Rest unverändert :
-> PC1 ist für PC2 komplett unerreichbar - weder eth0 noch eth 1 anpingbar - vom externen router red ich gar nicht erst
-> PC1 kann mit IP von PC2 nix anfangen -> Anfrage geht nach eth1 trotz routing auf eth0

b) Netzmasken von Pc1/eth0 /eth1 auf 0 ; Routing unverändert
-> Ergebnis wie unter a)

c) Netmasken Routing auf 0 ändern:
-> Ergebnis wie unter a)

2. PC2 bekommt auch 192.168.3 + ein routing das netz 192.168.2.x über eth0 erreichbar ist
-> Routing nicht mehr möglich (Kompaktrouter will nur "sein" Netz - also 192.168.2, solange er die IP 192.168.2.1 innehat) - da bliebe nur masquerading übrig.
(PS: auch da bekommt PC2 keine verbindung zu PC1 : (Network unreachable)) - da ich bei masquerading gar keinen durchblick habe - und ich ja auch erstmal versuchen will, das routing läuft, hab ich da das Problem nicht weiter untersucht

 

[Yehudi]

Ups, das ist natürlich blöd. Eine andere Vermutung wäre, dass das Routing nicht funktioniert, weil da noch der Router hinterhängt. Bei mir übernimmt der Linuxrechner nämlich auch die Routingfunktion, und die Einwahl. Ich gehe halt direkt mit einem DSL-Modem ins Netz.
Ansonsten muss ich passen.

 

[Cobra-x]

Jo - wenn man da bei google sucht bekommt man 100.000 Treffer die ein "einfaches" Routing behandeln (wo auf dem router ppp0 läuft) - aber inzwischen hab ich mich genug mit dem Problem befasst, um zu vermuten, das man auch zb 5 Linuxkisten in Reihe zum durchrouten bringen könnte - nur ist da die Information im WWW extrem spärlich :evil:

Weil dem Linux-Rechner ist es ja im Grunde genommen egal, ob er direkt die Internetluft schnuppert oder nicht (oder ich seh den Birkenwald vor lauter Bäumen nich mehr) - weil ein Routing von eth0 auf ppp0, das auf eth1 läuft ist fast gleich wie ein routing von eth0 auf eth1 - nur das das ppp0 protokoll wegfällt (und damit etwas Gefummel an der FW)

Unter Windows geht das ja meines Wissens auch (reihenrouting) - nur das da das system die ganze "fummelei" übernimmt - und Linux ist ja gerade was Netzwerk anget, um einiges besser.

Gruß Marco

 

[jengelh]

cpu1:~ # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.1     192.168.2.10    255.255.255.240 UGH   0      0        0 eth1
192.168.2.0     0.0.0.0         255.255.255.240 U     0      0        0 eth1
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1

Das kann auch nicht hinhauen. Sagen wir, du willst ein Paket an 134.76.13.21 schicken. Weil keine Route direkt passt, wird die letzte genommen (Default), also steht im IPV4-Header als Ziel 134.76.13.21 und das Paket geht an die Ethernetaddresse des Rechners 192.168.2.1. Fertig.
Die erste Regel dort wird gar nicht beachtet, da das *IPV4-Ziel* nicht 192.168.2.1 ist, sondern 134.76.13.21.

 

[Cobra-x]

cpu1:~ # route -n
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.1     192.168.2.10    255.255.255.240 UGH   0      0        0 eth1
192.168.2.0     0.0.0.0         255.255.255.240 U     0      0        0 eth1
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth1

Das kann auch nicht hinhauen. Sagen wir, du willst ein Paket an 134.76.13.21 schicken. Weil keine Route direkt passt, wird die letzte genommen (Default), also steht im IPV4-Header als Ziel 134.76.13.21 und das Paket geht an die Ethernetaddresse des Rechners 192.168.2.1. Fertig.
Die erste Regel dort wird gar nicht beachtet, da das *IPV4-Ziel* nicht 192.168.2.1 ist, sondern 134.76.13.21.

Hmmm - da fällt mir nur eines ein: Grundidee richtig, Durchführung fehlerhaft ...

Jeder Router macht folgendes bei einer "IP-Suche" zb 134.76.13.21 -
er geht die Routingtabelle durch, richtig - und findet dort den default ..... kann er was damit schon anangen ? Nein ! er weiß jetzt nur , das er die daten für die IP 134.76.13.21 an die IP des Defaulteintrags schicken muss, aber er weiß , das die IP des Defaulteintrags nicht übereinstimmt mit eth1 - also was macht er ?
er schaut ein zweites Mal in die Routingtabelle... und siehe da, der angeblich falsche Eintrag bekommt seine Existenzberechtigung ......


Gruß Marco



Im übrigen wurde der Fehler gefunden ( das log von Etheral auf PC1 / eth0 brachte mich auf die falsche Spur - nen bekannten auf die richtige : die Netzwerkmaske des PC" war noch auf 255.255.255.0 - nun ist sie auf 255.255.255.240 und der Rechner geht brav ins internet