☰

O convidado kvm não pode se conectar fora do host, vice-versa

tag-icon • tag-icon networking kvm-virtualization ubuntu-12.04 opennebula
O convidado kvm não pode se conectar fora do host, vice-versa

Eu tenho um vmware vm rodando o servidor ubuntu 12.04 (nome = vmhost), com ponte de rede e acesso total à internet.

Este vmhost está usando o hipervisor kvm e também está executando uma rede vm (centOS 6.4).

O vmhost pode acessar a internet e também pode acessar seu vm, e o vm pode acessar o vmhost. A VM não pode acessar a Internet, nem posso fazer ping/ssh de outro PC na minha sub-rede.

Eu tenho uma ponte para o vmhost/its vm e verifiquei o iptables/routes, mas não encontrei nada. Também tenho ip_forwarding. Executando o tcpdump, vejo que o vmhost pode ver os pacotes, mas não faz nada com eles. Também tentei desabilitar o ufw, mas não ajudou.

Informações para rota VHMOST:

Tabela de roteamento IP do 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

Postarei os resultados do tcpdump em breve.

Também vale a pena mencionar que estou executando o opennebula com vmhost como meu host VM, mas não acho que esse seja o problema.

Responder1

Já me deparei com isso algumas vezes e a melhor solução que encontrei foi uma edição 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

Então corra:

sudo sysctl -p

Disseram-me (pela internet) que é uma prática melhor criar um arquivo conf em /etc/sysctl.d/, mas não importa o que eu coloque lá, sempre parece que preciso executar sysctl -p. Acho que é possível algum problema, tunedmas não investiguei muito profundamente.

Você pode configurar um cron job que garanta a execução sysctl -pna reinicialização:

@reboot      sleep 15; sysctl -p

Não é à prova de balas, mas funciona na maioria dos sistemas com os quais joguei.

Responder2

Você pode tentar desvincular todas as máquinas virtuais do NAT para que seu roteador atribua a cada uma delas seu próprio endereço IP separado usando DHCP. Como alternativa, tente manter cada uma das máquinas virtuais conectadas ao NAT e verificar "Replicar estado da conexão física" para cada máquina. Parece, intuitivamente, que um deles deveria apresentar um ambiente consistente e mutuamente visível para as máquinas virtuais.

informação relacionada