Am Mittwoch, 24. Juli 2002 11:56 schrieb Alex Ascherl:

Hallo,

hört sich nach einem Problem mit ip-forwarding an...

Trage /etc/rc.config IP_FORWARD="yes" ein. Das ist es leider nicht. Die Einstellung habe ich vorgenommen. Ich vermute mal eher, dass ich in der Routing-Einstellung etwas ändern muss.

Gruß Norman Lyttek

Dann solllte es funktionieren. Einen Paketfilter (im Volksmund auch Firewall genannt) läuft aber nicht auf dem Server ?!

Gruß Alex Ascherl -SLSupport-

----- Original Message ----- From: "Norman Lyttek" To: "Suse Mailingliste" Sent: Wednesday, July 24, 2002 11:40 AM Subject: Probleme mit dem Dialin-Server

Ich habe mir hier einen Dialin-Server eingerichtet. IP der Netzwerkkarte: 192.168.0.xx IP von ippp0: 192.168.0.yy Die anderen Rechner gehören zum gleichen Subnetz. Problem: Über die Einwahl kann ich zwar den Dialin-Server erreichen, aber alle anderen Rechner im Netzt nicht. Was hab ich vergessen.

Gruß Norman

Am Mittwoch, 24. Juli 2002 13:10 schrieb Andreas Koenecke:

* Mittwoch, 24. Juli 2002 um 11:40 (+0200) schrieb Norman Lyttek:

...

Ich habe mir hier einen Dialin-Server eingerichtet. IP der Netzwerkkarte: 192.168.0.xx IP von ippp0: 192.168.0.yy Die anderen Rechner gehören zum gleichen Subnetz. Problem: Über die Einwahl kann ich zwar den Dialin-Server erreichen, aber alle anderen Rechner im Netzt nicht. Was hab ich vergessen.

Evtl. das Routing. Nach dem Verbindungsaufbau hast du auf dem Einwahl-Client lediglich eine Host-Route (Netmask 255.255.255.255) zum Einwahl-Server (PPP). Um die anderen Rechner "hinter" dem Einwahl-Server zu erreichen, musst die IMHO auf dem Einwahl-Client eine Netzwerkroute auf diese Rechner anlegen, z.B. 'route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.yy'.

Dachte ich am Anfang auch. Funktioniert aber nicht. Macht ja eigentlich auch dahingehend keinen Sinn, da ich ja bei der Client-Einrichtung nicht unbedingt die Netzgegebenheiten hinter dem Einwahl-Server kennen muss. Ich denke eher, dass ich die Route-Umgebung auf dem Einwahlserver ändern muss, bin aber echt überfragt, wie ich Einstellung vornehmen muss, damit die Pakete vom Server weitergereicht werden. Gruß Norman

Die "proxyarp"-Option des ipppd könnte in deinem Fall auch von Interesse sein. Aber den Teil der (i)pppd-Manpage verstehe ich nicht ganz und ich konnte auch nie mit dieser Option experimentieren.

Gruß

Andreas

Am Mittwoch, 24. Juli 2002 15:28 schrieb Andreas Koenecke:

* Mittwoch, 24. Juli 2002 um 14:17 (+0200) schrieb Norman Lyttek:

...

Am Mittwoch, 24. Juli 2002 13:10 schrieb Andreas Koenecke:

...

Evtl. das Routing. Nach dem Verbindungsaufbau hast du auf dem Einwahl-Client lediglich eine Host-Route (Netmask 255.255.255.255) zum Einwahl-Server (PPP). Um die anderen Rechner "hinter" dem Einwahl-Server zu erreichen, musst die IMHO auf dem Einwahl-Client eine Netzwerkroute auf diese Rechner anlegen, z.B. 'route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.0.yy'.

Dachte ich am Anfang auch. Funktioniert aber nicht.

Hm, was gibt denn 'route -n' auf Client und Server nach dem Verbindungsaufbau aus?

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 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

...

Macht ja eigentlich auch dahingehend keinen Sinn, da ich ja bei der Client-Einrichtung nicht unbedingt die Netzgegebenheiten hinter dem Einwahl-Server kennen muss.

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

...

Ich denke eher, dass ich die Route-Umgebung auf dem Einwahlserver ändern muss, bin aber echt überfragt, wie ich Einstellung vornehmen muss, damit die Pakete vom Server weitergereicht werden.

Probiere ruhig mal die "proxyarp"-Option des ipppd, das dürfte IMHO

Da werd ich wohl noch einiges lesen müssen

nicht schaden.

Gruß

Andreas

...

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

Am Mittwoch, 24. Juli 2002 23:40 schrieb Andreas Koenecke:

* Mittwoch, 24. Juli 2002 um 22:01 (+0200) schrieb Norman Lyttek:

...

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.

Gibt es dort vielleicht eine Zeile mit "IPPPD_OPTIONS=..."?

Die gibt es tatsächlich. Du meinst, wenn ich IPPD_OPTIONS="Proxyarp" eintrage, dann müsste es funktionieren

...

Vielleicht sollte ich doch wieder Suse 7.3 installieren. :-((

Ach, ich glaube so schlecht ist die 8.0 auch nicht. Ich habe eben mal in meinem Archiv zur suse-isdn-Liste herumgestöbert und folgendes in einem Thread mit ähnlichem Subject wie diesem gefunden:

Karsten Keil: "Update auf aktuelle version (z.B: via YOU). Dann findest Du eine kurzanleitung unter /usr/share/doc/pakages/i4l/README.dialin"

Danke für den Tip. Hatte ich aber auch schon gelesen. Steht eigentlich nur drin, wie man es anstellt, dass der Servert auf eingehende Anrufe reagiert.

(Mit aktueller Version ist das i4l-Paket aus den Suse-Updates für 8.0 gemeint.)

Vielleicht nützt es auch dir... ... und wenn nicht, nochmal in der suse-isdn-ML nachfragen.

Werd heute Nachmittag erst einmal die obige Einstellung mit proxyarp ausprobieren Gruß Norman

Gruß

Andreas