linux box WAN отказоустойчивая конфигурация
Хорошо, у меня есть linux box с одним кабельным WAN и GPRS модемом (или, скажем, другим WAN-соединением, которое обычно не работает).
Есть ли возможность сделать это второе соединение (GMPR/Ethernet/ другое) резервным соединением, которое используется ТОЛЬКО, когда основное соединение не работает должным образом?
Я могу определить состояние первичного канала, просто отправив эхо-запрос на указанный сервер в Интернете (важно, чтобы он не был шлюзом, потому что иногда шлюз доступен, а остальная часть Интернета - нет...).
далее - я могу написать этот тест в некотором скрипте bash, чтобы периодически проверять соединение и переключаться на резервную ссылку, когда основное соединение разорвано. Но при изменении - маршрут по умолчанию меняется на второе соединение, и я не могу проверить в фоновом режиме, если основная ссылка все еще не работает...
Итак, есть ли какое-либо решение, чтобы установить маршрут по умолчанию для всех приложений для резервного копирования и по-прежнему иметь возможность маршрутизировать пинг через первичную ссылку? Что делает это более сложным, я не могу поставить статический маршрут на тестовый сервер всегда через первичную ссылку, поскольку те "приложения", которые работают на сервере, также пытаются подключиться к этому серверу, и я хочу, чтобы они использовали резервную ссылку, когда основной не работает...
Нечто подобное я видел и на маршрутизаторе linksys RV042 dual WAN. Он может контролировать первичное соединение (в то время как вторичное не работает), и когда первичное отключается - оно использует вторичное соединение, но когда первичное снова работает - вторичное отключено, и весь трафик перенаправляется через первичное соединение снова.
5 ответов
У меня похожая проблема с нашим кабельным провайдером - шлюз может быть доступен, а остальная часть интернета - нет. Я использовал traceroute, чтобы найти хост, доступный для пинга, на границе сети провайдеров, в качестве тестового хоста для пингов. Вы делаете то же самое, чтобы найти хост в качестве пункта назначения ping-теста / кандидата на статический маршрут.
Выберите сервер, к которому вам никогда не нужен доступ по резервной ссылке. Это может быть следующий переход в traceroute после шлюза (вы все равно никогда не общаетесь с этим маршрутизатором). Или просто сервис, который вы никогда не используете по GPRS (например, потоковое видео). Создайте статический маршрут к этому серверу через первую ссылку.
Если вы гибко относитесь к тому, какое программное обеспечение вы используете для своего брандмауэра / маршрутизации, вы можете попробовать установку Shorewall следующим образом: http://www.shorewall.net/MultiISP.html
Я привожу это в качестве примера, потому что это то, что я использую лично, поэтому проверьте, поддерживает ли ваш предпочитаемый инструмент конфигурации netfilter или другое приложение брандмауэра / маршрутизации функцию MultiISP.
Используя указанный пакет LSM, вы можете определить действия, которые будут выполняться над событиями перехода вверх / вниз. Таким образом, когда ваша первичная ссылка выходит из строя, вы можете выполнить серию команд, необходимых для активации вашей вторичной ссылки, прежде чем трафик будет направлен на нее.
Что касается правильной маршрутизации ping-пакетов на ваш тестовый сервер в приведенной выше настройке, см. Раздел о приложениях в привязке #Applications. (Я бы опубликовал прямую ссылку, но я ограничен только одним URL)
Поскольку Shorewall является интерфейсом для инструментов нижнего уровня, вы должны быть в состоянии достичь того, что он делает напрямую, если это больше, чем вы ищете. Вы можете маршрутизировать на основе подтаблиц в дополнение к таблице маршрутизации по умолчанию, и вы можете использовать fwmarks для направления пакетов в эти подтаблицы.
Например, в моем "ip route ls" у меня есть:
10000: from all fwmark 0x100 lookup DSL
10001: from all fwmark 0x200 lookup WifiNet
Это на самом деле легко.
Предположим, что ISP1 является основным, а ISP2 - резервным.
1.1.1.1 - это IP-адрес шлюза ISP1.
2.2.2.2 - это IP-адрес шлюза ISP2.
9.9.9.9 - это IP-адрес, доступный на ISP1, который вы будете использовать для определения, работает ли ISP1 или нет.
Сначала вам нужна другая таблица маршрутизации, кроме основной таблицы. Давайте использовать таблицу 10.
Добавьте шлюз по умолчанию к IP-адресу шлюза ISP1 в таблицу 10 следующим образом:
# ip route add default via 1.1.1.1 table 10
И добавьте правило в базу данных политики маршрутизации (RPDB):
# ip rule add to 9.9.9.9 table 10
Вы можете проверить с помощью:
# ip route list table 10
# ip rule list
Теперь вам нужно написать скрипт, который обнаружит сбой ping до 9.9.9.9 и соответствующим образом изменит шлюз по умолчанию. При сбое проверки связи с 9.9.9.9 ваш сценарий должен изменить шлюз по умолчанию, чтобы трафик направлялся на резервную ссылку. Однако из-за только что добавленного правила и таблицы ping (или любой трафик) до 9.9.9.9 все еще будет маршрутизироваться по первичному каналу.
Вы можете протестировать, изменив шлюз по умолчанию (используя route del default && route add default gw 2.2.2.2) и переходя к 9.9.9.9
С политикой маршрутизации вы можете использовать разные таблицы маршрутизации в зависимости от метки [ fwmark ], установленной в iptables. Вы можете установить разные метки для одного и того же хоста, но разные номера портов [возможно, вы можете запустить несколько тестовых сервисов на вашем конечном сервере на разных портах]...
или, может быть, вы можете установить статический маршрут для нескольких соседних IP-адресов вашего сервера назначения?
посмотрите на LARTC для получения дополнительной информации.