☰

Der KVM-Gast kann keine Verbindung außerhalb des Hosts herstellen und umgekehrt.

tag-icon • tag-icon networking kvm-virtualization ubuntu-12.04 opennebula
Der KVM-Gast kann keine Verbindung außerhalb des Hosts herstellen und umgekehrt.

Ich habe eine VMware-VM, auf der ein Ubuntu 12.04-Server (Name=VMhost) läuft, mit Netzwerkbrücke und vollem Internetzugang.

Dieser VMhost verwendet den KVM-Hypervisor und führt eine VM (CentOS 6.4) aus, die ebenfalls über eine Netzwerkbrücke verfügt.

Der VM-Host kann auf das Internet und auch auf seine VM zugreifen, und die VM kann auf den VM-Host zugreifen. Die VM kann nicht auf das Internet zugreifen, und ich kann auch von einem anderen PC in meinem Subnetz keinen Ping/SSH-Zugriff auf sie durchführen.

Ich habe eine Bridge für den VMhost/seine VM und habe die iptables/routes überprüft, aber nichts gefunden. Außerdem habe ich ip_forwarding. Wenn ich tcpdump ausführe, sehe ich, dass der VMhost die Pakete sehen kann, aber nichts damit macht. Ich habe auch versucht, das ufw zu deaktivieren, aber das hat nicht geholfen.

Informationen zur VHMOST-Route:

Kernel-IP-Routing-Tabelle

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.0.1     0.0.0.0         UG    100    0        0 virbr0
192.168.0.0     *               255.255.255.0   U     0      0        0 virbr0

The vmhouste Iptables -l
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     state RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination



Interface file:
auto lo
iface lo inet loopback

auto virbr0
iface virbr0 inet static
        address 192.168.0.21
        network 192.168.0.0
        netmask 255.255.255.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
    dns-nameservers 192.168.0.1
        bridge_ports eth0
        bridge_fd 9
        bridge_hello 2
        bridge_maxage 12
        bridge_stp off

Brctl show:
bridge name bridge id       STP enabled interfaces
virbr0      8000.000c29f8f8e4   yes     eth0 vnet1
vnet0       8000.000000000000   no   




 THE VM 
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 02:00:c0:a8:00:20 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.32/24 brd 192.168.0.255 scope global eth0
inet6 fe80::c0ff:fea8:20/64 scope link 
   valid_lft forever preferred_lft forever


ip route
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.32 
default via 192.168.0.1 dev eth0

Ich werde die TCPdump-Ergebnisse in Kürze veröffentlichen.

Erwähnenswert ist auch, dass ich Opennebula mit vmhost als meinem VM-Host ausführe, aber ich glaube nicht, dass dies das Problem ist.

Antwort1

Ich bin schon einige Male auf dieses Problem gestoßen und die beste Lösung, die ich gefunden habe, ist eine Bearbeitung von /etc/sysctl.conf:

net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Dann renne:

sudo sysctl -p

Mir wurde (aus dem Internet) gesagt, dass es besser ist, eine conf-Datei in zu erstellen /etc/sysctl.d/, aber egal, was ich dort eingebe, muss ich anscheinend immer ausführen sysctl -p. Ich denke, es liegt möglicherweise ein Problem mit vor, tunedaber ich habe es nicht näher untersucht.

Sie können einen Cron-Job einrichten, der die Ausführung sysctl -pbeim Neustart verpfuscht:

@reboot      sleep 15; sysctl -p

Es ist nicht narrensicher, aber es funktioniert auf den meisten Systemen, mit denen ich gespielt habe.

Antwort2

Sie können versuchen, alle virtuellen Maschinen vom NAT zu trennen, sodass Ihr Router ihnen über DHCP jeweils eine eigene IP-Adresse zuweist. Alternativ können Sie versuchen, die virtuellen Maschinen jeweils mit dem NAT verbunden zu lassen und für jede Maschine „Physischen Verbindungsstatus replizieren“ zu aktivieren. Intuitiv scheint es, dass eine dieser Optionen eine konsistente, für beide Seiten sichtbare Umgebung für die virtuellen Maschinen darstellen sollte.

verwandte Informationen