У меня есть сервер Debian Wheezy под управлением Xivo (назовем его A), у этого сервера 2 интерфейса: eth0 и eth1 . Шлюза по умолчанию нет, и только несколько серверов статически доступны из A. eth0 имеет общедоступный IP-адрес и напрямую подключается к удаленному серверу (назовем его B), второму интерфейсу A, eth1 находится в локальной сети с другим подключением к Интернету, которое предполагается использовать для других целей.
В таблице маршрутизации A, B доступен через интерфейс eth0. Я хочу настроить аварийный маршрут, который пытается подключиться через eth1 если попытка подключения не удалась eth0. У меня нет доступа к маршрутизаторам, и не может быть задействована динамическая маршрутизация извне A.
Пока что я вижу разные вещи вроде ip rule, heartbeat HA и другие технологии, но с этим вопросом я хочу определить, возможно ли то, что я хочу делать, и, если возможно, с помощью каких технологий.
Я решил перефразировать свой вопрос, потому что чувствую, что никто не знает.
Как я могу отслеживать ссылку с одного сервера на другой и принимать меры, если ссылка не работает? Это также может быть связано с разрешением arp, потому что я виртуально подключен к удаленному хосту и знаю его MAC-адрес.
Я почти уверен, что в джунглях Интернета уже есть возможности, и я не хочу изобретать велосипед для этой задачи.
Поскольку решение сценария, наконец, то, что я выбрал, я принимаю его и награждаю, но я добавил своего рода компиляцию всего, что я пробовал, прежде чем использовать сценарий
Некоторое время назад у меня была аналогичная проблема с подключением к удаленному серверу из регистратора данных (Ubuntu) через нестабильное соединение HDSL (иногда не работающее в течение нескольких дней!). Я создал простой сценарий bash, работающий в регистраторе данных в crontab. Скрипт работал так:
Это не было изящным решением, но в моем сценарии оно сработало!
У меня есть несколько решений, и одно из них - это скрипт crontabed, работающий с arping это сценарий:
#!/bin/sh
#remote host to test on public interface
REMOTE_TEST_IP="195.168.156.1"
REMOTE_TEST_MAC="00:2D:FF:FF:FF:FF"
#number of arp request send to test connectivity
TEST_COUNT=4
#the rate acceptable of arp request failling, strictly above this rate the route will be change
#NEVER put 100 or it will never set up failover
ACCEPTABLE_FAILURE_RATE=20
#list of network that will be rerouted if test fails
NETWORK_LIST="25.14.0.0/20 198.27.45.40/32 21.1.80.0/20"
PUBLIC_DEVICE="eth0"
PUBLIC_GATEWAY="192.168.1.250"
PRIVATE_DEVICE="eth1"
PRIVATE_GATEWAY="15.168.16.4"
#try to ping the remote host ip and the remote host mac, extract the result line and get the failure rate
FAILURE_RATE=$(arping -i $PUBLIC_DEVICE -c $TEST_COUNT -t $REMOTE_TEST_MAC $REMOTE_TEST_IP | grep % | sed -r s/.* ([0-9]{1,3})% .*/\1/)
#if the faillure is superior to the acceptable failure rate, change the route to remote the remote host
if [ $FAILURE_RATE -gt $ACCEPTABLE_FAILURE_RATE ]
then
for NETWORK in $NETWORK_LIST
do
logger "$0 - WARNING -The network route to $NETWORK_LIST are set to failover route."
route del -net $NETWORK gw $PUBLIC_GATEWAY dev $PUBLIC_DEVICE
route add -net $NETWORK gw $PRIVATE_GATEWAY dev $PRIVATE_DEVICE
done
else
for NETWORK in $NETWORK_LIST
do
#back to default route
route del -net $NETWORK gw $PRIVATE_GATEWAY dev $PRIVATE_DEVICE
route add -net $NETWORK gw $PUBLIC_GATEWAY dev $PUBLIC_DEVICE
done
fi
Я также нашел другое решение, например, упоминание в других ответах.
Я действительно не знаю других решений, упоминание в блоге Джона Олда Вот датируется 2005 годом, когда linux все еще использовал метрику маршрута, чего больше нет, за исключением случаев, когда вы используете протокол динамической маршрутизации.
В следующей статье объясняется, как можно простым способом добиться отказоустойчивой маршрутизации.
http://archive09.linux.com/feature/113988
Это включает добавление двух маршрутов к одному и тому же пункту назначения, один через eth0 и один через eth1, а также настройку тайм-аута, которая переключает активный маршрут, когда один из них становится недоступным.
Имейте в виду, что исходящий IP-адрес исходящих пакетов изменится, если используется nat. Для протоколов без установления соединения, таких как HTTP, это не имеет значения. Однако с протоколами, ориентированными на соединение, маршрут может переключиться, но при изменении IP-адреса источника соединения не удастся.
VoIP упоминается в ваших комментариях, и вы должны ожидать, что вызовы не будут выполнены и их нужно будет перезапустить.
Ваш вопрос интересный. Поиск google дал Mpath-инструменты
Mpath-tools - это набор программ для Linux 2.6+, которые призваны облегчить балансировку нагрузки и переключение при отказе через несколько и разнородных подключений ISP.
Mpathd - это демон и ядро mpath-tools, он работает в фоновом режиме, отслеживая состояние каждого соединения. Он динамически обновляет таблицы маршрутизации в соответствии с состоянием шлюзов и набором правил, установленных администратором.
Состояние каждого соединения определяется отправкой через ICMP-зонды на один или несколько адресов.
Я никогда не пробовал.
Это конфиденциальный проект, они плохо проиндексированы, поиск «Linux static route failover» ничего не дал, а «Linux Dynamic route failover» дал сайт на странице 4 (возможно, мои навыки поиска не очень хороши); даже "mpath-tools" возвращает лишь несколько ссылок. Обратите внимание, это не означает, что он не работает.