Einwahl-Client Ziel Router Genmask Flags Metric Ref Use Iface 192.168.0.12 0.0.0.0 255.255.255.255 UH 0 0 0 ippp2 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 ippp2 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 default 192.168.0.12 0.0.0.0 UG 0 0 0 ippp2
OK, das sieht IMHO nicht schlecht aus. Du brauchst auch das von mir gepostete 'route add ...' _nicht_, weil du eine Default-Route auf ippp2 hast und dein lokales Netz in einem anderen (Sub-)Netz liegt. Das Forwarding hast du auf dem Client "eingeschaltet"?
Nein, nur auf dem Einwahlserver. Das ist meiner Meinung nach auch nicht notwendig. Wenn ich einen ping auf einen Rechner im Netz des Einwahlservers mache (Bsp. 192.168.0.10), kommt die Anfrage zumindest beim Einwahlserver an. Das sagt zumindest eine Überwachung des IP-Verkehrs.
Einwahl-Server 192.168.0.240 * 255.255.255.255 UH 0 0 0 ippp0 192.168.0.0 192.168.0.11 255.255.255.0 U 0 0 0 eth0 192.168.0.10 * 255.255.255.0 UG 0 0 0 eth0 0.0.0.0 192.168.0.11 0.0.0.0 UG 0 0 0 eth0
Hier ist IMHO etwas faul...
So wie die Routing-Tabelle aussieht, hat ippp2 auf dem Client die IP 192.168.0.240 und ippp0 auf dem Server die IP 192.168.0.12. Stimmt das und ist das beabsichtigt?
Laut Konfigurationsdatei erhält ippp2 des Einwahlservers die IP 192.168.0.12 und der einwählende Client die IP 192.168.0.240
Wer ist 192.168.0.11? eth0 auf dem Server?
Ja
Diese zweite Route (192.168.0.0 192.168.0.11 ...) habe ich doch schon mal bei Martin Falley gesehen. Die ist IMHO sinnlos... Auch die dritte Route (192.168.0.10 * ...) ist IMHO faul -- eine Hostadresse mit einer 24-er Netzmaske. Mein 'route' hier (7.3) weigert sich zu recht, eine solche Route anzulegen. Und die Default-Route macht auch keinen Sinn, wenn 192.168.0.11 eth0 auf dem Server selbst ist.
werd ich dann mal löschen
Was für eine Version ist auf dem Server installiert? SuSE 8.0?
JA, mitlerweile glaube ich "leider"
Vielleicht ist dieses seltsame Routing ja ein high-sophisticated-Feature von 'iproute2'...
Allerdings sehe ich im Moment trotz dieser seltsamen Routing-Einträge kein grundsätzliches Problem, das das Routing zwischen Client und lokalem Netz hinter dem Server behindern sollte. Aber, ehrlich gesagt, kann ich das Routing bei einer solchen Tabelle nicht mehr nachvollziehen. Ich komm auch schon völlig durcheinander :-((
Aber erst einmal solltest du es wirklich mit "proxyarp" versuchen (siehe unten), vieleicht erledigt sich das Problem damit...
Unter Suse 8.0 kann (soll man) nicht in der Datei options.ipppx rumhantieren. Das läuft alles über die Datei cfg-net0. Wenn man dort PROXYARP einträgt bekommt man (oder besser ich) die Fehlermeldung: command not found. Vielleicht sollte ich doch wieder Suse 7.3 installieren. :-(( Gruß Norman
Stimmt, du musst die Netzgegebenheiten hinter dem Einwahlserver nur kennen, wenn du auf dem Client _keine_ Default-Route auf ipppX und _keine_ Netzwerk-Route(n) für 192.168.0.0/24 auf eth0 hast.
Blöde Frage: Auf der Client oder auf der Server Seite
Auf dem Client.
Probiere ruhig mal die "proxyarp"-Option des ipppd, das dürfte IMHO
Da werd ich wohl noch einiges lesen müssen
Später ;-) Einfach erst einmal auf dem Server in /etc/ppp/options.ippp0 "proxyarp" einfügen und wenn das nicht reicht, auch in /etc/ppp/options.ippp2 auf dem Client (jeweils besser ipppd hinterher neu starten).
Gruß
Andreas