У меня есть машина Debian Wheezy, на которой я пытался настроить KVM с мостовой сетью. К сожалению, мост не может правильно пересылать трафик.
Моя установка следующая:
Физическая машина имеет eth0
который подключен к маршрутизатору с IP-адресом 192.168.0.1.
это eth0
является членом интерфейса моста br0
, который статически настроен на IP-адрес 192.168.0.101.
Сетевой интерфейс виртуальной машины vnet0
на физическом хосте и eth0
в виртуальной машине. В виртуальной машине интерфейс статически настроен на IP-адрес 192.168.0.110.
С физического хоста я могу пропинговать как виртуальную машину, так и маршрутизатор:
# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.331 ms
# ping 192.168.0.110
PING 192.168.0.110 (192.168.0.110) 56(84) bytes of data.
64 bytes from 192.168.0.110: icmp_req=1 ttl=64 time=0.417 ms
С виртуальной машины я могу проверить связь с физической машиной:
# ping 192.168.0.101:
PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_req=1 ttl=64 time=0.133 ms
Но я не могу пинговать роутер:
# ping 192.168.0.1:
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.110 icmp_seq=10 Destination Host Unreachable
Насколько я могу судить, мост настроен правильно, и все подключенные порты находятся в состоянии пересылки:
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.2cd444acf8ad no eth0
vnet0
# brctl showstp br0
br0
bridge id 8000.2cd444acf8ad
designated root 8000.2cd444acf8ad
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 0.00 bridge forward delay 0.00
ageing time 300.01
hello timer 1.20 tcn timer 0.00
topology change timer 0.00 gc timer 28.95
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.2cd444acf8ad path cost 4
designated bridge 8000.2cd444acf8ad message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.20
flags
vnet0 (2)
port id 8002 state forwarding
designated root 8000.2cd444acf8ad path cost 100
designated bridge 8000.2cd444acf8ad message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.20
flags
Обе iptables
и ebtables
пусты с политикой по умолчанию ACCEPT
:
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# ebtables -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Кто-нибудь знает, что вызывает эту проблему и как я могу ее решить?
Редактировать:
Видимо, мост распознает, что к нему что-то подключено, так как строит таблицу MAC:
# brctl showmacs br0
port no mac addr is local? ageing timer
1 2c:76:8a:ff:88:1d no 1.28 <- ???
1 2c:d4:44:ac:f8:ad yes 0.00 <- MAC of br0 and physical eth0
2 52:54:00:53:dd:34 no 143.80 <- MAC of VM's eth0
1 c8:1f:66:ba:83:33 no 0.00 <- MAC of router interface
2 fe:54:00:53:dd:34 yes 0.00 <- MAC of vnet0
Изменить 2:
Я только что создал вторую виртуальную машину. Этот компьютер имеет интерфейс vnet1 на физическом компьютере, его виртуальному eth0 назначен IP-адрес 192.168.0.111. Эта виртуальная машина также может проверять связь только с физической машиной, но не с маршрутизатором или исходной виртуальной машиной. brctl showstp
показывает все порты, включая vnet1, в состоянии пересылки и brctl showmacs
показывает MAC-адреса vnet1 и виртуального eth0 новой машины в дополнение к тому, что я написал выше.
Убедитесь, что ядро настроено для включения переадресации IP:
sysctl -a | grep forwarding
Вы можете включить:
sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv6.conf.all.forwarding=1
Также может быть проблема с проксированием ARP. Проверить с:
sysctl -a | grep proxy_arp
И устанавливаем командой:
sudo sysctl net.ipv4.conf.eth0.proxy_arp=1
Вы можете поместить ключи и значения в файл под /etc/sysctl.d
чтобы значения сбрасывались при перезагрузке.
Тестирование с другого устройства в подсети маршрутизатора может помочь определить проблему.
Тестирование с tcpdump
на eth0
интерфейс также может указывать на то, где происходит сбой соединения.
arp
запросы без действительного ответа указывают на проблему достижимости. echo
или echo reply
трафик может указывать на то, на какой стороне возникла проблема.