Marcus Glöder, Mittwoch, 14. April 2004 21:58:
Hallo Matthias,
bei den von Dir vorgeschlagenen statischen Routen habe ich ein bestimmtes Verständnisproblem. das kann aber daran liegen, dass ich die Vorgehensweise und die Syntax bei der Festlegung statischer Routen auf Cisco-Routern gelernt habe, und deshalb mit der Vorgehensweise und der Syntax bei Unix- bzw. Linux-Systemen nicht vertraut bin. Im Falle des Cisco-IOS sieht eine statische Route so aus:
ip route [Ziel] [Maske] [next-hop-Router | intf] [Dist] permanent
Dabei ist: ----------
[Ziel] Zielnetzwerk oder Zielhost
[Maske] Subnetzmaske des Zielnetzwerkes
[next-hop-Router | intf] [next-hop-Router] ist die IP-Adresse des Routers, der der nächste auf dem Weg zum Zielnetzwerk ist, aus der Sicht des Gerätes, auf dem die statische Route definiert ist (also: die IP-Adresse der "mir" zugewandten Schnittstelle des nächsten Routers auf dem Weg zum Zielnetzwerk). [ietf] ist dasjenige Interface des Gerätes, auf dem die statische Route definiert ist, aus dem der Verkehr zum Zielnetzwerk herausgejagt werden muss (z.B. eth0, serial0 oder dialer1). Die beiden Angaben sind alternativ zueinander: sie dürfen nicht beide gleichzeitig angegeben werden, aber eine davon muss gemacht werden.
--> Die bis hierhin aufgezählten Angaben müssen auf jeden Fall gemacht werden. Die folgenden beiden sind dagegen optional:
[Dist] Administrative Distanz. Statische Routen haben normalerweise eine administrative Distanz von 1 (EIGRP: 90, IGRP: 100, OSPF: 110, RIP: 120, direkt angeschlossene Netzwerke: 0). Mit dieser Option kann dieser Wert verändert und die Route damit "teurer" gemacht werden.
permanent Dieses Schlüsselwort bewirkt, dass eine Route auch dann aufrechterhalten wird, wenn das Interface, durch das der Verkehr geleitet werden soll, ausfällt oder abgeschaltet wird.
Wichtig ist nun, dass das Gerät, auf dem die statische Route definiert wird immer nur das nächste routende Gerät (den next-hop-Router) "sehen" kann. Der Blick auf all jene Router, die eventuell noch hinter dem next-hop-Router auf dem Weg zum Zielnetzwerk existieren, ist gewissermaßen verstellt. Das Gerät, auf dem die statische Route definiert ist, braucht diese ganzen anderen Router auch gar nicht zu kennen, da der next-hop-Router ja die Aufgabe hat, die Pakete zum übernächsten Router ins richtige Netzwerk zu routen.
Ich nehme jetzt mal Dein Bild, das ist schön:
Ich hab's immer gern bildlich:
[INTERNET] -------, [WLAN-DSL-Rt] [192.168.2.1] ..... .............. funk funk
[192.168.2.2] [192.168.2.3] [ PC-Router ]--, [ LAPTOP ] [192.168.1.1] \ / \ / `---[Drucker] [192.168.1.2] [ PC1 ]
(Bei Einstellung einer Schrift mit fester Zeichenbreite im E-Mail-Programm ist auch alles am richtigen Platz.)
Davon gehe ich immer aus *g*.
Für den PC1, der meinem Verständnis nach eigentlich gar kein routendes Gerät ist (oder sein sollte), schlägst Du die folgenden Routen vor:
~# route add -net 192.168.2.0 gw 192.168.1.1 dev eth0 ~# route add -net 0.0.0.0 gw 192.168.2.1 dev eth0
Wenn ich das richtig verstehe, besagt die erste Route, dass der PC1 Pakete die für das Netzwerk 192.168.2.0 /24 bestimmt sind, über sein eigenes Interface eth0 zum next-hop-Router 192.168.1.1 (aus Sicht von PC1) schicken muss. Soweit, so klar.
Die zweite Route soll dann wohl sagen, dass der PC1 Pakete, die für irgendwelche anderen Netzwerke bestimmt sind (0.0.0.0), ebenfalls aus der Schnittstelle eth0 rausgejagt werden sollen, aber jetzt zum Wireless-LAN-Router (192.168.2.1) als Zielgerät. Aber der PC1 sieht den Wireless-LAN-Router überhaupt nicht. Er hat nämlich den PC-Router direkt vor seiner Nase. Um Verkehr zum Wireless-LAN-Router leiten zu können, müsste der PC1 wissen, dass die Pakete zunächst beim PC-Router (192.168.1.1, auch Sicht von PC1) abgeliefert werden müssen. Jeglicher Verkehr, der den PC1 verlässt, muss also so oder so immer zuerst durch das Interface eth0 zum next-hop-Router 192.168.1.1 (aus der Sicht von PC1) geschickt werden. Alles weitere entscheidet dann der PC-Router. Das alles ist ganz einfach deshalb so, weil der PC1 ein Endgerät ist und deshalb gar nicht mehr als eine Schnittstelle zur großen weiten Welt hat. Wenn ich also nicht ganz daneben liege, dürfte für den PC1 auch die schlichte Definition eines Standard-Gateways ausreichen:
route add -net 0.0.0.0 gw 192.168.1.1 dev eth0
Im Prinzip ja. Das sollte reichen. Ich hab hier zuerst daran gedacht, dass ja der WLAN-Router ggf. erreichbar sein muss (für Konfiguration vom PC1 aus). Und dann kann man über diesen Gateway-Eintrag auch gleich die Defaultroute schicken. Ist ein wenig umständlich, geb ich zu. Man könnte aber so einfach durch löschen der Default-Route den Zugang zum Internet blocken, ohne gleich den WLAN-Router (und auch das Laptop) unerreichbar zu haben ;-) Außerdem spare ich mir so die Default-Route im PC-Router, denn der braucht keinen eigenen Zugang zum Internet (IMHO).
- oder einach über YaST -> Netzwerk/Basis -> Konfiguration der Netzwerkkarte das Standard-Gateway (hier: 192.168.1.1) einstellen.
Für den PC-Router schlägst Du vor:
~# route add -net 192.168.2.0 netmask 255.255.255.0 dev wlan0 ~# route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
Das ist eigentlich klar, was die beiden Routen als solche betrifft. Eine Frage zur Syntax wäre, ob die Angabe der Subnetzmaske des Zielnetzwerkes unbedingt gemacht werden muss, oder ob das optional ist (bei den Routen für PC1 hattest Du sie ja weggelassen).
Ja, könnte sie wahrscheinlich.
Allerdings sind das die beiden direkt mit dem Router verbundenen Netzwerke. Die sollte ein Router auch ohne statische Route und sogar ohne Routing-Protokoll erkennen können. Daher sind beide Routen meiner Meinung nach nicht falsch aber schlicht überflüssig.
Kann sein, das SuSE die automatisch setzt.
Was jedoch fehlt, ist eine Route, die sagt, wohin Pakete für nicht direkt angeschlossene Netzwerke (in unserem Fall also alles, was fürs Internet bestimmt ist) hingeroutet werden sollen. Auch hier wäre ein Standard-Gateway hilfreich (sonst wird alles gedroppt, was nicht die Netzwerke 192.168.1.0 /24 oder 192.168.2.0 /24 zum Ziel hat):
route add -net 0.0.0.0 gw 192.168.2.1 dev wlan0
Bei mir nicht (s.o.)
wäre also ebenso notwendig wie ausreichend.
Für den Wireless-LAN-Router schreibst Du:
Allerdings muss der WLAN-Router auch PC1 erreichen können, dafür muss er für das Subnetz 192.168.1.0 das Gateway 192.168.2.2 (den PC-Router) eingetragen bekommen (ich hoffe, das geht).
Selbstverständlich. Nach der von Dir benutzten Syntax müsste das dann so aussehen:
route add -net 192.168.1.0 gw 192.168.2.2 dev wlan0
(sofern die Wireless-LAN-Schnittstelle des Wireless-LAN-Routers so heißt). Solange ausschließlich statisches Routing betrieben wird ist das auch eine notwendige Angabe, da es sich um ein entferntes Netzwerk handelt ("entfernt" insofern, als es nicht direkt mit dem Wireless-LAN-Router verbunden ist). Allerdings hielte ich es hier für einfacher zur "Entdeckung" von Routen zu solchen entfernten Netzwerken ein Routing-Protokoll (z.B. RIP) einzusetzen. Da aber solche Routing-Protokolle wie RIP nicht im Internet arbeiten können (ich spreche jetzt nicht von BGP), muss auf dem Wireless-LAN-Router auf jeden Fall noch eine statische Route für alle Zielnetzwerke außer 192.168.1.0 /24 und 192.168.2.0 /24 gesetzt werden. Ohne Routing-Protokoll also:
route add -net 192.168.1.0 gw 192.168.2.2 dev wlan0 route add -net 0.0.0.0 gw [IP des ISP-POP] dev ppp0
Die zweite scheint ja logischer Weise per Default drin zu sein.
Mit Routing-Protokoll ist nur die zweite Route nötig.
So der WLAN-Router das unterstützt. Ich kenne das Teil nicht.
Was nun den Laptop angeht, denke ich dass hier, wie beim PC1 (und aus denselben Gründen), ein schlichtes setzen des Standard-Gateways ausreichen müsste:
route add -net 0.0.0.0 gw 192.168.2.1 dev wlan0
Ja, das ist ja offensichtlich der Fall, denn dort funxt es ja. Aber Danke für die ausführlichen Erklärungen (nicht nur für mich). -- Gruß MaxX 8-) Hinweis 1: PMs an diese Adresse werden automatisch vernichtet. Hinweis 2: Bitte unbedingt beachten: http://www.suse-etikette.de.vu