Назад | Перейти на главную страницу

Мост Linux не отвечает на пакеты arp

Я пытаюсь настроить тестовый сценарий для мостов Linux, для которого мне нужен полный виртуальный стек IP. По сути, я хотел бы смоделировать сеть между виртуальной машиной (или контейнером) и ее хостом, только без виртуальной машины, то есть уровня виртуализации.

Принимающая сторона - мост (br0) с настроенным IP-адресом (gw по умолчанию моделируемой виртуальной машины), как показано в других рабочих настройках KVM. Я попытался смоделировать соединение со стороны виртуальной машины следующим образом:

используя tap интерфейс (подключение OpenVPN к другому серверу, пинг оттуда)
а veth пара, один конец которого настроен с IP-адресом, а другой подключен к мосту
вторичный bridge с IP-адресом, подключенным к основному мосту через veth пара

Ни в одной из этих настроек мне не удалось пропинговать мост хоста (gw по умолчанию для виртуальных машин). Во всех настройках проблема была одна: интерфейс моста не отвечал на пакеты ARP.

комплектация (местный вет):

    +-----+
    | br0 |
    |     | +------+    +------+
    |     ==| vip1 |<-->| vip2 |
    +-----| +------+    +------+

    br0:  type=bridge, UP, 172.16.1.1/24
    vip1: type=veth, UP
    vip2: type=veth peer, UP, 172.16.1.2/24

    # brctl addbr br0
    # ifconfig br0 172.16.1.1 netmask 255.255.255.0 up
    # ip link add vip1 type veth peer name vip2
    # ifconfig vip2 172.16.1.2 netmask 255.255.255.0 up
    # brctl addif br0 vip1
    # ifconfig vip1 up

Теперь я пытаюсь ping то br0 из vip2:

    # [root@host ~]# ping -I vip2 172.16.1.1
    # PING 172.16.1.1 (172.16.1.1) from 172.16.1.2 vip2: 56(84) bytes of data.
    # ^C
    # --- 172.16.1.1 ping statistics ---
    # 2 packets transmitted, 0 received, 100% packet loss, time 1493ms

tcpdump на мосту:

    # [root@host ~]# tcpdump -i br0
    # tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    # listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
    # 23:14:02.367624 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # 23:14:03.367657 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # 23:14:04.367345 ARP, Request who-has 172.16.1.1 tell 172.16.1.2, length 28
    # ...

Что довольно странно, поскольку br0 интерфейс, на который приходят эти пакеты, UP и должен отвечать на запросы ARP.

    # [root@host ~]# ifconfig br0
    # br0       Link encap:Ethernet  HWaddr F6:F3:5A:A7:A2:5B
    #           inet addr:172.16.1.1  Bcast:172.16.1.255  Mask:255.255.255.0
    #           inet6 addr: fe80::f4f3:5aff:fea7:a25b/64 Scope:Link
    #           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    #           RX packets:53 errors:0 dropped:0 overruns:0 frame:0
    #           TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
    #           collisions:0 txqueuelen:0
    #           RX bytes:1580 (1.5 KiB)  TX bytes:360 (360.0 b)

Я пробовал:

Интерфейс связи OpenVPN (пинг с другого хоста через OpenVPN, чтобы пакет приходил на интерфейс перехода по сравнению с интерфейсом veth)
другой мост (br1), используя veth пара для соединения обоих мостов
установка net.ipv4.conf.all.arp_filter и другие, но, кажется, ничего не влияет
iptables и ebtables пустые и все ПРИНИМАЮ.

Поэтому я изо всех сил пытаюсь понять, почему это не работает, и в чем разница между решениями для контейнеров или виртуализации. Любая помощь высоко ценится!

Спасибо!