☰

El invitado kvm no puede conectarse fuera del host, y viceversa

tag-icon • tag-icon networking kvm-virtualization ubuntu-12.04 opennebula
El invitado kvm no puede conectarse fuera del host, y viceversa

Tengo una máquina virtual vmware que ejecuta el servidor ubuntu 12.04 (nombre = vmhost), con puente de red y acceso completo a Internet.

Este vmhost utiliza el hipervisor kvm y también ejecuta un vm (centOS 6.4) con puente de red.

El vmhost puede acceder a Internet y también a su máquina virtual, y la máquina virtual puede acceder al vmhost. La máquina virtual no puede acceder a Internet, ni puedo hacer ping/ssh desde otra computadora en mi subred.

Tengo un puente para vmhost/su vm y revisé iptables/rutas pero no encontré nada. También tengo ip_forwarding. Al ejecutar tcpdump veo que vmhost puede ver los paquetes pero no hace nada con ellos. También intenté desactivar el ufw pero no sirvió de nada.

Información para la ruta VHMOST:

Tabla de enrutamiento IP del kernel

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

Publicaré los resultados de tcpdump en breve.

También vale la pena mencionar que estoy ejecutando opennebula con vmhost como mi host vm, pero no creo que ese sea el problema.

Respuesta1

Me he encontrado con esto varias veces y la mejor solución que he encontrado es una edición de /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

Entonces corre:

sudo sysctl -p

Me dijeron (en Internet) que es una mejor práctica crear un archivo conf en /etc/sysctl.d/, pero no importa lo que ponga allí, parece que siempre necesito ejecutar sysctl -p. Creo que es posible que haya algún problema, tunedpero no lo he investigado demasiado en profundidad.

Puede configurar un trabajo cron que impida la ejecución sysctl -pal reiniciar:

@reboot      sleep 15; sysctl -p

No es a prueba de balas, pero funciona en la mayoría de los sistemas con los que he jugado.

Respuesta2

Es posible que desee intentar desconectar todas las máquinas virtuales de la NAT para que su enrutador asigne a cada una su propia dirección IP mediante DHCP. Alternativamente, intente mantener cada máquina virtual conectada a NAT y marque "Replicar estado de conexión física" para cada máquina. Intuitivamente, parece que uno de ellos debería presentar un entorno coherente y mutuamente visible para las máquinas virtuales.

información relacionada