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

Почему / как keepalived предотвращает локальный доступ к виртуальному ip?

Я использую контейнерный (с подман) прокси squid на порт 3128 на паре серверов, используя оставайся живым чтобы поделиться виртуальным IP-адресом между ними. Я заметил странное поведение, которое не могу понять.

VIP это 192.168.1.201. Запускаю сквид вот так:

podman run -p 192.168.1.201:3128:3128 squid

В squid образ создается локально, но на самом деле просто запускается squid --foreground с в основном стандартной конфигурацией (как в Alpine linux).

Я включил нелокальные привязки, поэтому это отлично работает независимо от того, активен ли vip на данном узле.

Если я остановлюсь keepalived в обеих системах и вручную назначить адрес одному из узлов ...

$ ip addr add 192.168.1.201/32 dev eth0.100
$ ip addr show eth0.100
3: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1c:1b:0d:fd:2e:44 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.53/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0.100
       valid_lft 6770sec preferred_lft 6770sec
    inet 192.168.1.201/32 scope global eth0.100
       valid_lft forever preferred_lft forever
    inet6 fe80::e046:ccb8:5063:f53b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

... тогда я могу войти в этот узел и запустить:

curl 192.168.1.201:3128

Это работает нормально, и я получаю ожидаемый ответ от squid. Но если я удалю vip, начни keepalived, и дождитесь, пока он назначит vip, тогда та же команда зависнет. Конфигурация интерфейса выглядит идентичной:

$ ip addr show eth0.100
3: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 1c:1b:0d:fd:2e:44 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.53/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0.100
       valid_lft 6743sec preferred_lft 6743sec
    inet 192.168.1.201/32 scope global eth0.100
       valid_lft forever preferred_lft forever
    inet6 fe80::e046:ccb8:5063:f53b/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Доступ к vip из любого другого места работает нормально; но доступ к vip от узла, который в настоящее время "владеет" vip, не работает.

Я также посмотрел конфигурацию маршрутизации (ip route) и iptables конфигурация (iptables-save), и оба выглядят одинаково независимо от того, назначаю я адрес вручную или позволяю keepalived сделай это.

Что keepalived это вызывает такое поведение?