☰

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

tag-icon • tag-icon networking router home-networking gateway
Избыточность сети относительно маршрута/шлюза по умолчанию

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

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

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

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

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

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

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

решение1

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

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

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

Если главный маршрутизатор выходит из строя, это автоматически приводит к тому, что вторичный маршрутизатор берет на себя управление — главный и вторичный маршрутизаторы обмениваются пакетами «hello», и как только вторичный маршрутизатор перестает получать сигналы от главного маршрутизатора, он берет на себя управление 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 в случае неудачи.

Связанный контент