☰

Гость kvm не может подключиться к внешней стороне хоста, и наоборот

tag-icon • tag-icon networking kvm-virtualization ubuntu-12.04 opennebula
Гость kvm не может подключиться к внешней стороне хоста, и наоборот

У меня есть виртуальная машина VMware, на которой работает сервер Ubuntu 12.04 (имя=vmhost), с сетевым мостом и полным доступом к Интернету.

Этот vmhost использует гипервизор kvm и работает под управлением виртуальной машины (CentOS 6.4), а также сетевого моста.

VMhost может получить доступ к интернету и также может получить доступ к своей виртуальной машине, а виртуальная машина может получить доступ к vmhost. VM не может получить доступ к интернету, и я не могу пинговать/ssh к ней с другого ПК в моей подсети.

У меня есть мост для vmhost/его vm, я проверил iptables/routes, но ничего не нашел. Также у меня есть ip_forwarding. Запустив tcpdump, я вижу, что vmhost видит пакеты, но ничего с ними не делает. Я также пробовал отключить ufw, но это не помогло.

Информация по маршруту VHMOST:

Таблица маршрутизации IP ядра

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

Скоро я опубликую результаты tcpdump.

Стоит также отметить, что я запускаю opennebula с vmhost в качестве хоста виртуальной машины, но не думаю, что проблема в этом.

решение1

Я сталкивался с этим несколько раз, и лучшее решение, которое я нашел, — это редактирование /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

Затем выполните:

sudo sysctl -p

Мне сказали (в интернете), что лучше всего создавать файл conf в /etc/sysctl.d/, но что бы я туда ни вставлял, мне всегда нужно запускать sysctl -p. Я думаю, что это может быть какая-то проблема с , tunedно я не исследовал ее слишком глубоко.

Вы можете настроить задание cron, которое заблокирует запуск sysctl -pпри перезагрузке:

@reboot      sleep 15; sysctl -p

Он не абсолютно надежен, но работает на большинстве систем, с которыми я играл.

решение2

Вы можете попробовать разъединить все виртуальные машины с NAT, чтобы ваш маршрутизатор назначал каждой свой собственный отдельный IP-адрес с помощью DHCP. В качестве альтернативы попробуйте оставить виртуальные машины подключенными к NAT и проверить "Replicate physical connection state" для каждой машины. Кажется, интуитивно, что один из них должен представлять собой согласованную, взаимно видимую среду для виртуальных машин.

Связанный контент