Хорошо, у меня есть Linux-бокс с одним кабельным WAN и GPRS-модемом (или, скажем, другое WAN-соединение, которое обычно не работает).
Есть ли возможность сделать это второе соединение (GMPR / Ethernet / другое) как резервное соединение, которое используется ТОЛЬКО, когда основное соединение не работает должным образом?
Я могу определить состояние первичной ссылки, просто выполнив проверку связи с указанным сервером в Интернете (важно, чтобы это не был шлюз, потому что иногда шлюз доступен, а остальная часть Интернета - нет ...).
далее - я могу написать этот тест в каком-нибудь bash-скрипте, чтобы периодически проверять соединение и переключаться на резервную ссылку при разрыве основного соединения. Но при изменении - маршрут по умолчанию изменяется на второе соединение, и я не могу проверить в фоновом режиме, не работает ли основная ссылка ...
Итак - есть ли какое-либо решение, чтобы установить маршрут по умолчанию для всех приложений для резервного канала и по-прежнему иметь возможность маршрутизировать пинги через первичный канал? Что делает его более сложным, я не могу поставить статический маршрут на тестовый сервер всегда через первичную ссылку, так как те «приложения», которые работают на сервере, также пытаются подключиться к этому серверу, и я хочу, чтобы они использовали резервную ссылку, когда первичный не работает ...
Нечто подобное я видел на двойном маршрутизаторе WAN Linksys RV042. Он может контролировать первичное соединение (пока вторичный не работает), а когда первичный выходит из строя - он использует вторичный канал, но когда первичный снова включается - вторичный отключается, и весь трафик снова перенаправляется через первичный канал.
У меня аналогичная проблема с нашим провайдером кабельного телевидения - шлюз может быть доступен, а остальная часть Интернета - нет. Я использовал traceroute, чтобы найти хост с возможностью проверки связи на границе сети провайдера в качестве тестового узла для проверки связи. Вы делаете то же самое, чтобы найти хост в качестве пункта назначения / статического маршрута для проверки связи.
Выберите сервер, к которому вам никогда не понадобится доступ по резервной ссылке. Это может быть следующий переход в traceroute после шлюза (вы все равно никогда не разговариваете с этим маршрутизатором). Или просто услуга, которую вы никогда не использовали бы через GPRS (например, потоковое видео). Создайте статический маршрут к этому серверу через первую ссылку.
с политикой-маршрутизацией вы можете использовать разные таблицы маршрутизации в зависимости от метки [fwmark], установленной в iptables. вы можете установить разные метки для одного и того же хоста, но с разными номерами портов [возможно, вы можете запустить пару тестовых сервисов на вашем конечном сервере на разных портах] ...
или, может быть, вы можете установить статический маршрут на несколько соседних IP-адресов вашего целевого сервера?
смотреть на Lartc для получения дополнительной информации.
Если вы можете гибко выбирать, какое программное обеспечение использовать для брандмауэра / маршрутизации, вы можете попробовать настроить Shorewall следующим образом: http://www.shorewall.net/MultiISP.html
Я привожу это в качестве примера, потому что это то, что я использую лично, поэтому проверьте, поддерживает ли ваш предпочтительный инструмент настройки netfilter или другое приложение межсетевого экрана / маршрутизации функциональность MultiISP.
Используя указанный пакет LSM, вы можете определять действия, предпринимаемые при событиях подключения / отключения. Поэтому, когда ваш основной канал отключается, вы можете выполнить серию команд, необходимых для включения вашего вторичного канала, прежде чем трафик будет направлен на него.
Что касается правильной маршрутизации пакетов ping на ваш тестовый сервер в приведенной выше настройке, см. Раздел о приложениях в привязке #Applications. (Я бы разместил прямую ссылку, но я ограничен только одним URL)
Поскольку Shorewall является интерфейсом для инструментов нижнего уровня, вы должны иметь возможность достигать того, что он делает, напрямую, если это больше то, что вы ищете. Вы можете выполнять маршрутизацию на основе подтаблиц в дополнение к таблице маршрутизации по умолчанию, и вы можете использовать fwmark для направления пакетов в эти подтаблицы.
Например, в моем 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, и соответствующим образом изменить шлюз по умолчанию. При сбое ping до 9.9.9.9 ваш сценарий должен изменить шлюз по умолчанию, чтобы трафик перенаправлялся на резервную ссылку. Однако из-за правила и таблицы, которые мы только что добавили, пинг (или любой трафик) до 9.9.9.9 по-прежнему будет маршрутизироваться через первичный канал.
Вы можете протестировать, изменив шлюз по умолчанию (используя route del default && route add default gw 2.2.2.2 ) и tracroute до 9.9.9.9