Network Manager: аварийное переключение между двумя шлюзами по умолчанию
Может ли Network Manager проверить, может ли шлюз по умолчанию маршрутизировать пакеты в Интернет?
У меня два интерфейса, оба обеспечивают маршрут к интернету.
Когда я отключаю кабель от любого из них, шлюз по умолчанию обновляется, и мое интернет-соединение работает. Но если текущий предпочтительный шлюз выходит из строя без разрыва физического канала, система не переключается на второй.
Я попытался установить более высокую метрику для сбойного GW вручную, это сработало, но это ручной шаг, которого я хочу избежать.
Можно ли решить эту проблему с помощью Network Manager?
Моя настройка: Ubuntu 16.04, NM 1.2.2
UPD
Участник сообщества на канале irc NM ответил, что NM не проверяет, действительно ли работает шлюз, и не выполняет переключение GW.
VRRP / ucarp / heartbeat / keepalived также не проверять. Они только проверяют доступность сети и переключают восходящие GW за виртуальным интерфейсом. Это не помогает в моем случае.
Следующий магазин Iproute вроде работает, но с огромной задержкой. Маршруты кэшируются ядром и даже после ip route flush cacheсистеме потребовалось около 10 минут для перехода на второй ГВт.
ip route replace default scope global \
nexthop via 11.22.33.1 dev eth0 weight 1 \
nexthop via 55.66.77.1 dev eth1 weight 1
Мое текущее решение: скрипт оболочки, который проверяет, предоставляет ли текущий gw по умолчанию доступ в Интернет; если нет - это увеличивает метрику текущего GW и система переключается на второй с более низкой метрикой.
Я все еще надеюсь найти более элегантное решение.
3 ответа
Для этого и создан BGP. Использование того, что обычно называют iBGP для внутренней связи маршрутизатора и избыточности пути и / или eBGP для избыточности полного пути на уровне Интернета. BGP описывает протокол для маршрутизаторов для обмена друг с другом аналитическими данными, необходимыми для принятия решений о характере допустимых и функциональных маршрутов трафика в автономной системе.
Я не вижу, чтобы кто-то делал это с NetworkManager в качестве инструмента конфигурации времени выполнения для такой степени маршрутизации. У NM были исторические проблемы с плохим масштабированием при использовании многих маршрутов, и существует гораздо лучшее программное обеспечение, разработанное для того, что вы хотите.
Большинство коммерческих маршрутизаторов будут иметь функциональность BGP, так что вы можете получить их "консервированными". Я обычно использую pfSense или VyOS, если я собираюсь использовать "программный маршрутизатор", так как они хорошо виртуализируются. VyOS даже поддерживает изображения LXD, поэтому я обычно использую это. Вы также можете использовать BGP в большинстве дистрибутивов Linux вручную с пакетами openbgbpd или quagga.
Многие решения SDN используют BGP для обеспечения избыточности и балансировки сети, а не системы, подобные MLAG, поскольку многие реализации MLAG на коммутаторах и маршрутизаторах Ethernet исторически либо были слишком специфичными для конкретного поставщика, либо не функционировали должным образом, особенно при использовании несоответствующего оборудования. Вместо того, чтобы беспокоиться о драйверах управления для каждого коммутатора, SDN часто ориентируется на работу над уровнем 2 для этих многоузловых решений с избыточностью даже во внутренней сети.
Теперь вы можете добавить проверку подключения к NM, которая автоматически увеличит метрику интерфейса, если хост будет недоступен.
Смотрите раздел подключения NetworkManager.conf. У Диги тоже есть хорошая статья на эту тему.
Я думаю, что есть несколько возможностей. Лучший / современный способ - использовать "таблицы" iproute2. Я еще не получил его полностью, но он описан здесь: http://mlvpn.readthedocs.io/en/latest/linux_example.html К сожалению, этот пример делает БОЛЬШЕ, чем вы просите, и это запутало проблему. Но я верю, что что-то подобное может сработать:
ip route show table main
ip route add default via 10.70.1.1 dev eth0 table 100
ip route add default via 10.70.70.1 dev eth0 table 101
При желании, отредактируйте /etc/iproute2/rt_tables и добавьте две строки:
100 myfavgw
101 myothergw
И тогда вы можете обратиться к этим по имени:
ip route add default via 10.70.70.1 dev eth0 table myothergw
Может потребоваться некоторая дополнительная игра, но вышесказанное кажется многообещающим началом. Я не могу проверить это, потому что один из моих двух шлюзов только что вышел из строя:-(
Второй метод, кажется, зависит от довольно старой технологии. В этой статье 2005 года предполагается, что если у вас есть две сетевые карты, вы можете указать разные шлюзы по умолчанию для каждого: https://www.linux.com/news/using-linux-failover-router. Так что - думая вслух - если у вас нет двух сетевых карт, есть способ (я забыл, как) создать второй виртуальный интерфейс и использовать для него ту же карту Ethernet (сделать это было так же просто, как загрузить модуль ядра, и он отлично работал). Если можно по-прежнему указывать разные значения gw по умолчанию для каждого интерфейса, тогда этот второй подход будет решением проблемы старой школы.
Третье решение - уродливое. Как вы указали, можно проверять сценарий оболочки каждую минуту. Такой скрипт есть здесь: rapellys.biz /? P =59