Короткий ответ: как работает автоматическое переключение маршрутизатора
Отказоустойчивый маршрутизатор на Linux строится на двух узлах, которые разделяют один виртуальный IP-адрес. Клиенты используют этот адрес как шлюз по умолчанию. Активный узел отвечает на виртуальный IP и пересылает трафик. Резервный узел постоянно проверяет доступность активного и при его отказе перехватывает управление. Переключение происходит автоматически за счет протокола VRRP, реализованного в демоне keepalived. Протокол VRRP выбирает активный узел на основе приоритетов и периодических объявлений. При пропадании объявлений от активного узла резервный повышает свой приоритет и становится новым владельцем виртуального IP.
VRRP решает проблему обнаружения отказа узла, но не гарантирует работоспособность всех сетевых функций. Если на активном маршрутизаторе вышел из строя внешний канал, но сам узел продолжает работать, VRRP не переключит роль. Для контроля состояния каналов и маршрутов нужны дополнительные проверки. Их настраивают через скрипты отслеживания в keepalived. Скрипты проверяют доступность шлюзов, наличие маршрутов и работу критичных сервисов. При неудачной проверке приоритет узла снижается, и резервный узел перехватывает виртуальный IP.
Полноценная отказоустойчивая схема включает резервирование физических интерфейсов, нескольких провайдеров и синхронизацию конфигурации между узлами. Только в этом случае переключение роли не приведет к потере трафика из-за несовпадения правил firewall, NAT или таблиц маршрутизации. Важно заранее продумать, какие состояния должны быть одинаковыми на обоих узлах, а какие могут отличаться. Например, IP-адреса физических интерфейсов разные, а правила трансляции адресов должны совпадать.
Что именно переключается при отказе
При отказе активного узла VRRP передает резервному узлу право владения виртуальным IP-адресом. Это означает, что резервный узел начинает отвечать на ARP-запросы для этого адреса и принимать пакеты, адресованные шлюзу. Физические IP-адреса узлов не меняются. Маршруты, настроенные статически или через демон маршрутизации, должны уже существовать на резервном узле. Если использовалась трансляция адресов (NAT), то таблица соединений (conntrack) на резервном узле пуста. Существующие TCP-сессии, проходящие через NAT, будут разорваны, если не настроена синхронизация conntrack между узлами.
Автоматически переключаются только виртуальный IP и связанная с ним роль VRRP. Все остальные компоненты должны быть заранее подготовлены на обоих узлах. Это касается правил межсетевого экрана, таблиц маршрутизации, настроек DNS и NTP, а также конфигурации сервисов, которые обеспечивают маршрутизацию. Если эти компоненты различаются, после переключения трафик может пойти неверным путем или быть заблокирован.
Какие отказы должна переживать схема
Отказоустойчивая схема должна справляться с несколькими типами отказов. Отказ основного узла, например, из-за сбоя питания или зависания операционной системы, покрывается VRRP. Отказ сетевого интерфейса на активном узле может быть обнаружен через отслеживание состояния интерфейса. Отказ локального коммутатора, к которому подключен активный узел, может привести к потере связи с резервным узлом и клиентами. В этом случае необходимо резервирование коммутаторов или подключение узлов к разным коммутаторам. Отказ внешнего шлюза или провайдера обнаруживается проверками доступности внешних адресов. Отказ сервиса маршрутизации, например, остановка FRRouting, требует проверки состояния процесса. Отказ отдельного маршрута сложнее обнаружить, но можно использовать скрипты, которые проверяют наличие маршрута в таблице.
VRRP покрывает только отказ узла. Для остальных отказов нужны дополнительные механизмы: bonding для интерфейсов, policy routing для нескольких провайдеров, динамическая маршрутизация для сложных сетей и скрипты мониторинга для проверки работоспособности.
Архитектура отказоустойчивого Linux-маршрутизатора
Рекомендуемая топология включает два Linux-маршрутизатора, подключенных к одному внутреннему L2-сегменту. Оба узла имеют физические IP-адреса в этой сети. Клиенты используют виртуальный IP-адрес как шлюз по умолчанию. Внешние подключения могут быть разными: один или несколько провайдеров, выделенные интерфейсы. На каждом узле должны быть настроены одинаковые правила маршрутизации, firewall и NAT. Конфигурация keepalived различается только приоритетом и, возможно, параметрами отслеживания.
Для устранения единой точки отказа следует подключать узлы к разным коммутаторам, если это возможно. Внешние каналы также должны быть независимыми. Если оба маршрутизатора используют один и тот же коммутатор или один канал провайдера, отказ этого элемента приведет к полной недоступности сети, несмотря на резервирование узлов.
Роли узлов: MASTER и BACKUP
В VRRP один узел находится в состоянии MASTER, другой в BACKUP. MASTER владеет виртуальным IP и отправляет объявления. BACKUP слушает объявления и готов перехватить роль. Приоритет определяет, какой узел станет MASTER при старте. Узел с более высоким приоритетом выигрывает выборы. Если приоритеты равны, выигрывает узел с большим IP-адресом интерфейса. Состояние узла может меняться динамически: при отказе MASTER, BACKUP становится новым MASTER. При восстановлении старого MASTER, если включен preemption, он может вернуть себе роль.
Роль не должна быть жестко привязана к имени сервера. Важно, чтобы резервный узел был полностью готов к работе в любой момент. Это означает, что все необходимые сервисы должны быть запущены, конфигурация синхронизирована, а проверки состояния должны проходить успешно. Иначе переключение приведет к недоступности сети.
Минимальная и расширенная топологии
Минимальная топология: два узла, один внешний канал, один внутренний коммутатор. Это устраняет отказ одного узла, но не защищает от отказа коммутатора или внешнего канала. Расширенная топология добавляет резервирование внешних каналов, например, два провайдера с настройкой policy routing. Еще один уровень - резервирование коммутаторов и использование bonding для сетевых интерфейсов. В сложных сетях применяется динамическая маршрутизация для автоматического перестроения маршрутов при изменении топологии.
Выбор топологии зависит от требований к доступности и бюджета. Для большинства офисных сетей достаточно двух узлов с резервированием внешнего канала. Для критичных сервисов следует рассмотреть полное резервирование всех компонентов.
Подготовка Linux-узлов перед настройкой VRRP
Перед установкой keepalived необходимо убедиться, что оба узла корректно настроены как маршрутизаторы. Проверьте, что IP-адреса интерфейсов не конфликтуют, IP forwarding включен, а правила firewall не блокируют VRRP-трафик. Различия в базовой конфигурации могут привести к некорректному переключению или недоступности сети.
Зафиксируйте версии используемого программного обеспечения: ядро Linux, keepalived, FRRouting или другие демоны маршрутизации. Синтаксис и поведение некоторых параметров зависят от версии. Рекомендуется использовать одинаковые версии на обоих узлах.
Проверка сетевых интерфейсов и IP-адресов
Проверьте имена интерфейсов и их состояние командой ip link. Убедитесь, что интерфейсы подняты и имеют корректные MTU. Проверьте IP-адреса командой ip addr. Физические адреса узлов должны быть разными, виртуальный IP не должен совпадать с ними. Проверьте таблицу маршрутизации командой ip route. Убедитесь, что маршрут по умолчанию настроен через правильный шлюз.
Имена интерфейсов должны быть одинаковыми на обоих узлах, если конфигурация keepalived ссылается на них. В современных дистрибутивах имена могут быть предсказуемыми (например, enp0s3), но лучше зафиксировать их через udev или systemd.link.
Включение маршрутизации и базовые параметры ядра
Для пересылки пакетов между интерфейсами необходимо включить IP forwarding. Проверьте значение параметра net.ipv4.ip_forward. Оно должно быть равно 1. Установите его в /etc/sysctl.conf и примените. Также проверьте параметр net.ipv4.conf.all.rp_filter. В некоторых схемах с асимметричной маршрутизацией его нужно отключить или настроить в режиме loose. Обратите внимание на параметры ARP: net.ipv4.conf.all.arp_ignore и arp_announce. Для корректной работы VRRP они обычно не требуют изменений, но в сложных схемах могут влиять.
Firewall и разрешение VRRP-трафика
VRRP использует multicast-адрес 224.0.0.18 и протокол IP 112. Убедитесь, что правила nftables или iptables на внутреннем интерфейсе разрешают этот трафик. В nftables можно добавить правило: ip protocol vrrp accept. В iptables: iptables -A INPUT -p vrrp -j ACCEPT. Также разрешите трафик от резервного узла к активному и обратно. Проверьте, что multicast не блокируется на коммутаторе. Некоторые коммутаторы требуют настройки IGMP snooping для VRRP.
Настройка VRRP через keepalived
Keepalived реализует VRRP и предоставляет механизмы отслеживания состояния. Установите keepalived из репозитория вашего дистрибутива. Основной конфигурационный файл: /etc/keepalived/keepalived.conf. Базовая конфигурация включает определение виртуального маршрутизатора с параметрами: state, interface, virtual_router_id, priority, advert_int и список виртуальных IP.
Базовая конфигурация MASTER и BACKUP
Пример для MASTER:
vrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 100
advert_int 1
authentication {
auth_type PASS
auth_pass secret
}
virtual_ipaddress {
192.168.1.1/24
}
}Для BACKUP меняются state на BACKUP и priority на 90. virtual_router_id должен быть одинаковым на обоих узлах. Интерфейс должен быть тем, который подключен к внутренней сети. Виртуальный IP должен принадлежать той же подсети, что и физические адреса узлов. Параметр advert_int задает интервал отправки объявлений в секундах. Аутентификация необязательна, но рекомендуется для предотвращения случайных конфликтов.
Приоритет, preemption и возврат роли
Приоритет определяет, кто станет MASTER. Узел с более высоким приоритетом выигрывает. Preemption позволяет узлу с более высоким приоритетом забрать роль у текущего MASTER. Если preemption отключен, узел с более высоким приоритетом не будет перехватывать роль, пока текущий MASTER работает. Это полезно, чтобы избежать частых переключений при нестабильном канале. Однако при восстановлении основного узла он не вернет себе роль автоматически. Нужно решить, что важнее: стабильность или предсказуемость возврата.
Рекомендуется возвращать узел в кластер после полной проверки его состояния, а не сразу после запуска keepalived. Можно временно установить более низкий приоритет, проверить работу, затем повысить приоритет и разрешить preemption.
Проверка перехода виртуального IP
После настройки проверьте состояние keepalived командой systemctl status keepalived. На активном узле виртуальный IP должен быть добавлен к интерфейсу: ip addr show eth0 должен показывать 192.168.1.1. На резервном узле этого адреса быть не должно. Для теста переключения остановите keepalived на активном узле или отключите интерфейс. Резервный узел должен стать MASTER и добавить виртуальный IP. Проверьте доступность виртуального IP с клиента. Убедитесь, что ARP-кэш клиента обновился. Обычно задержка составляет несколько секунд.
Резервирование сетевых каналов и маршрутов
Резервирование каналов необходимо для устранения отказов, не связанных с узлом. Если внешний канал активного маршрутизатора выходит из строя, но узел продолжает работать, VRRP не переключит роль. Нужно либо настроить отслеживание состояния канала и снижать приоритет, либо организовать резервирование на уровне маршрутизации.
Резервирование интерфейсов через bonding
Bonding объединяет несколько физических интерфейсов в один логический. При отказе одного физического линка трафик продолжает идти через другой. Режимы bonding различаются по требованиям к поддержке со стороны коммутатора. Режим active-backup не требует специальной настройки коммутатора и обеспечивает отказоустойчивость. Режимы balance-rr, balance-xor, 802.3ad требуют поддержки LACP или других протоколов. Для маршрутизатора обычно достаточно active-backup. Настройте bonding через /etc/network/interfaces или systemd-networkd. Проверьте состояние slave-интерфейсов и переключение при отключении одного из них.
Два провайдера и policy routing
При наличии двух внешних каналов нужно настроить policy routing, чтобы трафик, пришедший через один канал, возвращался через него же. Иначе возможна асимметричная маршрутизация и потеря пакетов. Создайте отдельные таблицы маршрутизации для каждого провайдера. Добавьте правила ip rule, которые направляют трафик в нужную таблицу на основе исходного адреса или метки. Настройте маршруты по умолчанию в каждой таблице. Для автоматического переключения между провайдерами используйте скрипты, которые проверяют доступность внешних адресов и меняют маршруты или приоритеты.
Синхронизация динамических маршрутов
В сложных сетях используйте динамическую маршрутизацию, например, OSPF или BGP через FRRouting. Это позволяет автоматически обновлять таблицы маршрутизации на обоих узлах при изменении топологии. Убедитесь, что конфигурация FRRouting синхронизирована. Проверяйте не только наличие маршрута, но и его активность, next hop и метрику. Динамическая маршрутизация дополняет VRRP, но не заменяет его: VRRP отвечает за виртуальный IP, а динамическая маршрутизация за маршруты.
Контроль состояния узлов, каналов и маршрутов
Для автоматического переключения при отказах, не связанных с полным отказом узла, используйте механизмы отслеживания в keepalived. Это track_interface для отслеживания состояния интерфейсов и track_script для выполнения пользовательских скриптов. Скрипты могут проверять доступность шлюзов, наличие маршрутов, состояние сервисов. Результат проверки влияет на приоритет узла. Если проверка не проходит, приоритет снижается, и резервный узел перехватывает роль.
Проверка интерфейса и локального шлюза
Отслеживание интерфейса можно настроить через track_interface. Если интерфейс переходит в состояние down, приоритет узла снижается на заданное значение. Однако поднятый интерфейс не гарантирует доступность шлюза. Поэтому добавьте скрипт, который проверяет доступность локального шлюза через ping. Скрипт должен быть коротким и не создавать ложных срабатываний. Используйте несколько проверок с таймаутами.
Проверка внешнего канала и маршрута по умолчанию
Проверка внешнего канала может выполняться через ping до надежного внешнего адреса, например, 8.8.8.8 или адреса DNS-сервера провайдера. Важно выполнять проверку с привязкой к нужному интерфейсу или таблице маршрутизации, чтобы убедиться, что трафик действительно пойдет через этот канал. Используйте несколько контрольных точек для избежания ложного срабатывания при недоступности одного адреса. Настройте таймауты и количество повторов так, чтобы кратковременные потери не вызывали переключение.
Проверка сервиса маршрутизации
Если используется FRRouting или другой демон маршрутизации, проверяйте его состояние. Скрипт может проверять, запущен ли процесс, и наличие ожидаемых маршрутов в таблице. Например, можно проверять наличие маршрута по умолчанию или специфического маршрута. Если маршрут отсутствует, приоритет снижается. Также можно проверять, что демон отвечает на команды, например, через vtysh.
Что синхронизировать между маршрутизаторами
Синхронизация конфигурации критична для корректного переключения. Если резервный узел имеет устаревшие правила firewall или другие маршруты, после переключения трафик может быть заблокирован или пойти неверным путем. Составьте список файлов и параметров, которые должны быть одинаковыми. Используйте систему контроля версий, например, Git, для хранения конфигурации. Регулярно сравнивайте файлы на узлах.
Конфигурация firewall, NAT и forwarding
Правила nftables или iptables должны быть идентичными на обоих узлах. Это касается правил фильтрации, трансляции адресов (SNAT, DNAT), зон и порядка правил. Убедитесь, что имена интерфейсов в правилах совпадают. Если используются разные имена, правила могут не сработать. Проверьте, что IP forwarding включен на обоих узлах. Любое различие может привести к недоступности сети после переключения.
Динамическое состояние соединений и conntrack
Таблица conntrack хранит информацию о текущих соединениях, проходящих через NAT. При переключении на резервный узел эта таблица пуста, поэтому существующие соединения будут разорваны. Для сохранения соединений можно использовать синхронизацию conntrack с помощью conntrackd. Однако это требует дополнительной настройки и не всегда работает корректно. Оцените, насколько критично сохранение сессий. Для многих приложений допустим разрыв и повторное подключение. Если требуется сохранение, настройте conntrackd и проверьте его работу.
Контроль расхождений конфигурации
Регулярно сравнивайте конфигурационные файлы на узлах. Можно использовать diff или специализированные инструменты. Храните конфигурацию в Git и разворачивайте изменения на оба узла. Проверяйте не только тексты файлов, но и фактические состояния: IP-адреса, маршруты, правила firewall, версии пакетов. Автоматизируйте проверки с помощью скриптов. Это позволит обнаружить расхождения до того, как они приведут к проблемам.
Предотвращение split-brain и конфликтов виртуального IP
Split-brain возникает, когда оба узла считают себя активными и одновременно владеют виртуальным IP. Это приводит к конфликту ARP, потере пакетов и двойному NAT. Причины: потеря VRRP-объявлений между узлами при сохранении доступа к клиентам, неправильная фильтрация multicast, разрыв внутреннего L2-сегмента, ошибки при ручном запуске сервисов и несогласованные приоритеты.
Как обнаружить двух активных владельцев VRRP
Проверьте состояние keepalived на обоих узлах. Если оба показывают MASTER, это split-brain. Проверьте наличие виртуального IP на обоих узлах командой ip addr. Захватите VRRP-пакеты с помощью tcpdump: tcpdump -i eth0 -n vrrp. Если оба узла отправляют объявления, это подтверждает split-brain. Проверьте ARP-таблицы клиентов и MAC-таблицу коммутатора. Сопоставьте время событий в логах.
Меры против одновременной активации узлов
Настройте фильтрацию VRRP-трафика так, чтобы узлы могли общаться только между собой. Используйте выделенный канал для VRRP-объявлений, если возможно. Настройте track_script для проверки связи между узлами. При потере связи узел может снизить приоритет или перейти в состояние FAULT. Рассмотрите возможность fencing: внешний механизм, который отключает узел при подозрении на split-brain. Это может быть управление питанием через IPMI или другие методы. Не используйте quorum без четкого понимания его реализации.
Проверка ARP и MAC после переключения
После переключения виртуального IP новый MASTER должен отправить gratuitous ARP, чтобы обновить ARP-кэши клиентов и коммутаторов. Проверьте, что клиенты получают новый MAC-адрес для виртуального IP. Если старый MAC-адрес застрял в кэше, трафик может идти на старый узел. Очистите ARP-кэш на клиентах или настройте более агрессивные gratuitous ARP. Проверьте настройки коммутатора: некоторые коммутаторы могут блокировать обновление MAC-адресов.
Тестирование failover и возврат основного узла
Тестирование отказоустойчивости необходимо для уверенности в работе схемы. Проведите серию тестов, имитирующих различные отказы. Зафиксируйте время переключения, потери пакетов и поведение приложений. После тестов верните основной узел в кластер по безопасной процедуре.
Сценарии аварийного переключения
Проверьте следующие сценарии: остановка keepalived на активном узле, отключение внутреннего интерфейса, отключение внешнего интерфейса, недоступность провайдера, удаление маршрута по умолчанию, остановка FRRouting, потеря связи между узлами. Для каждого сценария проверьте, что резервный узел становится MASTER и трафик продолжает проходить. Используйте ping, traceroute, curl, ip route, ss, tcpdump и логи для диагностики.
Критерии успешного failover
Определите допустимые значения до тестирования. Время обнаружения отказа, время владения VIP новым узлом, число потерянных пакетов, доступность новых соединений, судьба существующих NAT-сессий, отсутствие split-brain. Обычно время переключения составляет 1-3 секунды при advert_int=1. Потери пакетов могут быть до нескольких секунд. Существующие NAT-сессии обычно разрываются, если не настроена синхронизация conntrack.
Безопасный возврат MASTER в кластер
После восстановления основного узла не запускайте keepalived сразу. Сначала проверьте версии ПО, интерфейсы, firewall, маршруты, health check и синхронизацию состояния. Запустите keepalived с низким приоритетом, чтобы узел стал BACKUP. Убедитесь, что он получает объявления от текущего MASTER и не пытается перехватить роль. Затем постепенно повышайте приоритет и проверяйте стабильность. Если включен preemption, узел может автоматически забрать роль после достижения более высокого приоритета. Убедитесь, что это не вызовет новых проблем. Проверьте ARP, новые соединения и логи на обоих узлах.
Диагностика причин некорректного автоматического переключения
Если failover не срабатывает или происходит слишком часто, ищите причину по уровням: VRRP, firewall, интерфейсы, health check, маршруты, ARP, NAT и конфигурационный drift. Для каждого симптома проверяйте соответствующие команды и логи.
Узлы не видят VRRP-объявления
Проверьте, что оба узла используют одинаковый virtual_router_id. Проверьте, что интерфейс, указанный в конфигурации, подключен к нужной сети. Захватите трафик tcpdump: tcpdump -i eth0 -n vrrp. Если пакеты не приходят, проверьте firewall: разрешите протокол vrrp. Проверьте multicast на коммутаторе: возможно, IGMP snooping блокирует трафик. Проверьте, что узлы находятся в одном L2-сегменте.
Переключение происходит слишком часто
Частые переключения (flapping) могут быть вызваны нестабильным каналом, слишком агрессивными таймаутами в скриптах, одиночными потерями ICMP, некорректным track_script. Увеличьте таймауты и количество повторов в скриптах. Настройте задержку перед снижением приоритета. Проверьте физическое состояние каналов. Разделите кратковременные ошибки от подтвержденного отказа.
VIP перешел, но трафик не работает
Сравните таблицы маршрутизации на узлах: ip route. Проверьте правила policy routing: ip rule. Проверьте firewall: nft list ruleset. Проверьте NAT: nft list table nat. Проверьте forwarding: sysctl net.ipv4.ip_forward. Проверьте доступность внешнего шлюза. Проверьте обратный маршрут. Захватите трафик на входном и выходном интерфейсах tcpdump. Проверьте наличие нужного динамического маршрута.
После восстановления основной узел забирает роль преждевременно
Проверьте порядок запуска сервисов. Убедитесь, что все необходимые сервисы запущены до запуска keepalived. Проверьте условия track_script: возможно, проверки проходят, но не полностью. Добавьте задержку перед возвратом роли. Проверьте состояние conntrack и синхронизацию конфигурации. Используйте контролируемый возврат роли после успешных проверок.
Итоговый чек-лист перед вводом в эксплуатацию
Перед вводом схемы в эксплуатацию выполните следующие проверки.
Что проверить на каждом узле
- Версии ПО одинаковы.
- Интерфейсы подняты, IP-адреса корректны.
- IP forwarding включен.
- Правила firewall разрешают VRRP и необходимый трафик.
- Keepalived запущен и состояние соответствует ожидаемому.
- Сервис маршрутизации работает.
- Health check скрипты выполняются успешно.
- Конфигурация синхронизирована.
Что проверить с точки зрения клиента
- Виртуальный шлюз доступен.
- Новые исходящие соединения устанавливаются.
- Доступ к внутренним ресурсам работает.
- DNS разрешается.
- Входящие публикации доступны.
- Поведение существующих сессий при переключении соответствует ожиданиям.
Дополнительные материалы по теме: Готовые конфигурации для построения высокодоступной сети, Настройка policy routing в Linux, Программный маршрутизатор на Linux.