Am So, 07 Aug 2011 03:32:22 CEST schrieb David Haller: Hallo David,
Am Sun, 07 Aug 2011, Al Bogner schrieb:
Am So, 07 Aug 2011 00:00:04 CEST schrieb David Haller:
Am Sat, 06 Aug 2011, Helga Fischer schrieb:
Hmm... ich habe hier das Problem, dass ein Rechner wunderbar ins Netz kommt, sich Unfug im Netz angucken kann, aber keinen meiner internen Rechner erreicht. Mit IP anpingen kann ich alle. Das mit dem ping ist manchmal so eine Sache. Ich würde mich also nicht unbedingt auf pings verlassen.
ICMP ist eben nicht TCP oder UDP ;)
Was spuckt denn
LANG=C iptables -vnL | awk '$1 == "Chain" || $4 == "icmp" { print; }'
Ich hänge es, der Umbruch im Mail ist schwer leserlich.
Das nächste Mal bitte als .gz.
Gerne.
Komprimiert Logs genauso gut wie zip und ich kann's direkt im Mutt angucken. .bz2 oder so wäre auch ok, da geht wenigstens pipen. Aber .zip ist das unpraktischste.
Jedenfalls: auf englisch heißt es so schön:
"Hook, Line and Sinker!"
Zuerst ein bissl was aus 'man 7 icmp':
Bit definitions (see the kernel source file include/linux/icmp.h):
0 Echo Reply 3 Destination Unreachable * 4 Source Quench * 5 Redirect 8 Echo Request B Time Exceeded * C Parameter Problem * D Timestamp Request E Timestamp Reply F Info Request G Info Reply H Address Mask Request I Address Mask Reply
Ein 'ping' schickt "Echo Requests" raus (type 8) und die Antworten kommen als "Echo Reply" (Type 0) zurück. Dann gucken wir mal, was iptables bei also damit anstellt:
Chain FORWARD (policy DROP 0 packets, 0 bytes)
Chain forward_ext (1 references) 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED icmp type 0
Echo-Antworten werden "extern" durchgereicht .. aber kein "type 8", Anfragen also nicht! Im Log sollten sich Einträge dieser Regel finden:
0 0 LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDext-DROP-DEFLT '
Und in der Gegenrichtung sieht's genauso aus:
Chain forward_int (1 references) 0 0 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED icmp type 0 [..] 0 0 LOG icmp -- * * 0.0.0.0/0 0.0.0.0/0 limit: avg 3/min burst 5 LOG flags 6 level 4 prefix `SFW2-FWDint-DROP-DEFLT '
Kurzum: dir fehlt ne Forward-Regel für Pings (ICMP type 8). Wie das mit Yast / SuSEFirewall2 geht weiß ich nicht. Mit iptables in die SFW eingefügt:
Hmmh, IE9-Update wurde über Nacht auch nicht fertig, so habe ich es abgebrochen. Mit anderem Kabel, das ich leider wegen dem Update nicht früher verwenden konnte: Ping wird ausgef�hrt f�r suse.de [195.135.220.3] mit 32 Bytes Daten: Antwort von 195.135.220.3: Bytes=32 Zeit=54ms TTL=52 Antwort von 195.135.220.3: Bytes=32 Zeit=54ms TTL=52 Antwort von 195.135.220.3: Bytes=32 Zeit=53ms TTL=52 Antwort von 195.135.220.3: Bytes=32 Zeit=54ms TTL=52 Ping-Statistik f�r 195.135.220.3: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 53ms, Maximum = 54ms, Mittelwert = 53ms Ping wird ausgef�hrt f�r 192.168.178.1 mit 32 Bytes Daten: Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=63 Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=63 Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=63 Antwort von 192.168.178.1: Bytes=32 Zeit=1ms TTL=63 Ping-Statistik f�r 192.168.178.1: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust), Ca. Zeitangaben in Millisek.: Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms Ich liebe Hardware, die ein "bisschen" defekt ist ;-) Es ist schwer für mich zu verstehen, dass das Kabel schuld daran ist, dass forwarding nicht funktioniert hat. Aber verdächtig kam es mir schon vor, da es ja auch via Ubuntu nicht klappte und da habe ich meine eigenen iptables in die "interfaces" eingetragen. up /sbin/iptables -F up /sbin/iptables -X up /sbin/iptables -t nat -F up /sbin/iptables -A FORWARD -o eth0 -s 192.168.0.0/16 -m conntrack --ctstate NEW -j ACCEPT up /sbin/iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT up /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE up /sbin/sysctl -w net.ipv4.ip_forward=1
iptables -I 2 forward_int -p icmp --icmp-type echo-request -j ACCEPT iptables -I 2 forward_ext -p icmp --icmp-type echo-request -j ACCEPT
Das sollte man ggfs. noch nach Interface / Quelle einschränken.
Im Notfall könnte ich mich auch mal wieder durch die SFW2 wühlen, wo man sowas "regelgerecht" einbindet, aber obiges sollte schon mal helfen (irgendwo nach dem Start der SFW2 ausgeführt).
Achso, für mich schaut das sehr unlogisch aus, ICMP-Echo-Requests zu forwarden, Antworten aber nicht. Es sei denn, ich überseh da was bzgl. "RELATED,ESTABLISHED", aber erstens ist ICMP AFAIK verbindungslos, und zweitens gibt's nur in der INPUT Chain ein allgemeines "icmp .. RELATED" und ein 'icmp type 8 ACCEPT, aber nicht bei FORWARD.
Riecht nach nem Bugzilla-Eintrag gegen die SFW2 ...
Nachdem es nun funktioniert, dürfte sich da eine Konfiguration noch vor dir versteckt haben. Ich mache gerne weitere Tests, das Notebook habe ich vermutlich noch einige Tage, der Gateway-Rechner übersiedelt, aber ich könnte dann darauf via ssh zugreifen.
Oder du hast was in der Yast-Oberfläche übersehen. Die kenne ich nicht. Meine FW ist mit ein handgeklöppeltes initscript, das neben ein paar anderen Sachen ein 'iptables restore' einer handgeklöppelten "rules"-Datei macht ;) In der steht z.B. so Krams wie:
-A input_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT -A input_ext -p icmp -m icmp --icmp-type 0 -m state \ --state RELATED,ESTABLISHED -j ACCEPT -A output_ext -p icmp -m icmp --icmp-type 8 -j ACCEPT -A output_ext -p icmp -m icmp --icmp-type 0 -m state \ --state RELATED,ESTABLISHED -j ACCEPT
Forwarding mach ich hier z.Z. nicht, aber es ist übertragbar, s.o.
HTH, -dnh
PS: jup, die Regeldatei ist fast unverändert aus dem Hallerlix übernommen ;)
Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org