nurnoch icmp packets und related connections aus kvm?

[mojodoll]

[solved] nurnoch icmp packets und related connections aus kvm?

Ich habe mir gestern erfolgreich einen Centos6 KVM Container gebaut, mit Networking via NAT/Masquerading. Wie gewünscht ist auch der komplette HTTP/MySQL-Stack dorthin umgezogen.
Das funktionierte dann auch alles ordentlich, bis ich schlaftrunken heute morgen um 4 Uhr meinte: "Ach, räumen wir doch mal die überflüssigen iptables-rules auf!".
Fazit: a.) Ich kriege ohne Probleme ICMP Packets aus dem Container, traceroutes und ping laufen also einwandfrei.
b.) auch ist besagter Webstack noch einwandfrei zu erreichen - related/established connections kommen also wohl noch durch.
edit: unsinn, SSH geht natürlich auch noch, incoming geht also quasi alles, bis auf wie unten angeführt https
c.) DNS-Resolves gehen auch

Problem ist nun, das sonst garnichtsmehr raus kommt, obwohl es gerne möchte: kein "HEAD <url>", kein yum, keine Webmailapplikation etc..
Ausserdem kriegt man wenn man per https connecten möchte folgendes unerfreuliches:

SSL received a record that exceeded the maximum permissible length.
(Error code: ssl_error_rx_record_too_long)

Das funktionierte natürlich auch wunderbar bis zum "Unfall" heute morgen.

Nun muss aber auch natürlich nicht zwangsläufig eine der iptables Rules zerballert sein, auf mich machen die auf den ersten Blick einen recht gesunden eindruck:

192.168.100.1 ist der Guest, 192.168.100.254 der Gateway/Host:

# iptables -L -v
Chain INPUT (policy DROP 59 packets, 6504 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  46M  111G ACCEPT     all  --  lo     any     anywhere             anywhere            
 908M  661G ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
 408K   20M ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:http
15774  822K ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp dpt:https
 <snip>
 1084 65088 ACCEPT     all  --  any    any     192.168.100.1        anywhere            
  377 22620 ACCEPT     tcp  --  any    any     192.168.100.1        anywhere             tcp dpt:2080
11055  663K ACCEPT     tcp  --  any    any     192.168.100.1        anywhere             tcp dpt:45197
68294 9360K LOG        all  --  any    any     anywhere             anywhere             LOG level warning ip-options prefix "iptables: "

Chain FORWARD (policy ACCEPT 26074 packets, 23M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 52698 packets, 50M bytes)
 pkts bytes target     prot opt in     out     source               destination

# iptables -L -v -t nat
Chain PREROUTING (policy ACCEPT 4153 packets, 296K bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1836  101K DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:http to:192.168.100.1:80
   67  3584 DNAT       tcp  --  any    any     anywhere             anywhere             tcp dpt:https to:192.168.100.1:80

Chain INPUT (policy ACCEPT 3052 packets, 184K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 8807 packets, 595K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 3816 packets, 232K bytes)
 pkts bytes target     prot opt in     out     source               destination         
46735 3061K MASQUERADE  all  --  any    eth0    anywhere             anywhere

Ich bin jetzt auch noch nicht sonderlich weit gekommen mit der Fehleranalyse, da etwas in Eile, rasante Ratschläge wären hervorragend.
Die Freunde jammern schon dass "email ja nicht ginge" - noch kann ich das mit lapidaren Sprüchen wie "l2thunderbird" abschmettern, aber wohl nichtmehr lange

 

[mojodoll]

So, https funktioniert nun auch wieder, natürlich ganz besonders schlau dport 443 auf dem Host auf Port 80 des Guests zu forwarden...

Witzigerweise kommt Roundcube auch per IMAP und SMTP auf den Mailserver auf dem Hostsystem - und kann auch Mails raussenden. Eine XMLRPC Verbindung zum Host funktioniert nun auch wieder.
GET und yum haben aber nachwievor Probleme:

yum update
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 error was
14: PYCURL ERROR 7 - "Failed to connect to 2610:28:3090:3001:dead:beef:cafe:fed4: Network is unreachable"
 * base: ftp.plusline.de
 * epel: mirror.fraunhofer.de
 * extras: ftp.plusline.de
 * ius: archive.linux.duke.edu
 * updates: ftp.plusline.de
http://ftp.plusline.de/centos/6.0/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "Failed to connect to 2a02:2e0:4::1: Network is unreachable"
Trying other mirror.
http://centos.kiewel-online.ch/centos/6.0/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "Failed to connect to 2001:4dd0:fc1d::2: Network is unreachable"
Trying other mirror.
http://ftp.hosteurope.de/mirror/centos.org/6.0/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "Failed to connect to 2a01:488:10:1::50ed:888a: Network is unreachable"
Trying other mirror.
http://mirror.softaculous.com/centos/6.0/os/x86_64/repodata/repomd.xml: [Errno 14] PYCURL ERROR 7 - "couldn't connect to host"
Trying other mirror.

Wobei es mich da auch etwas wundert dass ipv6 überhaupt versucht wird, das soll es eigentlich nicht tun.
edit: ipv6 ist nun disabled - das Grundproblem besteht aber nachwievor.

edit2: br0 nimmt die packets gern entgegen, wohingegen eth0 gänzlich stumm bleibt:

# tcpdump -vvi br0 src 192.168.100.1 and dst port 80
tcpdump: listening on br0, link-type EN10MB (Ethernet), capture size 96 bytes
15:55:37.000741 IP (tos 0x0, ttl 64, id 53724, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.1.49708 > serversupportforum.de.http: S, cksum 0x6fe4 (correct), 2640980177:2640980177(0) win 5840 <mss 1460,sackOK,timestamp 2947341 0,nop,wscale 7>
15:55:37.000768 IP (tos 0x0, ttl 63, id 53724, offset 0, flags [DF], proto TCP (6), length 60) 192.168.100.1.49708 > 192.168.100.1.http: S, cksum 0x65ea (correct), 2640980177:2640980177(0) win 5840 <mss 1460,sackOK,timestamp 2947341 0,nop,wscale 7>

wieso kann ich mir nicht erklären, an den routes hab ich nichts geändert, als Vorlage diente übrigens: http://en.gentoo-wiki.com/wiki/KVM#Launch_KVM_Guest1_with_network_enabled . Am Hostsystem funktioniert natürlich alles einwandfrei.

edit solution:
Man hat mir nun im IRC weitergeholfen, ich versteh zwar nicht was die DNAT rules in der prerouting chain mit vom Guest ausgehenden TCP-Requests zu tun haben, aber das Problem war dass den beiden "forwards" von port 80 und 443 ein Interface, nämlich eth0 gefehlt hat. Macht insofern auch Sinn, als dass ICMP ja rausging weils -p tcp nicht matched.
Wieso auch immer, wenn mir das jmd erklären mag, nur zu, ich mach mich auch mal selber schlau.