Bisher ging es nur darum, Clients den Zugriff auf Dienste eines Servers innerhalb desselben Netzwerkes zu ermöglichen.
Was aber, wenn ein Client mit der IP-Adresse 192.168.1.79 aus der Domäne "Test" auf Server B mit der IP-Adresse 192.168.10.1 zugreifen will, der einem anderen Netzwerk angehört? Die Eingabe von "ping 192.168.10.1" schlägt fehl:
Dies bedeutet, dass Server A Anfragen an Server B nicht routet (weiterleitet).
Üblicherweise stattet man einen Rechner, der als Router dienen soll, mit einer zweiten Netzwerkkarte (= eth1) aus und weist ihr eine Adresse aus dem Adressbereich des Netzwerks zu, zu dem eine Verbindung hergestellt werden soll. Wenn man dies nicht via YaST erledigen will (siehe Basiskonfiguration), geht dies auch auf der Konsole.
Um Server A über Server B mit Server C zu verbinden wählt man z. B. diese Konfiguration:
Server A: | eth0: 192.168.1.1 eth1: 192.168.10.2 |
Server B: | eth0: 192.168.10.1 eth1: 192.168.100.2 |
Server C: | eth0: 192.168.100.1 |
Sie wird wie folgt realisiert:
Wenn beim Anpingen des Servers B vom Server A aus die Meldung erscheint: "connect: Network ist unreachable":
bedeutet dies, dass die Routing-Tabelle auf Server A keine Route für das Netzwerk 192.168.10.0 enthält.
Wenn auch die Eingabe von "route add -net 192.168.10.0 netmask 255.255.255.0 eth1" nicht zum Erfolg führt ("100% packet loss"):
dann finden die Antwortpakete den Weg zu Server A nicht. Dies zeigt die Eingabe von "tcpdump -i eth1" auf einer anderen Konsole; es wird deutlich, dass ein "echo request" herausgeht, aber keine Antwort erfolgt:
Wenn man auf Server B nun eingibt:
kommen Antwortpakete zurück:
Entsprechend zeigt "traceroute" den Weg zu Server C an:
Ob das Routing clientseitig funktioniert, lässt sich auf der Kommandozeile mit der Eingabe von "netstat -r" ermitteln; in der Ausgabe muss das korrekte Gateway eingetragen sein:
Wenn das Routing fehlschlägt, sollte man zuerst prüfen, ob die Netzwerkkarten des Servers richtig konfiguriert sind. Zu diesem Zweck gibt man auf der Konsole "ifconfig" ein. Die folgende Bildschirmausgabe auf Server A muss beide Netzwerkkarten mit den ihnen zugewiesen IP-Adressen zeigen:
Als Nächstes sollte man sich davon überzeugen, dass auf dem Server die Weiterleitung der Datenpakete richtig eingestellt ist. Zu diesem Zweck gibt man auf der Konsole "route -n" ein. Die Bildschirmausgabe muss für Server A wie folgt aussehen:
Wenn die zweite Zeile fehlt, kann weder Server A noch einer seiner Clients den Server B anpingen. Damit das gelingt, muss man auf der Konsole "route add -net 192.168.1.0 netmask 255.255.255.0 eth0" eingeben.
Auf Server B muss "route -n" folgende Ausgabe liefern:
Destination 192.168.10.0 192.168.100.0 192.168.1.0 |
Gateway 0.0.0.0 0.0.0.0 192.168.10.2 |
Genmask 255.255.255.0 255.255.255.0 255.255.255.0 |
... ... ... ... |
Iface eth0 eth1 eth0 |
Auf Server C muss "route -n" folgende Ausgabe liefern:
Destination 192.168.100.0 192.168.10.0 192.168.1.0 |
Gateway 0.0.0.0 192.168.100.2 192.168.100.2 |
Genmask 255.255.255.0 255.255.255.0 255.255.255.0 |
... ... ... ... |
Iface eth0 eth0 eth0 |
Wenn sich Server B zwar von Server A anpingen lässt, aber nicht von dessen Clients, ist eth1 von Server A in der Datei "dhcpd.conf" auf Server A vermutlich nicht als Router eingetragen; dies erkennt man daran, dass nach Eingabe von "ipconfig /all" in der Eingabeaufforderung des Clients als Standardgateway etwas anderes als "192.168.10.2" erscheint. In diesem Fall muss in der Datei "dhcpd.conf" auf Server A mit der Zeile "option routers 192.168.10.2" eth1 von Server A als Router eingetragen sein.
URI dieser Seite: <http://www.ewetel.net/~martin.bode/ag_computernetze/routing.htm>, zuletzt geändert: 2005-12-08