Hallo Liste einerzeits hatte mein Server 192.168.1.1 / 255.255.255.0 plus ISDN Karte. In der rc.config hatte ich eingestellt: IP_DYNIP yes IP_FORWARD yes FW_DEV_WORLD ippp0 FW_DEV_INT etho Ferner hatte ich in /etc/ppp/ip-up unter ippp+) [...] ip-up) /sbin/route add default gw ... ipchains -F forward ipchains -A forward -i ippp0 -s 192.168.1.0/24 -j MASQ [...] eingetragen. Die route.conf auf den Clients war: 192.168.1.0 255.255.255.0 etho default 192.168.1.1 So, dies zum damaligen Server mit eth0 und ISDN Karte. Das funktionierte einwandfrei. Jetzt hat es sich dahingehend geändert, das aus dem Server die ISDN-Karte entfernt wurde. Statt dessen habe ich eine ISDN-Anlage mit integrierter ISDN-Karte an den Rechner an ttyS0 angeschlossen und den Internetzugang über t-online konfiguriert. Dies klappt. Auch pings auf z. B. www.test.de Weiterhin fungiert der Server als DHCD-Server. auch dies, funktioniert. In der rc.config habe ich lediglich den Wert FW_DEV_WORLD ippp0 in FW_DEC_WORLD ppp0 geändert. Die route.conf auf den Clients ist geblieben. Auf dem Server lautet sie wie folgt: 192.168.1.0 0.0.0.0 255.255.255.0 eth0 Ich weiss einfach nicht, wie und welche Einträge in /etc/ppp/ip-up gemacht werden müssen, so dass das Routing wieder klappt. Ein route -n ergibt bei besthender Verbindung zum Internet: Dest. GW Genmask Flags Metric Ref USE Iface 212.185.254.233 0.0.0.0 255.255.255.255 UH 0 0 0 0 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 212.185.254.233 0.0.0.0 UG 0 0 0 ppp0 Ein route -n ohne Internetverbindung: Dest. GW Genmask Flags Metric Ref USE Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Vielleicht ist es doch möglich, mir einen entscheidenden Hinweis zu geben. Ich komme nämlich einfach nicht weiter. Insbesondere zu machende Einstellungen in /etc/ppp/ip-up sind mir nicht klar. Vielen Dank im voraus und Grüsse Martin Pitsch --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, Martin Pitsch wrote:
IP_DYNIP yes IP_FORWARD yes FW_DEV_WORLD ippp0 FW_DEV_INT etho ^^^^
Ist das nur ein Tippfehler in der Mail, dass hier "etho" anstatt "eth0" steht?
/sbin/route add default gw ... ipchains -F forward ipchains -A forward -i ippp0 -s 192.168.1.0/24 -j MASQ [...]
eingetragen.
[1] - siehe weiter untern...
Die route.conf auf den Clients war:
192.168.1.0 255.255.255.0 etho default 192.168.1.1
Auch hier steht wieder "etho" anstatt "eth0"...
In der rc.config habe ich lediglich den Wert
FW_DEV_WORLD ippp0
in
FW_DEC_WORLD ppp0
geändert.
Wenn Du schon eine selbstgestrickte Masquerading-/Firewall-Rule [1] verwendest, sollte natuerlich auch dort das "ippp0" in "ppp0" geaendert werden...
Die route.conf auf den Clients ist geblieben.
Korrekt.
Auf dem Server lautet sie wie folgt:
192.168.1.0 0.0.0.0 255.255.255.0 eth0
Passt auch.
Ich weiss einfach nicht, wie und welche Einträge in /etc/ppp/ip-up gemacht werden müssen, so dass das Routing wieder klappt.
Ich denke, das Problem ist, dass das Masquerading nicht funktioniert, weil die "ipchains"-Rule auf "ippp0" zeigt, das Device aber nun "ppp0" heisst. Gruss Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Moser wrote:
Hallo,
Martin Pitsch wrote:
IP_DYNIP yes IP_FORWARD yes FW_DEV_WORLD ippp0 FW_DEV_INT etho ^^^^
Ist das nur ein Tippfehler in der Mail, dass hier "etho" anstatt "eth0" steht?
Hallo Steffen, das ist ein Tippfehler, sollte eth0 heißen. Ich bin aber schon weitergekommen. Der Server fungiert nun als DHCP incl. BIND8 im Netz 192.168.1.0/24. Benutzt habe ich das Script von SuSE aus der Datenbank "Firewall und Masquerading auf SuSE 6.4" fürs routing. Ich bin entsprechend den Angaben für "reines Masquerading ohne Filterung" vorgegangen (Punkt 1. im Scrip). Danach hat das Routing zu allen Clients geklappt. Anschließend habe ich noch "dial-on-demand" mittels entsprechendem Script eingerichtet. Auch dies klappt. Sobald von den Clients eine Anfrage, welche außerhalb des LAN's liegt, an den Router angetragen wird, wählt dieser sich ein und routed weiter. Auswählen nach voreingestellter idle-Time funtzt ebenfalls. Ich bin mir aber noch nicht sicher, ob diese vorgenannte Konfiguration einen ausreichenden Schutz für mein Netz darstellt. Grüsse Martin -- Martin Pitsch Registrierter Linux User # 173833 Tel.: 0231 / 71 09 - 58 2 02362 / 96 59 01 Fax : 089 / 14 88 21 15 81 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
m.pitsch@gmx.de
-
moser@egu.schule.ulm.de