Routing : Ich komme nicht weiter... zum 2.
Hallo ! Ich hatte bereits vor einer Woche hier gefragt , ob mir wer einen Tip geben könnte, was ich tun muß damit das Routing klappt... soweit ich die Infos in der SDB / Handbuch verstanden habe müßte alles laufen. Aber wenn der client pingt geht das nur lokal. z.b. Client ping pop.gmx.de ping: unknown host. ( also sofortiger abbruch ) Client ping 194.221.183.20 ( ist nur die ip vom pop.gmx.de ) 100% loss Client ping router ... 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 1.060/1.123/1.351 ms also kanns am ethernet nicht liegen *g* Anmerkung : bei route -n kommt das selbe Ergebnis wie bei rcroute status Infos Client : *----* route -n *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.12 0.0.0.0 UG 0 0 0 eth0 *--------* *----* route.conf *----* 192.168.0.0 0.0.0.0 255.255.255.0 eth0:0 default 192.168.0.12 *--------* *----* ifconfig *----* eth0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C EtherTalk Phase 2 addr:65280/241 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22724 errors:0 dropped:0 overruns:0 frame:0 TX packets:20743 errors:0 dropped:0 overruns:0 carrier:0 collisions:1 eth0:0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth0:1 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 EtherTalk Phase 2 addr:0/0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:382 errors:0 dropped:0 overruns:0 frame:0 TX packets:382 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 *--------* Und beim Router : *----* route -n *----* *----* offline *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Das Gateway setzt der Rechner irgendwo selbst - aber wo und weshalb ? - no plan - definiert ist da nix. *--------* *----* online *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.104.205.34 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 62.104.205.34 0.0.0.0 UG 0 0 0 ppp0 Anmerkung : ich habe verschiedene Provider - also würde eine route auf die ip von diesem nichts nutzen. *--------* *--------* *----* route.conf *----* 192.168.0.0 0.0.0.0 255.255.255.0 eth0 kein default ( wohin auch - da ppp ) *--------* *----* ifconfig ( online ) *----* eth0 Link encap:Ethernet HWaddr 00:20:18:52:C9:69 inet addr:192.168.0.12 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:566557 errors:0 dropped:0 overruns:0 frame:0 TX packets:1638617 errors:0 dropped:0 overruns:0 carrier:0 collisions:276 txqueuelen:100 Interrupt:10 Base address:0xff80 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:5205 errors:0 dropped:0 overruns:0 frame:0 TX packets:5205 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 ppp0 Link encap:Point-to-Point Protocol inet addr:213.7.88.222 P-t-P:62.104.205.34 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:1696 errors:16 dropped:0 overruns:0 frame:16 TX packets:1640 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 *--------* Wenn also Jemand ne Idee für 'nen Ansatzpunkt hat - nur zu ! Bin nach ca. 4 Wochen suche in manpages, datenbanken, diversen config-files usw rat- und planlos. - rein theoretisch müßte es laufen aus meiner sicht im moment. -- Nobody said computers were going to be polite. ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624
* Marco_Jaeger@gmx.de schrieb am 27.05.01 um 13:22 Uhr:
Hallo !
Ich hatte bereits vor einer Woche hier gefragt , ob mir wer einen Tip geben könnte, was ich tun muß damit das Routing klappt...
Ja, und? [ping klappt nicht]
Anmerkung : bei route -n kommt das selbe Ergebnis wie bei rcroute status
Infos Client :
*----* route -n *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 192.168.0.12 0.0.0.0 UG 0 0 0 eth0 *--------*
OK, aber lo kannst du hier rauslassen
*----* route.conf *----* 192.168.0.0 0.0.0.0 255.255.255.0 eth0:0 default 192.168.0.12 *--------*
*----* ifconfig *----* eth0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C EtherTalk Phase 2 addr:65280/241 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22724 errors:0 dropped:0 overruns:0 frame:0 TX packets:20743 errors:0 dropped:0 overruns:0 carrier:0 collisions:1
eth0:0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Warum arbeitest du nicht nur mit eth0 und eth0:0 ? Hättest du ein device gespart. Musst du ueberhaupt zwei IP's im selben subnet haben?
Und beim Router :
*----* route -n *----*
*----* offline *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo Das Gateway setzt der Rechner irgendwo selbst - aber wo und weshalb ? - no plan - definiert ist da nix. *--------*
*----* online *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.104.205.34 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 62.104.205.34 0.0.0.0 UG 0 0 0 ppp0 Anmerkung : ich habe verschiedene Provider - also würde eine route auf die ip von diesem nichts nutzen. *--------*
Bei ISDN funktioniert das mit einer Dummy Adresse. Da wird zum Beispiel das default gm auf 192.168.2.99 gesetzt, während das ippp0 if eine dummy-Adresse (z.B.) 192.168.2.1 bekommt Wenn ein Paket ueber 192.168.2.1 zum default gm 192.168.2.99 will, wird eine Verbindung aufgebaut. Ich weiss jetzt gar nicht: Hast du das ppp0 device *nur* wenn du pnline bist? Dann ist das natuerlich anders. Ist schon so lange her...
*----* route.conf *----* 192.168.0.0 0.0.0.0 255.255.255.0 eth0 kein default ( wohin auch - da ppp ) *--------*
ok [ifconfig auch ok] Mal nebenbei: Hast du denn ueberhaupt ip-forwarding und masquerading aktiviert? Gruss -Marc -- +-O . . . o . . . O . . . o . . . O . . . ___ . . . O . . . o .-+ | Ein neuer Service von Links2Linux.de: / o\ RPMs for SuSE | | --> PackMan! <-- naeheres unter | __| and others | | http://packman.links2linux.de/ . . . O \__\ . . . O . . . O . |
Am 27-May-01 schrieb Marc Schiffbauer :
* Marco_Jaeger@gmx.de schrieb am 27.05.01 um 13:22 Uhr: .... Ja, und?
[ping klappt nicht]
Wenn nichtmal ping durchkommt dann stimmt das routing noch ned *g* wie sollte dann z.b. ein prog wie mailer oder gar netscape dann ins web kommen ?? [... ]
*----* ifconfig *----* eth0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C EtherTalk Phase 2 addr:65280/241 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22724 errors:0 dropped:0 overruns:0 frame:0 TX packets:20743 errors:0 dropped:0 overruns:0 carrier:0 collisions:1
eth0:0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Warum arbeitest du nicht nur mit eth0 und eth0:0 ? Hättest du ein device gespart. Musst du ueberhaupt zwei IP's im selben subnet haben? intern hat der client 2 aufgaben - der einfaheit halber auch 2 namen *g* - und das geht nur über 2 feste IP's
ich arbeite nur mit eth0:0 und eth0:1 wie du erkennen kannst hat eth0 keine eigene IP.
*----* online *----* Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 62.104.205.34 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 192.168.0.0 192.168.0.12 255.255.255.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 0.0.0.0 62.104.205.34 0.0.0.0 UG 0 0 0 ppp0 Anmerkung : ich habe verschiedene Provider - also würde eine route auf die ip von diesem nichts nutzen. *--------*
Bei ISDN funktioniert das mit einer Dummy Adresse. Da wird zum Beispiel das default gm auf 192.168.2.99 gesetzt, während das ippp0 if eine dummy-Adresse (z.B.) 192.168.2.1 bekommt Wenn ein Paket ueber 192.168.2.1 zum default gm 192.168.2.99 will, wird eine Verbindung aufgebaut.
Ich weiss jetzt gar nicht: Hast du das ppp0 device *nur* wenn du pnline bist? Dann ist das natuerlich anders. Ist schon so lange her...
japp wenn ich offline bin, iss ppp0 auch weg. isdn kommt vielleicht bald *grübelz* - wär einfacher zum routen *g*
Mal nebenbei: Hast du denn ueberhaupt ip-forwarding und masquerading aktiviert?
*----* rc.config Router : *----* IP_FORWARD="yes" START_ROUTED="yes" START_RINETD="yes" START_FW="no" *----*Router : Kerneloptionen Netzwerk *----* <*> Packet socket [*] Kernel/User network link driver [*] Routing Nachrichten <*> Netlink device Emulation [ ] Firewall-Funktionalität [ ] Paket-Filter an Sockets <*> Unterstützung für Unix Domain Sockets [*] Unterstützung des TCP/IP-Protokolls [*] IP Multicasting [*] Weiterentwickelte Unterstützung für IP-Router [*] Regelbasierte IP-Routen [*] Mehrere gleichteure IP-Routen [*] TOS als IP-Routingschlüssel [*] Unterstützung ausführlicher IP-Routing-Anzeigen [*] IP: Große Routingtabellen [*] IP: Schnelle Netzwerkadressen-Umsetzung (NAT) [ ] IP: Autokonfiguration auf Kernelebene [*] IP: Optimierung für Router (nicht Host) <*> IP-Tunnel < > GRE Tunnel über IP [*] IP: Multicast-Routing [*] IP: Unterstützung für PIM-SM Version 1 [*] IP: Unterstützung für PIM-SM Version 2 [*] IP: Unterstützung von Aliasing [ ] Unterstützung des ARP-Dämon (EXPERIMENTELL) [*] Schutz vor "SYN flooding" < > Reverse ARP Server-Unterstützung [*] IP: Anlegen großer Buffer (nicht empfohlen für RAM < 16MB) <*> tty support for PPP over X <*> PPP (point-to-point) support *--------* Soweit ich "noch" durchblicke ist alles aktiv was fürs routing/masq benötigt wird - und auch richtig eingestellt -- Drew's Law of Highway Biology: The first bug to hit a clean windshield lands directly in front of your eyes. ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo, ich hab zwar nicht alles verfolgt aber event. ein paar Tips. Läuft denn jetzt Masquerading und IP-Forwarding? Für mich hört sich das genau so an als ob zumind. eines davon nicht laufen würde. Viele Infos sind in der SuSE-SDB. Einfach mal nach masq suchen. (Z.B. http://sdb.suse.de/sdb/de/html/sm_masq2.html ) So auf die Schnell einfach mal: echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0 auf dem Router eingeben wenn die Modemverbindung steht. Damit sollte jetzt ein ping mit IP's vom Client zum Internet gehen. (Auf dem Client muß als GW die IP des Routers angegeben werden.) MfG Klaus
* NKRDL schrieb am 27.05.01 um 18:41 Uhr:
Hallo,
ich hab zwar nicht alles verfolgt aber event. ein paar Tips. Läuft denn jetzt Masquerading und IP-Forwarding? Für mich hört sich das genau so an als ob zumind. eines davon nicht laufen würde.
Viele Infos sind in der SuSE-SDB. Einfach mal nach masq suchen. (Z.B. http://sdb.suse.de/sdb/de/html/sm_masq2.html )
So auf die Schnell einfach mal:
echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
genau! und das ist auch, was Marco nicht hat! Masquerading fehlt, bzw wurde nicht konfiguriert. Gruss -Marc -- +------------------------------------------------------------------+ | --> http://www.links2linux.de <-- Jetzt mit neuen Features! | | wie z.B. [EasyLink] | +---Registered-Linux-User-#136487------------http://counter.li.org +
Am 27-May-01 schrieb NKRDL :
Hallo,
ich hab zwar nicht alles verfolgt aber event. ein paar Tips. Läuft denn jetzt Masquerading und IP-Forwarding? Für mich hört sich das genau so an als ob zumind. eines davon nicht laufen würde.
jo aber warum ?
Viele Infos sind in der SuSE-SDB. Einfach mal nach masq suchen. (Z.B. http://sdb.suse.de/sdb/de/html/sm_masq2.html )
habe die db auch offline *g*
So auf die Schnell einfach mal:
echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0
forget it - ipchains will ned Rtr:> ipchains -A forward -i ppp0 -j MASQ ipchains : Protocol not aviabble RTR:> ipchains -L (liste) kommt ipchains: Incompatible with this Kernel ipchains V1.3.9 kernel 2.2.14 Das war der griff ins Klo, oder ? - das system iss komplett vom server gesaugt - und neu installiert nach HD-Crash - also kein update vor dem crash lief alles einwandfrei - auch routing - aber meines wissens ohne ipchains ( kann mich auch irren ) - iss ca. 11 mon. her, wo ich das eingestellt hab - auf dem gleichen system ( neuinstall )
Damit sollte jetzt ein ping mit IP's vom Client zum Internet gehen. (Auf dem Client muß als GW die IP des Routers angegeben werden.)
iss bereits eingetragen -- While it may be true that a watched pot never boils, the one you don't keep an eye on can make an awful mess of your stove. -- Edward Stevenson ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo, Masq. geht normalerweise bei 2.2.x er Kernel immer mit ipchains. Nur merkt man das nicht unbedingt, da man alles z.b. Im YaST bei "Konfigurationsdatei ändern" einstellen kann. Bei SuSE 7 landen die Variablen dann unter /etc/rc.config.d in der Datei firewall.rc.config . Die Start-Variable in /etc/rc.config . Einige recht brauchbare Beisp. sind in der Datei /usr/share/doc/packages/firewals/EXAMPLES . Gestartet wir dann automatisch über /sbin/init.d/firewall . .. bezieht sich alles auf SuSE 7 . Bei SuSe 6.2 ist es etwas anders. 6.3 und 6.4 kenne ich nicht. Denke aber es ist wie 7 . Welche SuSE ist das denn? Da hier ipchains aber nicht geht fehlt event. ein Modul oder im Kernel fehlt was. Zum Testen würde ich mal den Standard-Kernel/Module nehmen. Event. als zweite Konf. im lilo. Sind im VZ /lib/modules/2.2.14/ipv4 die *masq* Module vorhanden? Und dann nochmal mit dem "Kurztest" echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0 versuchen. Solange aber ipchains nicht geht funktioniert das nicht! (Ich hab auch ipchains 1.3.9, 17-Mar-1999, aber den Standard-Kernel 2.2.16) .. hab gerade noch gelesen, daß im Kernel "Firewall-Funktionalität" nicht eingeschaltet ist. Event. ist das das Problem mit dem ipchains. MfG Klaus
Hallo ! Na ja als nun hab ich den kenel überbacken *lol* - mit firewallfunktionalität - ipchains läuft - aber der rest ?? *----* Bash Router *----* ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): *--------* Na gut das läuft ... aber ... *----* router ping > inet *----*
ping pop.gmx.de PING pop.gmx.de (194.221.183.20): 56 data bytes --- pop.gmx.de ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss
ping 194.221.183.20 PING 194.221.183.20 (194.221.183.20): 56 data bytes --- 194.221.183.20 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss *--------*
*----* client ping > inet *----*
ping pop.gmx.de nach 1 Min Abbruch durch Strg+C - keine Ausgabe
ping 194.221.183.20 PING 194.221.183.20 (194.221.183.20): 56 data bytes --- 194.221.183.20 ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss *--------*
Router Netscape > http://www.suse.de geht Client Netscape > http://www.suse.de geht nicht ( wie vordem ) ( meiner meinung nach ein recht guter zusatztest ) Danke an NKRDL für den Tip mit dem Kernel - ich hätte an die Firewall funkionalität darin unter Garantie als letztes gedacht. dabei warten bestimmt noch weitere Probleme auf mich, wenn das Routing erstmal richtig läuft. aber irgendwie seltsam - trotz Fehler bei ping komme ich ins web - vom router aus. das Rätsel geht also weiter - habe übringes die 2.IP des Clienten sicherheitshalber eingefroren - device eth0:1 gelöscht ( reakivierung geht ja leicht ) und device eth0:0 zu eth0 geändert. ( während der Kernel auf dem Router röstete ) -- To be intoxicated is to feel sophisticated but not be able to say it. ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo,
ping 194.221.183.20 PING 194.221.183.20 (194.221.183.20): 56 data bytes --- 194.221.183.20 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss *--------*
Event. mal ping www.suse.de . Ein ping auf pop.gmx.de geht bei mir auch unter Win nicht.
*----* client ping > inet *----*
ping pop.gmx.de nach 1 Min Abbruch durch Strg+C - keine Ausgabe
.. ist mir schon klar da der Client ja keinen NS hat wird auch keine IP geliefert. Da würde der ping selbst dann nicht gehen wenn das Masq. funkt. würde. .. ah ja noch was. Vor dem "Kurztest" sollte die FW mit rcfirewall stop gestoppt werden damit es da keine Probleme gibt. Wenn's dann mal geht kann man immer noch die Variablen im YaST einstellen. MfG Klaus
Am 30-May-01 schrieb NKRDL :
Hallo,
Event. mal ping www.suse.de . Ein ping auf pop.gmx.de geht bei mir auch unter Win nicht.
na ja ohne kernel zum 5. mal backen gings - vom router *g* Router :
ping www.suse.de PING Turing.suse.de (213.95.15.200): 56 data bytes --- Turing.suse.de ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss
ping 213.95.15.200 PING 213.95.15.200 (194.95.15.200): 56 data bytes --- 194.95.15.200 ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss
also dasselbe wie mit gmx *g* ( alte mail ) dasselbe iss beim cient - ping name : geht garnix ping
.. ist mir schon klar da der Client ja keinen NS hat wird auch keine IP geliefert. Da würde der ping selbst dann nicht gehen wenn das Masq. funkt. würde.
*g* - ns wurde auch im clienten angegeben - den von meinem hauptprovider
.. ah ja noch was. Vor dem "Kurztest" sollte die FW mit rcfirewall stop
kurztest ?? - meintest wohl den zusatztest mit ns - aber egal ob fw läuft oder nicht - ns findet garnix - dasselbe gilt für ping
gestoppt werden damit es da keine Probleme gibt. Wenn's dann mal geht kann man immer noch die Variablen im YaST einstellen.
*bg* - ich glaub bis ich den fehler gefunden habe, woran es noch scheitert, hab ich vermutlich suse 20.6 installiert *bg* mit brummenden Schädel grüßt Marco -- "Saw a sign on a restaurant that said Breakfast, any time -- so I ordered French Toast in the Renaissance. -- Steven Wright ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo, da nicht mal ein ping geht würde ich das mit dem Kernel erst mal lassen, SuSE neu inst., nur das Modem einrichten und dann einwählen. Wenn das dann geht kann man immer noch einen eigenen Kernel erstellen, Netzkarte konf., .. . (Einfach mal vom Grundsystem anfangen und immer mehr zufügen .. bis es nicht mehr geht oder besser noch alles funkt.) Ist event. Win verfügbar? Dann mal mit Win ein ping auf www.suse.de event. wird ja der ping vom Provider aus gesperrt. Der NS scheint aber die IP aufzulösen und da im Netscape www.suse.de geht, schon komisch.
.. ah ja noch was. Vor dem "Kurztest" sollte die FW mit rcfirewall stop
kurztest ?? - meintest wohl den zusatztest mit ns - aber egal ob fw läuft oder nicht - ns findet garnix - dasselbe gilt für ping
mit Kurztest meine ich: echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0 Das geht eigentlich immer wenn man das System gerade inst. hat, die Netzwerkkarte und das Modem richtig eingestellt sind und auf dem Client die IP, GW und NS passen. Dann nur noch einwählen und schon ist der Client auch im Netz (normalerweise). MfG Klaus
Am 02-Jun-01 schrieb NKRDL :
Hallo,
da nicht mal ein ping geht würde ich das mit dem Kernel erst mal lassen, SuSE neu inst., nur das Modem einrichten und dann einwählen.
na ja - konnte mir besseres vorstellen, da dasselbe in ein paar tagen ? nochmal kommt ( hab ja 6.4 - und die 7.2 ist schon bestellt )
Wenn das dann geht kann man immer noch einen eigenen Kernel erstellen, Netzkarte konf., .. . (Einfach mal vom Grundsystem anfangen und immer mehr zufügen .. bis es nicht mehr geht oder besser noch alles funkt.)
soweit o.k. - ping vom router geht ( wieder ) - von client noch nicht - soweit wie sonst auch *grrrr* Die alten Config-Files habe ich für den istall beim Clienten hinterlegt - das einzig "alte" iss /home ( extra-pladde ) - aber die neu zu bauen wäre mir überflüssig vorgekommen - sind ja nur die Mails und persönliche einstellungen / daten von verschiedenen programmen - nix systemwichtiges *g* - höchstens persönlich wichtig
Ist event. Win verfügbar? Dann mal mit Win ein ping auf www.suse.de event. wird ja der ping vom Provider aus gesperrt. Der NS scheint aber die IP aufzulösen und da im Netscape www.suse.de geht, schon komisch.
ähhm Win ??? - öh das einzige was ich "noch" von alten Zeiten habe, wäre M$-Dos 5.00 und Win 3.0 *lach* - aber die install spar ich mir *g*
mit Kurztest meine ich: echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0
*----* Ausgabe Router *----* :> echo "1" > /proc/sys/net/ipv4/ip_forward :> echo "1" > /proc/sys/net/ipv4/ip_forward :> ipchains -A forward -j MASQ -i ppp0 :> ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): :> *-------* hmmm da iss ping aufschlußreicher *g* und der kurztest ist auf dem clienten genauso nichtssagend und in .../ip_forward ist auf dem router nix ( leeres file, 0 Byte Größe) egal ob firewall on oder off ist ( router ) nur wenn die fw down ist , meldet sie route to internet failed - obwohl ipchain wie oben aktiv ist *----* Router *----* :> rcfirewall status Checking the status of the Firewall: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT):
rcfirewall start Starting Firewall Initialization: The Firewall script needs to know the external (internet) interface! failed :> *-------*
hmhmh frei nach trappatoni : gehirn durch routing wie Flasche leer
Das geht eigentlich immer wenn man das System gerade inst. hat, die Netzwerkkarte und das Modem richtig eingestellt sind und auf dem Client die IP, GW und NS passen. Dann nur noch einwählen und schon ist der Client auch im Netz (normalerweise).
hmhmhm irgendwie kommt mir die aussage bekannt vor - soweit ich alles verstanden ( man, SDB, ... ) und auch notwendigerweise gemacht ( start_routed / IP_Forwarding, .... ) hab - sollte alles buttermäßig laufen langsam glaub ich ich bin zu dämlich :-( -- Every improvement in communication makes the bore more terrible. -- Frank Moore Colby ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo,
soweit o.k. - ping vom router geht ( wieder ) - von client noch nicht - soweit wie sonst auch *grrrr*
.. also ping vom Router aus geht jetzt. Schon mal gut.
mit Kurztest meine ich: echo "1" > /proc/sys/net/ipv4/ip_forward ipchains -A forward -j MASQ -i ppp0
*----* Ausgabe Router *----* :> echo "1" > /proc/sys/net/ipv4/ip_forward :> echo "1" > /proc/sys/net/ipv4/ip_forward :> ipchains -A forward -j MASQ -i ppp0 :> ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): :> *-------* hmmm da iss ping aufschlußreicher *g*
.. das passt doch Alles.
und der kurztest ist auf dem clienten genauso nichtssagend
.. nein nicht auf dem Client, nur auf dem Router. Der Kurztest ist ja nur ein schnell eingetippter Ersatz für die Konf. der Variablen der FW im YaST auf dem Router.
und in .../ip_forward ist auf dem router nix ( leeres file, 0 Byte Größe)
../ip_forward ist so eine Art Schalter um das Weiterleiten ein (1) oder aus (0) zu schalten. Status nachsehen mit cat /proc/sys/net/ipv4/ip_forward .
egal ob firewall on oder off ist ( router ) nur wenn die fw down ist , meldet sie route to internet failed - obwohl ipchain wie oben aktiv ist
.. wo kommt die Meldung "route to internet failed"?
*----* Router *----* :> rcfirewall status Checking the status of the Firewall: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT):
rcfirewall start Starting Firewall Initialization: The Firewall script needs to know the external (internet) interface! failed :>
.. da rcfirewall status bzw start keine Fehlermeldung bezüglich FW_START bzw. START_FW bringt nehme ich mal an, daß jetzt in der /etc/rc.config die Variable START_FW auf yes steht, richtig? Der Kurztest wurde nur einmal vor dem starten der Modemverbindung eingegeben? Die FW wurde noch nicht konf.? Dann haben wir das Problem. Wenn START_FW auf yes ist wird die Firewall bei jeder Einwahl gestartet. Da sie aber noch nicht konf. ist werden alle Regeln gelöscht. --->>> Der zuvor eingegebene Kurztest ist dann gelöscht. Lösung für den Kurztest: Den Kurztest jedesmal eingeben nach dem die Einwahl erfolgreich erfolgt ist. Jetzt kann man mit ipchains -L nachsehen ob die Regeln noch stimmen und mit einem cat /proc/sys/net/ipv4/ip_forward nachsehen ob die Weiterleitung noch aktiv ist. Kurz: Entweder den Kurztest um schnell mal zu sehen ob es grundsätzlich geht oder die Variablen der FW wie in (bei SuSE 7) /usr/share/doc/packages/firewals/EXAMPLES beschrieben einstellen. Nur eins von beiden. Den Kurztest nehme ich um mal zu sehen ob der Kernel, Netzwerkkonf. und Clients funktionieren bevor ich dann beginne die Variablen für die FW zu bestimmen. Dauerlösung mit FW (konf. nur für Masq.): (external fw interface=ppp0 , internal fw interface=eth0 , internal LAN: 192.168.0.0/24) Einfach die Variablen im YaST bei "Konfigurationsdatei ändern" eingeben. FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" Die FW mit dem Masq. wird dann bei jeder Einwahl automatisch gestartet. (START_FW und IP_FORWARD muß natürlich auch yes sein.) MfG Klaus
Am 02-Jun-01 schrieb NKRDL :
Hallo, [..]
egal ob firewall on oder off ist ( router ) nur wenn die fw down ist , meldet sie route to internet failed - obwohl ipchain wie oben aktiv ist
.. wo kommt die Meldung "route to internet failed"?
o.k. chronologie routingtest ( kurzform ) tty1,rtr:> wvdial tty3,rtr:> ipchains -L tty3,rtr:> ipchains -A ... tty3,rtr:> ipchains -L ( ausgabe auch unten ) tty3,rtr:> ping www.suse.de <<< klappt tty1,cln:> ping www.suse.de <<< klappt nicht tty1,cln:> ping 213.95.15.200 <<< klappt nicht tty7,cln:> X-Server netscape www.suse.de <<< klappt nicht tty3,rtr:> rcfirewall stop <<< done tty3,rtr:> kurztest tty3,rtr:> ipchains -A ... tty3,rtr:> ipchains -L tty3,rtr:> ping www.suse.de <<< klappt tty1,cln:> ping www.suse.de <<< klappt nicht tty1,cln:> ping 213.95.15.200 <<< klappt nicht tty7,cln:> X-Server netscape www.suse.de <<< klappt nicht tty3,rtr:> rcfirewall status <<< siehe ca. 10 zeil. tiefer tty3,rtr:> rcfirewall start <<< failed tty3,rtr:> ipchains -L <<< ist o.k. - 1 regel ( s.u. ) tty3,rtr:> rcfirewall start <<< failed ttyx = entsprechende konsole - auf tty2 ist startx unter user rtr = Router cln = client
*----* Router *----* :> rcfirewall status Checking the status of the Firewall: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT):
rcfirewall start Starting Firewall Initialization: The Firewall script needs to know the external (internet) interface! failed :>
.. da rcfirewall status bzw start keine Fehlermeldung bezüglich FW_START bzw. START_FW bringt nehme ich mal an, daß jetzt in der /etc/rc.config die Variable START_FW auf yes steht, richtig? nope auf no - nur ip-forwarding & routed auf yes
Der Kurztest wurde nur einmal vor dem starten der Modemverbindung eingegeben? 2x - nach dem dialin ( siehe oben )
Die FW wurde noch nicht konf.? nur mit der einen regel manuell ( ipchain -A forward -J MASQ -i ppp0 ) und das als config bezeichnen ?? na ja
Dauerlösung mit FW (konf. nur für Masq.): (external fw interface=ppp0 , internal fw interface=eth0 , internal LAN: 192.168.0.0/24)
Einfach die Variablen im YaST bei "Konfigurationsdatei ändern" eingeben. FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24"
Die FW mit dem Masq. wird dann bei jeder Einwahl automatisch gestartet. (START_FW und IP_FORWARD muß natürlich auch yes sein.)
hhmhmm die variablen gibts in der rc.config ( v6.4 ) ned ... yast » konfigdatei ändern » mit F4 ( suche "FW" ) wird nur !!! Start_FW gefunden - und auf yes gesetzt bringt START_FW auch nur failed ( boot ) - da nicht ! online ;-) - und auch ned fest configuriert. was mich aber bei fw status und auch ipchains -L etwas wundert ... Ports : n/a ?? obwohl nur ! ipchains -A forward -j MASQ -i ppp0 eingetragen wurde ? ( online ) Router Bash ( online ) : bash-2.03# rcfirewall status Checking the status of the Firewall: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): bash-2.03# ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): bash-2.03# oder iss das "normal" ???? -- Crime does not pay ... as well as politics. -- A. E. Newman ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
hi Marco, On Sun, Jun 03, 2001 at 02:56:30AM +0200, Marco_Jaeger@gmx.de wrote:
Am 02-Jun-01 schrieb NKRDL :
...
was mich aber bei fw status und auch ipchains -L etwas wundert ... Ports : n/a ?? obwohl nur !
ipchains -A forward -j MASQ -i ppp0
eingetragen wurde ? ( online )
Router Bash ( online ) :
bash-2.03# rcfirewall status Checking the status of the Firewall: Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): bash-2.03# ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ anywhere anywhere n/a Chain output (policy ACCEPT): bash-2.03#
oder iss das "normal" ????
Ports n/a bedeutet nur, daß diese Regel nicht auf einen oder mehrere Ports beschränkt ist. n/a bedeutet, diese Regel gilt für alle Ports! gruss Udo
Am 03-Jun-01 schrieb Udo Müller :
hi Marco, [Ausgabe FW/IPchains gel. ] Ports n/a bedeutet nur, daß diese Regel nicht auf einen oder mehrere Ports beschränkt ist. n/a bedeutet, diese Regel gilt für alle Ports!
gruss Udo
o.k. - nur wenn man mit bestem wissen alles richtig macht und dennoch an jeder ecke n fehler kommt, bzw nix so läuft wie es laufen sollte / müßte sieht man irgendwann an jeder Ecke Gespenster *lach* weil wo ich in dem system noch den "Fehler" suchen könnte - null plan Wie gesagt - rein theoretisch mußte alles sauber laufen - aber die Praxis sagt nein ... - zum schwarzärgern - und da bickt dann auch vor lauter negativtests und fehlersuche auch ein genie nix mehr ( vermutung ) - wobei ich ned sag ich wär ein genie. -- "The Right Honorable Gentleman is indebted to his memory for his jests and to his imagination for his facts." -- Sheridan ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
Hallo,
.. da rcfirewall status bzw start keine Fehlermeldung bezüglich FW_START bzw. START_FW bringt nehme ich mal an, daß jetzt in der /etc/rc.config die Variable START_FW auf yes steht, richtig? nope auf no - nur ip-forwarding & routed auf yes
ich hab mir mal den "Spass" gegönnt auf meinen SuSE 7 Bastelserver firewals.rpm und ipchains.rpm von SuSE 6.4 zu inst. (ftp.suse.com) Wenn aber FW_START und START_FW in /etc/rc.config nicht auf yes sind kommt der Fehler: server3:~ # rcfirewall start Starting Firewall Initialization: (final run) SuSEfirewall is not activated yet. Configure /etc/rc.config.d/firewall.rc.config and set FW_START in /etc/rc.config to "yes". failed server3:~ # D.h. mindestens eine der beiden Variablen müsste bei Dir auf yes sein. (S.h. auch grep -i fw /etc/rc.config oder grep -i start /sbin/SuSEfirewall ) Welche Version der FW ist das denn? Bei mir ist es dann firewals-2.1-27 . (Zu sehen mit rpm -q -a | grep -i fire ) Die Beisp. sind bei der 6.4 in /usr/doc/packages/firewals/EXAMPLES zu finden. (Wenn ich das richtig gelesen habe wird bei 6.4 die FW bei ip-up eh nicht gestartet. Ist also egal. Bin mir da aber nicht sicher.)
Der Kurztest wurde nur einmal vor dem starten der Modemverbindung eingegeben? 2x - nach dem dialin ( siehe oben )
.. das gibt's doch garnicht. Das muß doch dann funkt.
hhmhmm die variablen gibts in der rc.config ( v6.4 ) ned ... yast » konfigdatei ändern » mit F4 ( suche "FW" ) wird nur !!! Start_FW gefunden
Das die Variablen bei 6.4 nicht im YaST sind kann gut sein. Einstellen kann man sie ja auch in /etc/rc.config.d/firewall.rc.config . Die FW sollte mit: FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" FW_MASQ_DEV="$FW_DEV_WORLD" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" funktionieren. Da aber die ipchains Ausgaben richtig sind würde ich mal vermuten, daß irgendwas am Client noch nicht richtig ist. Wenn schon kein Win zur Verfügung steht, wie sieht's mit einer SuSE Live CD oder einem frisch inst. SuSE auf einem anderen Client aus? Hab da für solche Test immer meine alte SuSE 6.2 Live CD . Schnell reingeschoben und in 5 min Konf. Auf dem Client nur die Netzkarte (GW=Router-IP) konf. Sonst nichts. Wenn das auch nicht geht bleibt nur die Hoffnung, daß mit SuSE 7.2 alles besser wird. (Was besseres fällt mir jetzt auch nicht mehr ein, oder doch .. ICS von Win ab 98SE das geht so gut wie Immer .. in 10 min..) MfG Klaus
Am 03-Jun-01 schrieb NKRDL :
[....] Das die Variablen bei 6.4 nicht im YaST sind kann gut sein. Einstellen kann man sie ja auch in /etc/rc.config.d/firewall.rc.config . Die FW sollte mit: FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" FW_MASQ_DEV="$FW_DEV_WORLD" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" funktionieren.
Jo hat wunderbar "geklappt" :-((( Fw wie oben konfiguriert, in rc.config start_FW auf yes und dann restart.... Erbebnis : tty1: endlosmeldung ( nicht abbrechbar ) is a good choice tty2-6 : kein login möglich ( tot ) tty10 : standard systemmeldung via Client mit telnet : fehlanzeige - außerdem war das nfs ebenso tot Lösung : install-Disk - und unter serie sec packet firewals deinstalled ! von daher - weiter versuche über firewall zu routen mach ich früherstens mit 7.2 - alles andere wäre irrsinn. Falls jemand ne Möglichkeit weiß OHNE Firewall zu routen... her damit !!!!! wie gesagt vor etwa 1 1/2 Jahren lief das routing schomal - und definitiv ohne firewall. -- Before Xerox, five carbons were the maximum extension of anybody's ego. ---------------------------------- Registierter Linux - User #177159 ICQ - UIN : 51735624 HP : http://members.tripod.de/LinuxCobra/
* Marco_Jaeger@gmx.de
Am 03-Jun-01 schrieb NKRDL :
[....] Das die Variablen bei 6.4 nicht im YaST sind kann gut sein. Einstellen kann man sie ja auch in /etc/rc.config.d/firewall.rc.config . Die FW sollte mit: FW_DEV_WORLD="ppp0" FW_DEV_INT="eth0" FW_ROUTE="yes" FW_MASQUERADE="yes" FW_MASQ_NETS="192.168.0.0/24" FW_MASQ_DEV="$FW_DEV_WORLD" FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" funktionieren.
Jo hat wunderbar "geklappt" :-(((
Fw wie oben konfiguriert, in rc.config start_FW auf yes und dann restart.... Erbebnis : tty1: endlosmeldung ( nicht abbrechbar ) is a good choice tty2-6 : kein login möglich ( tot ) tty10 : standard systemmeldung
via Client mit telnet : fehlanzeige - außerdem war das nfs ebenso tot
Lösung : install-Disk - und unter serie sec packet firewals deinstalled !
von daher - weiter versuche über firewall zu routen mach ich früherstens mit 7.2 - alles andere wäre irrsinn.
Falls jemand ne Möglichkeit weiß OHNE Firewall zu routen... her damit !!!!!
wie gesagt vor etwa 1 1/2 Jahren lief das routing schomal - und definitiv ohne firewall.
Wie sieht denn überhaut die Ausgabe von "route -n" aus wenn Du online bist? Hab zwar nicht den ganzen Thread verfolgt, aber es sieht so aus, als ob nach dem einwählen keine default Route gesetzt wird. cu Bruno
Marco_Jaeger@gmx.de writes:
Hallo !
*----* ifconfig *----* eth0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C EtherTalk Phase 2 addr:65280/241 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22724 errors:0 dropped:0 overruns:0 frame:0 TX packets:20743 errors:0 dropped:0 overruns:0 carrier:0 collisions:1
eth0:0 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.11 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
eth0:1 Link encap:Ethernet HWaddr 00:80:AD:46:E2:8C inet addr:192.168.0.20 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Das kann ja auch nicht funktionieren, bei identischer Bcast addr. :-( und Netzadresse 192.168.0.0., da gehen ja alle broadcasts ueber beide NIC's Also eth0:0 inet addr 192.168.0.11 und eth0:1 inet addr 192.168.1.20 sollte Abhilfe schaffen. In /etc/route.conf solte stehen 192.168.0.0 0.0.0.0 255.255.255.0 eth0:0 192.168.1.0 0.0.0.0 255.255.255.0 eth0:1 Gruss Dieter -- Dieter Kluenter | Systemberatung BFI Rendering und Image Processing Tel: 040.64861967 | Fax: 040.64891521
participants (6)
-
bsemrau@t-online.de
-
Dieter Kluenter
-
Marc Schiffbauer
-
Marco_Jaeger@gmx.de
-
NKRDL
-
Udo Müller