Kein Internet-Zugang mehr nach Installation von SuSE-Patches

Hallo,

ich habe gerade die SuSE Patches der letzten 2 Monate über die Update-Funktion unter KDE geladen und installiert, jetzt habe ich keinen Internet-Zugang mehr. Ich betreibe SuSE 9.2, und bislang funktionierte alles problemlos, ich habe vom Computer eine Direktverbindung über einen Router. YaST2 findet unter "Network Devices" meine Netzwerk-Karte und gibt an "IBM 82541GI Gigabit Ethernet Controller Configured with DHCP". Doch kein Programm scheint das Netz zu finden.

Weiss jemand Rat?

Viele Grüße, Mark

Versuch mal

ping IP-DES-ROUTERS

wenn das nicht geht zeig uns die ausgabe von

ifconfig

Da sollte neben der Konfigurartion von lo auch die für eth0 angzeigt werden. Wenn dem nicht der Fall ist kannst du uns auch gleich die Ausgabe von

ifup eth0

zeigen.

Hallo nobbiew,

also: ifconfig ergibt:

eth0 Link encap:Ethernet HWaddr 00:11:25:31:922
inet addr:192.168.123.182 Bcast:192.168.123.255 Mask:255.255.255.0
inet6 addr: fe80::211:25ff:fe31:92d2/64 Scope:Link
UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:579 (579.0 b) TX bytes:1436 (1.4 Kb)
Base address:0x7000 Memory:d0220000-d0240000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:56 errors:0 dropped:0 overruns:0 frame:0
TX packets:56 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3634 (3.5 Kb) TX bytes:3634 (3.5 Kb)

und ifup eth0 bringt folgendes auf den Schirm:

eth0 device: Intel Corp. 82541GI Gigabit Ethernet Controller
eth0 configuration: eth-id-00:11:25:31:92:d2
DHCP client is already running on eth0

Ich nehme an, dass 192.168.123.182 die IP-Adresse des Routers ist? Wenn ich ping 192.168.123.182 eingebe, bekomme ich jedenfalls eine regelmaessige Rueckmeldung.

Also gut, deine Karte kann sich schon ganz gut mit sich selbst unterhalten (192.168.123.182 ist deine eigene IP). Jetzt weißt du zumindest, das die Funktioniert.

Du solltest jetzt mal ermitteln welche IP dein Router hat. Das steht oft im Handbuch drin, wenn du es nicht selbst geändert hast.

Mit

bzw.
kanns du dann ermitteln ob die IP auch als Gateway eingetragen ist.

Zeig uns diese Ausgaben u. evtl. auch die von
(geht nur als root)
bzw.
(geht auch als normaluser - zumindest bei SuSE)

Das Handbuch des Routers habe ich leider nicht. Allerdings habe ich nachgeschaut, welcher Gateway unter Windows eingetragen war und habe diesen in YaST2 als Default-Gateway eingetragen. Jetzt funktionieren firefox und YOU wieder.

Allerdings bekomme ich von ssh bislang nur die Rückmeldung 'No route to host'.

Hier sind die Angaben: ifstat eth0 liefert

#kernel
Interface RX Pkts/Rate TX Pkts/Rate RX Data/Rate TX Data/Rate
RX Errs/Drop TX Errs/Drop RX Over/Rate TX Coll/Rate
eth0 1166 0 1218 0 887131 0 170932 0
0 0 0 0 0 0 0 0

und netstat -r

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.123.0 * 255.255.255.0 U 0 0 0 eth0
PIB-Netz.physik * 255.255.248.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 192.168.123.254 0.0.0.0 UG 0 0 0 eth0

Zum traceroute-Befehl: Ich habe eingestellt, dass der Nameserver per DHCP gesetzt wird. Welche Nameserver-Adresse sollte ich angeben?

Der Nameserver wird in die Datei /etc/resolv.conf eingetragen.

Ich wollte nicht ifstat eth0 sondern ifstatus eth0. Bitte genauer lesen. Tut aber zum Problem mit ssh nichts zur sache.

Von wo aus willst du mit ssh auf wen zugreifen? Bislang war davon nicht die Rede.

Wenn du von intern einen Rechner extern mit ssh anfahren willst kann es durchaus sein, dass dein Router das ssh-Protokoll verwirft. Hängt ganz davon ab, wie der Router konfiguriert ist. Gilt übringens auch für den umgekehrten Weg.

Bisher konnte ich mich per ssh auf einem Uni-Rechner einloggen. Das hat vorher geklappt, auch von hier aus und über diesen Router. Kann es sein, dass die Firewall (die bei den Patches dabei war) etwas damit zu tun hat? Wieso der Gateway nach dem Herunterladen & Installieren der Patches geändert worden sein sollte ist mir schleierhaft. Aber auf jeden Fall funktioniert das Internet jetzt wieder...

Ja, die Firewall kann damit was zu tun haben.

Beende sie einfach mal über den Yast. Bitte den Yast verwenden, da hier mehrere rc-scripte betroffen sind.

Ich habe die firewall über YaST abgeschaltet (rcSuSEfirewall2 status sagt 'unused') und vorsichtshalber neu gebootet. Hat leider nichts gebracht: ssh sagt

connect to host ... port 22: No route to host

wobei ich für ... mehrere Uni-Rechner eingesetzt habe. Das Problem muss irgendwie auf meiner Seite liegen...

Mit putty unter Windows funktioniert es auch, irgendwas stimmt also bei mir hier mit ssh unter linux nicht...

Wie hast du die Firewall deaktiviert?

Es gibt in Yast, unter Sicherheit und Benutzer eigens einen Menüpunkt dafür. Wie gesagt da sind mehrere rcscripte davon betroffen. Als nicht über Systemdienste stoppen/starten.

Ja genau, ich habe YaST benutzt -> Security and Users -> Firewall und dann Stop Firewall and Remove From Boot Process ausgewählt.

Dann Next geklickt und bekomme als Bestätigung 'Firewall is turned off'.

Ich dachte, ich boote mal lieber neu, aber ich bekomme bei ssh noch immer no route to host

Irgendwie verstehe ich das alles nicht: Ich habe bei YaST (immer schon) eingestellt, dass meine IP-Adresse dynamisch sein soll. Irgendwo habe ich gelesen, dass dann die Angabe des Standard-Gateways nicht obligatorisch ist, und in der Tat: Wenn ich den Standard-Gateway bei YaST lösche, gibt es auch keine Probleme mit dem Internetzugang. Ebenso funktionierte es ja jetzt mit dem Standard-Gateway, den ich aus Windows heraus eingetragen hatte. Nur der Gateway, der vorher eingestellt war, klappt aus irgendeinem Grund nicht, allerdings funzte der ja auch vor dem Update mit den neuen Patches.

Wenn jetzt firefox und You vernünftig auf das Netz zugreifen können, sollte dann nicht auch ssh funktionieren? Was läuft denn dort grundsätzlich anders als bei den anderen Programmen?

(Die Firewall ist auf jeden Fall deaktiviert. Sollte sie eigentlich grundsätzlich deaktiviert bleiben? Oder was sollte man bei einer aktiven Firewall am besten einstellen?)

Ich habe gerade mal versucht, den Zielrechner anzupingen, selbst das klappt nicht...

Also wenn du dhcp verwendest solltest du keinen Gateway angeben, denn das soll ja dhcp für die erledigen.

Was nun bei ssh anders läuft ist, dass ssh auf einem anderen Port läuft. Nun kann es sein, dass dieser Port von einer Firewall geblockt wird.

Da ich der Suse Firewall an der Stelle nicht immer traue.

schau mal was bringt

Das sollte bei deaktivierter Firewall etwa so aussehen:

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Zum Vergrößern anklicken....

Hallo,

ich bekomme bei iptables -L -n genau das:

mh74 schrieb:

Ich habe gerade mal versucht, den Zielrechner anzupingen, selbst das klappt nicht...

Zum Vergrößern anklicken....

Ok dann liegt´s nicht am ssh sondern evtl. an den Netzwerkeinstellungen

Zeig mal die Auskunft von


Wobei du gerne die IP-Adresse des SERVERS aus-xen darfst. Die will gar keiner wissen. Ich will nur wissen, wie weit er kommt. Irgendwann tauchen zeilen mit *** *** *** auf und es geht nicht mehr weiter. Da kannst du dann auch abbrechen.

D.h. er versucht noch nicht mal den Standardateway, bzw. kann in dem Fall den Gateway schon nicht erreichen. Was wiederum bedeuten würde du hast noch eine falsche Route eingetragen.

Ich würde dir im Augenblick raten, die kompletten Netzkarteneinstellungen zu löschen und noch mal neu anzufangen.

Danach sollte die Ausgabe von nestat -r etwa so aussehen

Was mich in deiner Konfiguration etwas stutzig macht ist Wieso hast du neben der defaultroute noch eine Netzroute, die aber über die gleiche Netzwerkkarte geht? Das sieht danach aus, dass du zwei logische Netzwerke über das gleiche LAN betreibst. Stimmt das?