Избыточность сети относительно маршрута / шлюза по умолчанию

Question

У меня есть два интернет-провайдера (основной - кабель 100Mi на 24.xxx [быстрый, но ненадежный], а резервная копия - 1.5Mi DSL на 70.xxx) для обеспечения избыточности и надежности. У меня есть выделенные межсетевые экраны Red Hat Linux, подключенные к каждой службе, и они питаются от ИБП. Сторона LAN каждого брандмауэра / маршрутизатора подключается к 24-портовому коммутатору с остальными устройствами в моей домашней сети, включая две точки доступа Wi-Fi с одинаковым SSID на разных каналах в каждом конце дома.

Мой вопрос состоит из двух частей;

1) Как настроить клиенты Windows/iOS/android/linux/solaris для переключения на второй маршрутизатор при сбое службы на первичном сервере (что, по-видимому, происходит несколько раз в месяц, почти всегда в субботу утром)?

2) Как я могу дать сигнал клиентам вернуться к использованию основного маршрутизатора при восстановлении службы?

Можно ли просто перечислить оба маршрутизатора при обслуживании DHCP, а затем позволить клиенту разобраться, что ему нужно? Похоже, что это может работать для части 1), но ничего не делает для части 2), если я не вручную / фальшиво не установлю соединение с резервной копией, когда основной сервер вернется в оперативный режим.

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

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

Answer 1

Есть много способов кожи этого кота, но keepalived могут быть вариантом.

keepalived - это реализация VRRP , что означает, что вы можете определить "виртуальный" ip, который принадлежит одному или другому маршрутизатору. Обычно вы назначаете одного в качестве основного, а второй - в качестве дополнительного. Если мастер становится недоступным, вторичный сервер становится владельцем IP-адреса.

В вашем сценарии это будет IP-адрес шлюза ваших клиентов. Таким образом, они всегда общаются с одним и тем же IP-адресом, и это либо идет к первому, либо ко второму маршрутизатору, в зависимости от того, какой из них является главным.

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

Тем не менее, вам нужно больше контролировать ссылку и позволить мастеру перевести себя в недоступный режим - вы можете сделать это с помощью "скриптов отслеживания".

Например, вот конфиг для мастера:

vrrp_instance RouterVRRP {
  state MASTER
  interface eth0
  virtual_router_id 50
  priority 200
  advert_int 1
  virtual_ipaddress {
    10.10.10.100/32 dev eth0
  }
  track_script {
    check_google
  }
}

Тогда определение скрипта трека:

vrrp_script check_google {
  script       "/scripts/pinggoogle.sh"
  interval 3   # check every 3 seconds
  fall 3       # require 3 fails for down
  rise 2       # require 2 successes back up
}

Сценарий будет пинговать Google и вернуть 0 для всех хорошо, и 1 для сбоя.