SystemdDoctor
служба не работает отказоустойчивость сеть

keepalived: оба узла считают себя главным

Оба узла поднимают общий адрес, когда не видят объявлений друг друга. Каждый считает соседа умершим и берёт адрес себе. Сеть получает два ответа на один адрес, соединения рвутся непредсказуемо. Причина почти всегда в блокировке служебного трафика, а не в настройках приоритетов.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Служебный трафик VRRP блокируется

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

  2. Разные идентификаторы группы или пароли

    Узлы с разными идентификаторами группы не считают друг друга участниками одной пары, даже если трафик проходит.

  3. Служба запускается раньше готовности сети

    Если адрес интерфейса ещё не назначен, служба не может отправлять объявления и уходит в главное состояние по умолчанию.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Переходы между состояниями: видно, когда узел взял адрес.

sudo journalctl -u keepalived -n 30 --no-pager

Поднят ли общий адрес на этом узле прямо сейчас.

ip -brief addr | grep -F "$(grep -A3 virtual_ipaddress /etc/keepalived/keepalived.conf | grep -oE '[0-9.]+/[0-9]+' | head -1)" 2>/dev/null || ip -brief addr

Идут ли объявления VRRP — самая прямая проверка.

sudo tcpdump -ni any proto 112 -c 5 2>/dev/null

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Служебный трафик VRRP блокируется
Почему происходит
Объявления идут отдельным протоколом на групповой адрес. Брандмауэр по умолчанию его не пропускает, и узлы друг друга не видят.
Как проверить
Посмотрите состояние узлов и правила брандмауэра. 
sudo journalctl -u keepalived -n 20 --no-pager | grep -iE "MASTER|BACKUP"
sudo nft list ruleset 2>/dev/null | grep -iE "vrrp|224.0.0.18" || sudo iptables -S | grep -iE "vrrp|224.0.0.18"
Как исправить
Разрешите протокол VRRP между узлами и трафик на его групповой адрес. Без этого любые настройки приоритетов бессмысленны.
2. Разные идентификаторы группы или пароли
Почему происходит
Узлы с разными идентификаторами группы не считают друг друга участниками одной пары, даже если трафик проходит.
Как проверить
Сравните идентификаторы и аутентификацию на обоих узлах. 
grep -iE "virtual_router_id|auth_pass|priority" /etc/keepalived/keepalived.conf
Как исправить
Приведите идентификатор группы и пароль к одинаковым значениям на обоих узлах, а приоритеты сделайте разными.
3. Служба запускается раньше готовности сети
Почему происходит
Если адрес интерфейса ещё не назначен, служба не может отправлять объявления и уходит в главное состояние по умолчанию.
Как проверить
Посмотрите порядок запуска и время назначения адресов. 
systemctl show keepalived -p After -p Wants
journalctl -b --no-pager | grep -iE "keepalived|network-online" | head -10
Как исправить
Добавьте ожидание готовности сети в unit-файл службы и убедитесь, что служба ожидания сети включена. 
[Unit]
After=network-online.target
Wants=network-online.target

Пример вывода

Оба узла перешли в главное состояние. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

keepalived[1300]: (VI_1) Entering MASTER STATE
keepalived[1300]: (VI_1) setting VIPs.
keepalived[1300]: Sending gratuitous ARP on eth0 for 192.0.2.50
# на втором узле в это же время:
keepalived[1290]: (VI_1) Entering MASTER STATE

Связанные ошибки

Источники

  • Документация keepalived документация программы
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено блокировкой протокола VRRP между двумя узлами.     собственная проверка, systemd 255
    сверено 15 сентября 2026