keepalived нет маршрута к хосту, проблема с брандмауэром?

У меня простая конфигурация из двух серверов для keepalived. Выбор главного/резервного сервера работает нормально, но я не могу подключиться к VIP с резервного сервера. Когда я пытаюсь подключиться, на главном сервере я вижу ARP-запросы от резервного сервера и ответы от главного; на резервном сервере я вижу только запросы (т.е. я не вижу ARP-ответов от главного).

Конфигурация keepalived.conf главного сервера:

vrrp_script haproxy-check {
    script "/usr/bin/pgrep python"
    interval 5
}
 
vrrp_instance haproxy-vip {
    state MASTER
    priority 101
    interface eth0
    virtual_router_id 47
    advert_int 3
 
    unicast_src_ip 192.168.122.4
    unicast_peer {
        192.168.122.9
    }
 
    virtual_ipaddress {
        192.168.122.250
    }
 
    track_script {
        haproxy-check weight 20
    }
}

Конфигурация keepalived.conf резервного сервера:

vrrp_script haproxy-check {
    script "/usr/bin/pgrep python"
    interval 5
}

vrrp_instance haproxy-vip {
    state BACKUP
    priority 99
    interface eth0
    virtual_router_id 47
    advert_int 3

    unicast_src_ip 192.168.122.9
    unicast_peer {
        192.168.122.4
    }

    virtual_ipaddress {
        192.168.122.250
    }

    track_script {
        haproxy-check weight 20
    }
}

ip addr на главном сервере:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1458 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:9e:e8:18 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.4/24 brd 192.168.122.255 scope global noprefixroute dynamic eth0
       valid_lft 55567sec preferred_lft 55567sec
    inet 192.168.122.250/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::571a:df5f:930c:2b57/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

А на резервном:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1458 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:2e:59:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.9/24 brd 192.168.122.255 scope global noprefixroute dynamic eth0
       valid_lft 79982sec preferred_lft 79982sec
    inet6 fe80::f816:3eff:fe2e:593d/64 scope link 
       valid_lft forever preferred_lft forever

tcpdump с главного сервера:

# tcpdump -nni eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:06.299398 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:06.299435 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:07.298939 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:07.298985 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:08.300920 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:08.300954 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:09.303039 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:09.303062 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28

А с резервного:

# tcpdump -nni eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:39.430367 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:40.431810 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:41.433847 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:42.435979 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:43.437814 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28

Я не верю, что это проблема с файрволом (iptables -L | grep -i arp ничего не показывает), есть ли настройка ядра, которая может вызывать проблему? Есть ли какие-то предложения по отладке?

ОС – Centos 7, версия keepalived – 2.1.5.

Я только что узнал о этом вопросе, так как он был упомянут в проблеме, поднятой кем-то другим на GitHub. Я не помню, чтобы видел этот вопрос на keepalived-users, что, вероятно, лучший источник для публикации вопросов, связанных с keepalived.

Часть VRRP конфигурации keepalived настраивает IP-адреса (а в некоторых случаях (но не в этой конфигурации) настраивает правила nftables или iptables). Как только keepalived выполнил это, ядро обрабатывает передачу и получение любых пакетов.

Я не вижу никаких проблем с конфигурацией keepalived.

Ваша проблема, похоже, связана с тем, что ARP-ответы не принимаются на резервной системе, и это выходит за рамки keepalived, поэтому вам нужно будет исследовать в другом месте, чтобы выяснить, почему ответы не принимаются.

У меня была очень-очень похожая проблема с несколькими VIP на одном VLAN на одном сервере:

https://github.com/acassen/keepalived/issues/1876

Как указано в doc/source/software_design.rst

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 1

решает проблему с IP-адресом назначения.