Linux несколько шлюзов по умолчанию

ip rule add lookup table localnets pref 1000

ip rule add lookup localnets pref 1000

Иначе команда вообще не работает.

ip rule add lookup table localnets pref 1000

нужно смотреть как

ip rule add from all lookup localnets pref 1000

Источник

Настройка основного и двух резервных операторов на Linux-роутере с NetGWM

Задача резервирования основного шлюза — одна из самых популярных в сетевом администрировании. У нее есть целый ряд решений, которые реализуют механизмы приоритезации или балансировки исходящих каналов для абсолютного большинства современных маршрутизаторов, в том числе и маршрутизаторов на базе Linux.

В статье об отказоустойчивом роутере мы вскользь упоминали свой корпоративный стандарт для решения этой задачи — Open Source-продукт NetGWM — и обещали рассказать об этой утилите подробнее. Из этой статьи вы узнаете, как устроена утилита, какие «фишки» можно использовать в работе с ней и почему мы решили отказаться от использования альтернативных решений.

Почему NetGWM?

Классическая схема резервирования основного шлюза в Linux, реализуемая средствами iproute2, выглядит практически во всех источниках примерно одинаково:

• Дано: 2 провайдера.
• Создаем для каждого оператора свою таблицу маршрутизации.
• Создаем правила ( ip rule ), по которым трафик попадает в ту или иную таблицу маршрутизации (например, по источнику и/или по метке из iptables).
• Метриками или ifupdown-скриптами определяем приоритет основного шлюза.

Подробности этой схемы легко гуглятся по запросу «linux policy routing». На наш взгляд, схема имеет ряд очевидных недостатков, которые и стали основным мотиватором создания утилиты NetGWM:

1. Сложность внесения изменений в схему, плохая управляемость.
2. Если количество шлюзов 3 и более, логика скриптов усложняется, как и реализация выбора шлюза на основе метрик.
3. Проблема обнаружения пропадания канала. Зачастую, физический линк и даже шлюз оператора могут быть доступны, при этом из-за проблем внутри инфраструктуры оператора или у его вышестоящего поставщика услуг реально сеть оказывается недоступной. Решение этой проблемы требует добавление дополнительной логики в ifupdown-скрипты, а в маршрутизации на основе метрик она нерешаема в принципе.
4. Проблема «шалтай-болтай». Такая проблема проявляется, если на высокоприоритетном канале наблюдаются кратковременные частые перерывы в связи. При этом шлюз успешно переключается на резервный. Откуда здесь, казалось бы, может взяться проблема? Дело в том, что ряд сервисов, таких как телефония, видеосвязь, VPN-туннели и другие, требуют некоторого таймаута для определения факта обрыва и установления нового сеанса. В зависимости от частоты обрывов это приводит к резкому снижению качества сервиса или его полной недоступности. Решение этой проблемы также требует усложнения логики скриптов и тоже совершенно нерешаема метриками.

Мы посмотрели, что поможет нам решить все 4 проблемы: простое и управляемое средство с поддержкой 2 и более шлюзов по умолчанию, умеющее диагностировать доступность канала и тестировать его на стабильность. И не нашли такого варианта. Именно так и появился NetGWM.

Установка из GitHub и репозитория «Флант»

NetGWM (Network GateWay Manager) — это небольшая утилита приоритезации основного шлюза, написанная на Python и распространяемая под свободной лицензией GNU GPL v3. Автор первоначальной версии — driusha (Андрей Половов).

Исходный код и документация на английском языке доступны на GitHub, а краткая документация и описание на русском языке — здесь.

Установка из GitHub:

Кроме того, готовый DEB-пакет с NetGWM можно установить из репозитория для Ubuntu компании «Флант». Установка для Ubuntu 14.04 LTS выглядит так:

Добавлять служебную таблицу маршрутизации и настраивать cron в Ubuntu не потребуется. Таблица автоматически добавится при установке пакета. Кроме того, при установке будет зарегистрирована служба netgwm , init-скрипт которой стартует в качестве демона небольшой shell-скрипт /usr/bin/netgwm , который, в свою очередь, читает из файла /etc/default/netgwm значение параметра INTERVAL (в секундах) и с указанной периодичностью сам вызывает netgwm.py .

Настройка

В основе работы NetGWM также лежит policy-роутинг, и нам придется предварительно настроить таблицы маршрутизации для каждого оператора.

Допустим, есть 3 оператора, и необходимо сделать так, чтобы основным оператором был оператор 1, в случае отказа — использовался оператор 2, а в случае отказа из обоих — оператор 3.

Пусть первый оператор у нас подключен к интерфейсу eth1, второй — к eth2, третий — к eth3. Первый оператор имеет шлюз 88.88.88.88, второй оператор — шлюз 99.99.99.99, третий — 100.100.100.100.

Мы почти всегда при настройке сети с несколькими основными шлюзами используем маркировку пакетов и модуль conntrack из NetFilter. Это хорошая практика, помогающая распределять пакеты по таблицам маршрутизации с учетом состояния, но не являющаяся обязательной.

Настроим маркинг пакетов и conntrack:

2. Добавим правила маршрутизации для промаркированных пакетов. Мы это делаем с помощью скрипта, который вызывается из /etc/network/interfaces при событии post-up на интерфейсе lo:

3. Объявим таблицы маршрутизации в /etc/iproute2/rt_tables :

4. Настроим NetGWM. По умолчанию, netgwm.py будет искать конфигурационный файл по адресу /etc/netgwm/netgwm.yml , однако вы можете переопределить это с помощью ключа -c . Настроим работу утилиты:

5. Настроим действия при переключении

Если произойдет переключение, то после смены основного шлюза будут выполнены все исполняемые файлы из каталога /etc/netgwm/post-replace.d/* . При этом каждому файлу будут переданы 6 параметров командной строки:

• $1 — наименование нового оператора;
• $2 — IP вновь установленного шлюзе или NaN, если новый шлюз установить не удалось;
• $3 — имя устройства нового шлюза или NaN, если шлюз установить не удалось;
• $4 — наименование старого оператора или NaN, если шлюз устанавливается впервые;
• $5 — IP старого оператора или NaN, если шлюз устанавливается впервые;
• $6 — имя устройства старого оператора или NaN, если шлюз устанавливается впервые.

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

6. Стартуем сервис netgwm в Ubuntu, если вы установили DEB-пакет:

Если вы получили NetGWM из GitHub, то установленное ранее задание в cron уже и так проверяет доступность вашего основного шлюза, дополнительных действий не требуется.

Журналирование

События по переключению NetGWM регистрирует в журнале /var/log/netgwm :

Сохраненная история переключений помогает произвести анализ инцидента и определить причины перерыва в связи.

Проверено в production

Уже около 4 лет NetGWM используется в нашей компании на 30+ маршрутизаторах Linux разных масштабов. Надежность утилиты многократно проверена в работе. Для примера, на одной из инсталляций, с мая 2014 года NetGWM обработал 137 переключений операторов без каких-либо проблем.

Стабильность, покрытие всех наших потребностей и отсутствие проблем в эксплуатации в течение длительного времени привели к тому, что мы практически не занимаемся развитием проекта. Код NetGWM написан на Python, поэтому отсутствует и необходимость в адаптации утилиты к новым версиям операционных систем. Тем не менее, мы будем очень рады, если вы решите принять участие в развитии NetGWM, отправив свои патчи в GitHub или просто написав feature request в комментариях.

Заключение

С NetGWM мы имеем стабильную, гибкую и расширяемую (с помощью скриптов) утилиту, которая полностью закрывает наши потребности в управлении приоритетом основного шлюза.

Любые вопросы по использованию NetGWM также приветствуются — можно прямо здесь в комментариях.

Источник

2 шлюза по-умолчанию в Linux в одной подсети с разной метрикой на одном интерфейсе. Возможно ли?

Есть одна довольно чудная машинка с одним адресом в LAN на которую заNATчены 2 WAN адреса с двух разных роутеров от двух разных провайдеров. Из интернета сия жуть доступна по обоим адресам и прекрасно работает.

Выглядит это примерно так:

Проблема ожидаемо возникает с исходящим трафиком, когда пропадает ISP 1 (default gw). Ситуация осложняется тем, что аварии ISP не приводят к недоступности самих шлюзов .1 и(или) .254.

Будет ли работать сеть, если указать 2 шлюза с разной метрикой одному сетевому интерфейсу? Пойдет ли трафик во второй шлюз?

Понятное дело, что можно руками переключить gw на .254 и все заработает. Но можно ли это автоматизировать?

• Вопрос задан более трёх лет назад
• 5461 просмотр

Можно указать два дефолтныйх маршрута с разной метрикой:
unix.stackexchange.com/questions/35713/adding-two-.
примерная команда route add default gw 192.168.1.254 metric 2

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

Источник

Вам также может понравиться

Windows или Linux: Что лучше выбрать?

Есть много причин выбирать между Windows и Linux, но

Файл владелец изменить linux

Команда Chown в Linux Chown Command in Linux (File

Установка шлюза по умолчанию linux

Настройка сети вручную Содержание Краткое описание

Чем разбить диск для linux

ИТ База знаний Курс по Asterisk Полезно — Узнать IP —