ISDN-Einwahl/Namensauflösung funktioniert nur manchmal
Hi Liste, ich habe Probleme mit dem Internetzugang unter SuSE 8.0 (FritzCard PCI, hisax, i4l-Patch eingespielt): Der Zugriff über z.B. ssh und scp funktioniert, über grafischen Webbrowser kommt nach einem Neustart keine Verbindung zustande, nach einer manuellen Einwahl funktionierts, danach auch automatisch. Über w3m wird nie eine Verbindung aufgebaut mit "unknown uri", ebenso ein ping auf einen Domainnamen. Ping auf eine IP baut eine Verbindung auf, aber es komme wird die lokale IP angegeben, beim Versuch bei einer bestehenden Verbindung läuft der ping mit der "from"-Angabe der dynamische Internet-IP. Von dem einzigen Windows-Client wird über einen Browser eine Verbindung aufgebaut, es kommt aber nichts an. Ein ping vom Client funktioniert ausschliesslich für den Server (Netzwerk läuft also), aber nicht auf Internet-IP's. Der ping baut auch hier wiederum eine Internetverbing auf. Habe ich einen Fehler im routing gemacht und wenn ja wo und wie kann ich ihn beheben. Sowohl der Eintrag in /etc/sysconfig/network/routes, als auch in einer manuell erstellten ifroute-eth0 von formal korrekten, aber inhaltlich blödsinnigen Einträgen zu Testzwecken ergaben keine Änderung von route -n nach einem Neustart der Netzverbindungen. Die gleiche Konfiguration unter 7.2 lief übrigens, ausser dass ippp0 192.168.0.99 als "vorab"-Adresse hatte. 8.0 wurde übrigens neu installiert, kein Update. Zur Konfiguration: lokale IP Linux: 192.168.100.100 lokale IP Win: 192.168.100.101 Internet-DNS-IPs sowohl lokal eingetragen, als auch "über Provider beziehen" in der yast-Konfiguration, Searchlist lokal ist der domain-Name des linux-servers hedone:/home/holgi # route -n Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface 192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ippp0 hedone:/home/holgi # ifconfig eth0 Protokoll:Ethernet Hardware Adresse 00:80:AD:20:4F:7E inet Adresse:192.168.100.100 Bcast:192.168.100.255 Maske:255.255.255.0 inet6 Adresse: fe80::280:adff:fe20:4f7e/10 Gültigkeitsbereich:Verbindung UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5 errors:0 dropped:0 overruns:0 frame:0 TX packets:11 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:100 RX bytes:356 (356.0 b) TX bytes:330 (330.0 b) Interrupt:11 Basisadresse:0xd800 ippp0 Protokoll:Punkt-zu-Punkt Verbindung UP PUNKTZUPUNKT RUNNING NOARP DYNAMIC MTU:1500 Metric:1 RX packets:446 errors:0 dropped:0 overruns:0 frame:0 TX packets:554 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:30 RX bytes:256167 (250.1 Kb) TX bytes:70632 (68.9 Kb) lo Protokoll:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:136 errors:0 dropped:0 overruns:0 frame:0 TX packets:136 errors:0 dropped:0 overruns:0 carrier:0 Kollisionen:0 Sendewarteschlangenlänge:0 RX bytes:9704 (9.4 Kb) TX bytes:9704 (9.4 Kb) Vielen Dank schon einmal für Eure Hilfe. Gruß, Holger Nowak
Klingt für mich nach einem Problem der Auflösung des Nameserver. Schau' mal, was in der resolv.conf steht (ich glaub', die ist auch bei SuSe in /etc/ kann das aber gerade nicht nachschauen, da mein Rechner zu Hause ist). Bei der dynamischen IP vergabe beim Eiwählen wird die Datei aber geändert (zumindest, wenn ich die Standard-Konfig von der 8.0 richtig verstanden habe), da der Nameserver und die IP bei DHCP per default vom Server kommt. Thorsten On Mon, 2002-07-01 at 16:06, Holger Nowak wrote:
ich habe Probleme mit dem Internetzugang unter SuSE 8.0 (FritzCard PCI, hisax, i4l-Patch eingespielt): Der Zugriff über z.B. ssh und scp funktioniert, über grafischen Webbrowser kommt nach einem Neustart keine Verbindung zustande, nach einer manuellen Einwahl funktionierts, danach auch automatisch. Über w3m wird nie eine Verbindung aufgebaut mit "unknown uri", ebenso ein ping auf einen Domainnamen. Ping auf eine IP baut eine Verbindung auf, aber es komme wird die lokale IP angegeben, beim Versuch bei einer bestehenden Verbindung läuft der ping mit der "from"-Angabe der dynamische Internet-IP. Von dem einzigen Windows-Client wird über einen Browser eine Verbindung aufgebaut, es kommt aber nichts an. Ein ping vom Client funktioniert ausschliesslich für den Server (Netzwerk läuft also), aber nicht auf Internet-IP's. Der ping baut auch hier wiederum eine Internetverbing auf.
-- ----------------------------------------------------------------------------- ///////// Thorsten Trippel ttrippel@spectrum.uni-bielefeld.de // Computational Linguistics and Spoken Language // // Office: C6-149 Phone: +49 (0) 521 106 3519 // // URL: http://www.spectrum.uni-bielefeld.de/~ttrippel // Bielefeld University, Federal Republic of Germany ///////// Department of Linguistics and Literary Studies -----------------------------------------------------------------------------
Hallo Thorsten, On 1 Jul 2002, Thorsten Trippel wrote:
Schau' mal, was in der resolv.conf steht (ich glaub', die ist auch bei SuSe in /etc/ kann das aber gerade nicht nachschauen, da mein Rechner zu Hause ist). Bei der dynamischen IP vergabe beim Eiwählen wird die Datei aber geändert (zumindest, wenn ich die Standard-Konfig von der 8.0
Zumindest bin ich dadurch einen Schritt weiter, wenn auch nicht am Ziel. Die resolv.conf unterscheidet sich zwar nicht wenn eine Internetverb. aufgebaut ist oder nicht, _aber_ die Rechte! Ist der Rechner nicht im Inet hat nur root Leserechte, ändert man dies auf Leserechte für alle, klappt auch die Namensauflösung von ping und w3m, nur: ein ping auf ip ergibt immer noch ... from 192.168.100.100 ohne dass Pakete ankommen, aber eine Verbindung aufgemacht wird. Steht eine Verbindung, dann .. from 134.95.88.8 und Pakete kommen an. Ebenso wenig funktioniert die Internetverb. vom Win-Client. Eine Verbindung wird hergestellt, aber es kommt nichts an (weder ping, noch über Browser). Vielleicht noch eine Idee? Danke aber schon mal, Holger
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi! On Monday 01 July 2002 18:20, Holger Nowak wrote:
On 1 Jul 2002, Thorsten Trippel wrote:
Schau' mal, was in der resolv.conf steht (ich glaub', die ist auch bei SuSe in /etc/ kann das aber gerade nicht nachschauen, da mein Rechner zu Hause ist). Bei der dynamischen IP vergabe beim Eiwählen wird die Datei aber geändert (zumindest, wenn ich die Standard-Konfig von der 8.0
Zumindest bin ich dadurch einen Schritt weiter, wenn auch nicht am Ziel. Die resolv.conf unterscheidet sich zwar nicht wenn eine Internetverb. aufgebaut ist oder nicht, _aber_ die Rechte! Ist der Rechner nicht im Inet hat nur root Leserechte, ändert man dies auf Leserechte für alle, klappt auch die Namensauflösung von ping und w3m, nur:
ein ping auf ip ergibt immer noch ... from 192.168.100.100 ohne dass Pakete ankommen, aber eine Verbindung aufgemacht wird. Steht eine Verbindung, dann .. from 134.95.88.8 und Pakete kommen an.
Schaut fast so aus, als würde das triggern des automatischen Verbindungsaufbaus nicht funktionieren. Wenn ich jetzt nur wüßte, wie das bei ippp0 konfiguriert wurde. Ist schon solange her... :-((
Ebenso wenig funktioniert die Internetverb. vom Win-Client. Eine Verbindung wird hergestellt, aber es kommt nichts an (weder ping, noch über Browser).
Läuft vielleicht auf dem Linux-Server eine Firewall? (Zeigt "iptables -L" Regeln an?) Ist das IP-Forwarding auf dem Linux-Server aktiviert? Was sagt "cat /proc/sys/net/ipv4/ip_forward"? Wenn das nichts bringt, wäre die Ausgabe von "tcpdump -i ippp0" hilfreich, wenn Du ein ping vom Win-Rechner losschickst. Dann wüßte man vielleicht eher, was genau schiefgeht. - -- Ciao, Gernot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9IIiHk997/GGeSeIRAnc3AJ9AZLznTYSk0LxtLcEM34tWlodAwgCfUZAB qVLOHlmukfqeOySJSqnD1nI= =E6Zq -----END PGP SIGNATURE-----
Hi, zuerst. Ich habe das script von ** mit den IP-Tables ausprobiert. Stellte fest, dass es sowohl ipv4 und ipv6-Protokolle gibt, mit beiden (iptables und ip6tables) klappts nicht. Was ist der Unterschied zwischen beiden? Auf dem Rechner läuft (noch) keine Firewall und ip-forwarding habe ich im sysctl aktiviert, als dass es auch mit ip-up.local durch oben genanntes Script aktiviert wird.
Wenn das nichts bringt, wäre die Ausgabe von "tcpdump -i ippp0" hilfreich,
Ich habe mal drei verschiedene Ausgaben gepostet, eine mit einem ping vom win-client, eine mit ping auf ip vom linux-server (laufen beide nicht) und eine mit ping auf hostname vom linux-server. Mir scheint, dass nach 5 sec der ping funktionieren müsste (s.u.), allerdings verstehe ich die erste Fehlermeldung nicht. Hoffe, die Mail ist dadurch nicht zu lang geworden, wusste nicht wo ich abschneiden kann. Der FQN ist hedone.bzhn.de mit 192.168.100.100, der win-client ist 192.168.100.101 mit ping 134.95.100.208 (Nameserver der Uni) vom win-client, wieso Zugriff auf den Mail-Server? hedone:/etc/ppp # tcpdump -i ippp0 tcpdump: WARNING: ippp0: no IPv4 address assigned tcpdump: listening on ippp0 20:21:55.639779 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.647332 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.663950 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.680330 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.684069 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.709826 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.714079 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.725445 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.741700 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.759478 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.759516 hedone.bzhn.de.optima-vnet > noc2.rrz.Uni-Koeln.DE.domain: 19140+ PTR? 208.100.95.134.in-addr.arpa. (45) (DF) 20:21:58.763719 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:58.776099 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:21:59.895038 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:22:00.667119 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt > mail1.rrz.Uni-Koeln.DE.domain: 19140+ PTR? 208.100.95.134.in-addr.arpa. (45) (DF) 20:22:00.723057 mail1.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt: 19140* 1/4/4 (240) (DF) 20:22:00.724058 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt > noc2.rrz.Uni-Koeln.DE.domain: 19141+ PTR? 101.100.168.192.in-addr.arpa. (46) (DF) 20:22:00.763817 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt: 19141 NXDomain 0/1/0 (123) (DF) 20:22:00.810692 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt > noc2.rrz.Uni-Koeln.DE.domain: 19142+ PTR? 23.129.95.134.in-addr.arpa. (44) (DF) 20:22:00.864940 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt: 19142* 1/4/4 (239) (DF) 20:22:00.888840 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt > noc2.rrz.Uni-Koeln.DE.domain: 19143+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:22:00.944575 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt: 19143* 1/4/4 (253) (DF) 20:22:01.395075 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:22:02.895117 192.168.100.101 > mail1.rrz.Uni-Koeln.DE: icmp: echo request 20:22:05.432899 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt > noc2.rrz.Uni-Koeln.DE.domain: 1446+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:22:05.488677 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ddt: 1446* 1/4/4 (253) (DF) mit selben ping vom _Linux_-Rechner (funkt nicht) hedone:/etc/ppp # tcpdump -i ippp0 tcpdump: WARNING: ippp0: no IPv4 address assigned tcpdump: listening on ippp0 20:11:36.724304 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.627443 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.644938 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.659558 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.663312 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.688683 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.693058 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.704435 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.720684 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.738472 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.738511 hedone.bzhn.de.td-postman > noc2.rrz.Uni-Koeln.DE.domain: 46857+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:11:39.746576 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.758075 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:39.768082 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:40.776995 hedone.bzhn.de > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:11:41.827045 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma > mail1.rrz.Uni-Koeln.DE.domain: 46857+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:11:41.883317 mail1.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma: 46857* 1/4/4 (245) (DF) 20:11:41.924956 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma > noc2.rrz.Uni-Koeln.DE.domain: 46858+ PTR? 23.129.95.134.in-addr.arpa. (44) (DF) 20:11:41.979195 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma: 46858* 1/4/4 (239) (DF) 20:11:42.003281 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma > noc2.rrz.Uni-Koeln.DE.domain: 46859+ PTR? 208.100.95.134.in-addr.arpa. (45) (DF) 20:11:42.057950 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma: 46859* 1/4/4 (240) (DF) 20:11:42.058529 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma > noc2.rrz.Uni-Koeln.DE.domain: 46860+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:11:42.114438 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma: 46860* 1/4/4 (253) (DF) 20:11:47.302003 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma > noc2.rrz.Uni-Koeln.DE.domain: 60668+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:11:47.358951 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.cma: 60668* 1/4/4 (253) (DF) mit ping www.uni-koeln.de vom linux-rechner, was klappt hedone:/etc/ppp # tcpdump -i ippp0 tcpdump: WARNING: ippp0: no IPv4 address assigned tcpdump: listening on ippp0 20:24:33.529429 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.029433 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.045795 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.059671 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.063299 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.095300 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.100553 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.110418 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.125921 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.143041 hedone.bzhn.de.ddt > noc2.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:36.143082 hedone.bzhn.de.remote-as > noc2.rrz.Uni-Koeln.DE.domain: 57541+ PTR? 23.129.95.134.in-addr.arpa. (44) (DF) 20:24:38.537106 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.brvread > mail1.rrz.Uni-Koeln.DE.domain: 25717+ A? www.uni-koeln.de. (34) (DF) 20:24:38.596813 mail1.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.brvread: 25717* 2/5/5 CNAME[|domain] (DF) 20:24:38.604375 ra-uni1-c71-nc.rrz.Uni-Koeln.DE > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:24:38.635880 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.brvread > mail1.rrz.Uni-Koeln.DE.domain: 57541+ PTR? 23.129.95.134.in-addr.arpa. (44) (DF) 20:24:38.636556 www1.rrz.Uni-Koeln.DE > ra-uni1-c71-nc.rrz.Uni-Koeln.DE: icmp: echo reply (DF) 20:24:38.637314 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 25718+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:24:38.689312 mail1.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.brvread: 57541* 1/4/4 (239) (DF) 20:24:38.724816 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 25718* 1/4/4 (245) (DF) 20:24:38.744216 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 57542+ PTR? 208.100.95.134.in-addr.arpa. (45) (DF) 20:24:38.798189 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 57542* 1/4/4 (240) (DF) 20:24:38.798717 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 57543+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:24:38.853948 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 57543* 1/4/4 (253) (DF) 20:24:38.854630 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 57544+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:24:38.909321 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 57544* 1/4/4 (245) (DF) 20:24:39.607562 ra-uni1-c71-nc.rrz.Uni-Koeln.DE > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:24:39.639485 www1.rrz.Uni-Koeln.DE > ra-uni1-c71-nc.rrz.Uni-Koeln.DE: icmp: echo reply (DF) 20:24:39.639979 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 25719+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:24:39.694478 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 25719* 1/4/4 (245) (DF) 20:24:40.616930 ra-uni1-c71-nc.rrz.Uni-Koeln.DE > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:24:40.649028 www1.rrz.Uni-Koeln.DE > ra-uni1-c71-nc.rrz.Uni-Koeln.DE: icmp: echo reply (DF) 20:24:40.649508 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 25720+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:24:40.704034 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 25720* 1/4/4 (245) (DF) 20:24:41.626924 ra-uni1-c71-nc.rrz.Uni-Koeln.DE > www1.rrz.Uni-Koeln.DE: icmp: echo request (DF) 20:24:41.658840 www1.rrz.Uni-Koeln.DE > ra-uni1-c71-nc.rrz.Uni-Koeln.DE: icmp: echo reply (DF) 20:24:41.659328 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 25721+ PTR? 203.100.95.134.in-addr.arpa. (45) (DF) 20:24:41.713850 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 25721* 1/4/4 (245) (DF) 20:24:42.580093 ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd > noc2.rrz.Uni-Koeln.DE.domain: 25515+ PTR? 72.88.95.134.in-addr.arpa. (43) (DF) 20:24:42.635383 noc2.rrz.Uni-Koeln.DE.domain > ra-uni1-c71-nc.rrz.Uni-Koeln.DE.ansyslmd: 25515* 1/4/4 (253) (DF) Bin in übrigens begeistert von den superschnellen Lösungsvorschlägen. Gruß, Holger
Hallo Holger,
...
Ebenso wenig funktioniert die Internetverb. vom Win-Client. Eine Verbindung wird hergestellt, aber es kommt nichts an (weder ping, noch über Browser).
Vielleicht noch eine Idee?
Dein Problem, dass Du keine Pakete von Deinem Client "wegbekommst", klingt danach als sei das Masquerading nicht eingestellt. Beim SuSE 8 Standardkernel geht das am leichtesten über den iptables Befehl. Probier mal folgende Zeilen in Dein /etc/ppp/ip-up.local Skript (falls nicht existent, einfach erstellen und ausführbar machen) einzutragen und ob sich dann etwas ändert: # Kernel-Forwarding aktivieren echo 1 > /proc/sys/net/ipv4/ip_forward # Network Access Translation Modul laden modprobe iptable_nat # In der MASQUERADING über iptables aktivieren iptables -t nat -A POSTROUTING -o "PPP-Device einfügen" -j MASQUERADE
Danke aber schon mal, Holger
Grüße Sven
participants (4)
-
Gernot Hillier -
Holger Nowak -
Sven Gailus -
Thorsten Trippel