Я исследую эту проблему несколько дней и пока не нашел ответа. Мы будем очень благодарны за вашу помощь!
У меня есть несколько виртуальных машин (виртуальных машин), работающих на физическом сервере. Сервер использует мост Linux (br100) для соединения этих виртуальных машин:
# brctl show
bridge name bridge id STP enabled interfaces
br100 8000.984be15fe7e3 no eth1.1729
vnet0
vnet1
vnet0 и vnet1 - виртуальные сетевые адаптеры виртуальных машин.
br100 (физический сервер) назначен IP 172.16.0.11. Виртуальной машине, подключенной к vnet1, назначается 172.16.0.3, vnet0 - 172.16.0.5.
Все идет нормально. 172.16.0.3 может пинговать 172.16.0.5 без проблем.
Теперь я пытаюсь настроить 172.16.0.3 в качестве маршрутизатора (сервер openvpn, если это имеет значение) для подсети 10.8.0.0/16.
Вот и моя проблема: машины в 10.8.0.0/16 (в данном случае 10.8.0.6) могут пинговать 172.16.0.3, но не могут пинговать 172.16.0.5.
(Я думаю) я исключил все очевидные причины: включен ip_forward, iptables сброшен и т. Д. Теперь я сузил причину до: br100 не пересылает пакеты как следует!
Когда я пингую 172.16.0.5 из 10.8.0.6, пакеты были доставлены в vnet1 (VM 172.16.0.3) на физическом сервере:
# tcpdump -leni vnet1 icmp
tcpdump: WARNING: vnet1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet1, link-type EN10MB (Ethernet), capture size 65535 bytes
07:45:03.858356 02:16:3e:6a:42:57 > 02:16:3e:02:40:82, ethertype IPv4 (0x0800), length 98:
10.8.0.6 > 172.16.0.5: ICMP echo request, id 63242, seq 1046, length 64
07:45:04.858239 02:16:3e:6a:42:57 > 02:16:3e:02:40:82, ethertype IPv4 (0x0800), length 98:
10.8.0.6 > 172.16.0.5: ICMP echo request, id 63242, seq 1047, length 64
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Но не перенаправляются на vnet0 (172.16.0.5):
# tcpdump -leni vnet0 icmp
tcpdump: WARNING: vnet0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
Я также следил за советами в эта почта и установите 0 в / proc / sys / net / bridge / bridge-nf- *, но это не помогло.
В дополнение к очистке фильтров iptables я также включил TRACE в iptables, который показал, что эти пакеты никогда не попадают в iptables.
Есть ли другие причины, по которым мост Linux не пересылает пакеты между портами?
Нашел ответ! Ethernet-мост Linux обращается к ebtables, чтобы решить, какие пакеты пересылать, а какие отбрасывать. Промывка ebtables решила мою проблему.