Routing Problem

[bkiepke]

Moin,

ich klappere seit Tagen Tutorials und Foren ab und finde keinen neuen Ansatzpunkt zur Lösung meines Routing-Problems.

Mein Netzwerk hat folgenden Aufbau:

Internet
|
DSL-Modem-Router
mit IP 192.168.0.1
|
+ 192.168.0.0/24
|
+--- DNS/DHCP-Debian5-Router mit 4 Schnittstellen
hostname : dns
eth0 : 192.168.0.254, 255.255.255.0
eth1 : 192.168.178.254, 255.255.255.0
eth2 : 192.168.179.254, 255.255.255.0
eth3 : 192.168.180.254, 255.255.255.0

In jedem der Subnetze gibt es mehrere Clients basierend auf Debian5 oder WinXP bzw. Win7. Alle Clients bekommen per DHCP eine IP passend zu Ihrem Subnetz und können grundsätzlich Namen in anderen Netzen auflösen - Was ja bedeutet, dass sowohl DHCP als auch DNS funktionieren.

Versuche ich von einem beliebigen Client eines der Subnetze 192.168.178.0 bzw. 192.168.179.0 bzw. 192.168.180.0 einen Client in einem anderen Subnetz zu erreichen oder einen Rechner im Internet so kommt grundsätzlich keine Verbindung zu stande.

Ich habe auf dem Host "dns" IP-Forwarding mittels

Code: Alles auswählen

echo "1" /proc/sys/net/ipv4/ip_forward

aktiviert, so dass ein

Code: Alles auswählen

cat /proc/sys/net/ipv4/ip_forward
1

zurückliefert.

Routingtabelle hat folgenden Inhalt

Code: Alles auswählen

route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.178.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.179.0   0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.180.0   0.0.0.0         255.255.255.0   U     0      0        0 eth3
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0

IP-Tables ist wie folgt konfiguriert

Code: Alles auswählen

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

wie die Ausgabe zeigt sollten grundsätzlich alle Pakete angenommen werden.

Es ist möglich von jedem Client aus ein beliebiges Interface des Hosts "dns" erfolgreich anzupingen.

Bei meiner Suche bin ich auf einen Benutzer gestossen der ein ähnliches Problem hatte und nach einem Upgrade des Kernels von 2.6.26 auf 2.6.29 sein Problem lösen konnte. Daraufhin habe ich den Kernel 2.6.32-5 aus dem "Squeese"-Zweig installiert, jedoch ohne Erfolg.

Jeder Client eines der Subnetze 192.168.178.0 bis 192.168.180.0 hat als Router den Host "dns" eingetragen. Ich habe zur Überprüfung mal ein paar "FORWARD"-Regeln zu iptables hinzugefügt, sodass Anfragen geloggt werden, was dann auch in den Logfiles aufgetaucht ist.

Hat jemand noch eine Idee was ich übersehen haben könnte, bzw. warum sich der Host "dns" vehement weigert Pakete weiterzuleiten?

[gucki]

Hallo bkiepke,

sieht soweit alles richtig aus. Du solltest jetzt auf den verschiedenen Rechnern mittels tcpdump prüfen, wo die Pakete "versanden".

Also z.B. von einem System im .178.x Netz einen ping auf ein System im .179.x Netz

Code: Alles auswählen

ping 192.168.179.xx

und z.B. auf dem dns

kommen die Pakete an?

Code: Alles auswählen

tcpdump -n -i eth1

werden die Pakete weitergeleitet?

Code: Alles auswählen

tcpdump -n -i eth2

und kommen die Antwortpakete zurück und wo versanden diese.

Gruß Gucki

[carsten2]

Moin,

DSL-Modem-Router
mit IP 192.168.0.1
|
+ 192.168.0.0/24
|

Mach da eine 16 draus oder richte auf dns Masquerading ein.

Carsten

[bkiepke]

@Carsten:

Im Netz 192.168.0.0/24 sind auch jede Menge Clients, eigentlich die Meisten in diesem Netzwerk, die anderen Netze habe ich eingerichtet um die "gewachsene Struktur" mit Ihren Problemen aufzudröseln.

Masquerading wäre sicher eine Möglichkeit, allerdings möchte ich soweit möglich die Dinge nicht komplizierte machen als nötig, zumal es Anwendungen gibt die dann entsprechend gemappt werden müssten.

@gucki:
das war ne tolle Idee, ich konnte jetzt zumindest festellen, dass Anfragen von den Subnetzen 192.168.178.0/24 bis 192.168.80.0/24 untereinander weitergeleitet werden. Sprich 2 Clients finden sich. Mir war die Windows Firewall der Clients im Weg. Was bedeutet, das IP-Routing mal grundsätzlich funktioniert.

Jetzt wird es etwas merkwürdig, weil ich mit Hilfe von tcpdump feststellen konnte, dass bei einem Ping von einem Client aus dem 192.168.179.0/24-Netz zu einem Client aus dem 192.168.0.0/24-Netz das "echo request" dort ankam und beantwortet wurde. Es wurde allerdings nicht vom host "dns" wieder an den Client aus dem 192.168.179.0/24 zugestellt.

Damit ist mir auch klar warum nicht: Der DSL-Modem-Router kennt natürlich die Netze 192.168.178.0/24 bis 192.168.180.0/24 nicht. Da aber alle Clients aus dem 192.168.0.0/24-Netz den DSL-Modem-Router als Router eingetragen haben, schicken diese die Antworten an den DSL-Modem-Router, der die Pakete dann vermutlich verwirft.

Vielen Dank für Eure Hilfe