Может ли Network Manager проверить, может ли шлюз по умолчанию направлять пакеты в Интернет?
У меня два интерфейса, оба обеспечивают выход в Интернет.
Когда я отсоединяю кабель от любого из них, шлюз по умолчанию обновляется, и мое подключение к Интернету работает. Но если текущий предпочтительный шлюз выходит из строя без разрыва физического соединения, система не переключается на второй.
Я пытался установить более высокую метрику для сбойного GW вручную, это сработало, но это ручной шаг, которого я хочу избежать.
Можно ли решить эту проблему с помощью Network Manager?
Моя настройка: Ubuntu 16.04, NM 1.2.2
UPD
Член сообщества на irc-канале NM ответил, что NM не проверяет, действительно ли работает шлюз, и не выполняет переключение GW.
VRRP / ucarp / heartbeat / keepalived тоже не проверяйте. Они только проверяют доступность сети и переключают вышестоящие GW за виртуальным интерфейсом. В моем случае это не помогает.
Nexthop от Iproute вроде как работает, но с огромной задержкой. Маршруты кэшируются ядром и даже после ip route flush cache системе потребовалось около 10 минут для переключения на второй GW.
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, и система переключается на вторую с более низкой метрикой.
Я все еще надеюсь найти более элегантное решение.
Это то, для чего был создан 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. У Digi также есть хорошая статья по теме.
Думаю, есть несколько возможностей. Самый лучший / современный способ - использовать 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 по умолчанию для каждого интерфейса, то этот второй подход будет старым решением проблемы.
Третье решение уродливое. Как вы отметили, для проверки каждую минуту можно запускать сценарий оболочки.
Такой сценарий можно найти Вот!