Автоматическое переключение на резервный интернет-канал на шлюзе небольшого офиса

()

Очень часто в различных организациях возникает необходимость резервирования интернет-канала на случай каких-либо сбоев. Крупные организации могут позволить себе купить блок IP-адресов и AS и затем уже покупая каналы у нескольких интернет-провайдеров настроить BGP.

Для небольших компаний такая схема это непозволительная роскошь и обычно небольшие компании просто покупают интернет-каналы у нескольких провайдеров. И имея на каждом из каналов свои независимые адреса и прочие настройки каким-то образом (временами даже в ручную!) настраивают переключение каналов. Далее будет показан один из возможных способов организации автоматического переключения на резервный канал в случае сбоя основного и возврат обратно после восстановления связи.

Внесём немного ясности:

  • Шлюз работает под управлением Debian или Ubuntu Linux;
  • Основной интернет-канал на интерфейсе eth0 с адресом 1.1.1.2/24 и шлюзом 1.1.1.1 (у автора этих строк это ADSL от Таттелекома);
  • Резервный интернет-канал на интерфейсе ppp999 с адресом 2.2.2.2 (у автора этих строк это DOCSIS от ТВТ)

Для начала уточним (на всякий случай) как именно привязать ppp-соединение к ppp-интерфейсу с конкретным номером. Для этого нужно в соответствующий файле в "/etc/ppp/peers&quto; добавить строку:

unit 999

Далее добавим ещё один параметр в тот же файл: метку соединения:

ipparam tbt

Кроме того этот интерфейс не должен при подъёме трогать маршрут по умолчанию. Это достигается примерно вот так:

# Следующие строки закомментированы чтобы не трогать маршрут по умолчанию
#defaultroute
#replacedefaultroute

Это нам пригодиться чуть позже. Сейчас нам нужно описать две дополнительные таблицы роутинга (по одной для каждого провайдера). Для этого в файл "/etc/iproute2/rt_tables" добавим следующие строки:

190     net_tbt
195     net_tattelecom

Теперь нам надо явно указать с какого интерфейса через какую таблицу роутинга искать маршруты. Для этого нужно выполнить вот такие команды (и заодно добавить в "/etc/rc.local" чтобы выполнялись при загрузке):

/sbin/ip rule add from 1.1.1.2 lookup net_tattelecom pref 20000
/sbin/ip rule add from 2.2.2.2 lookup net_tbt pref 20000

Разумеется надо чтобы в нужных таблицах были и нужные маршруты (как минимум маршрут по умолчанию). Для резервного канала это достигается созданием скрипта "/etc/ppp/ip-up.d/tbt" примерно такого содержания:

#!/bin/sh

# Если это подключение к ТВТ (вот тут пригождается ipparam!)
if [ ${PPP_IPPARAM} = "tbt" ]; then
    # Заворачиваем трафик через этот интерфейс для соответствующей таблицы
    /sbin/ip route add default dev ${PPP_IFACE} table net_tbt
fi

Для eth0 всё ещё проще: открываем файл "/etc/network/interfaces" и приводим конфигурацию eth0 к такому виду:

auto eth0
iface eth0 inet static
    address 1.1.1.2
    netmask 255.255.255.0
    gateway 1.1.1.1
    dns-nameservers 127.0.0.1
    metric 100
    post-up /sbin/ip route add default via 1.1.1.1 table net_tattelecom

Теперь нужно перезагрузить сервер и после этого сервер будет по умолчанию идти в интернет через eth0, но при этом снаружи будет доступен по обоим каналам. Теперь создадим скрипт "/usr/local/scripts/check_internet.sh" следующего содержания:

#!/bin/sh

# Доступность этого хоста будет означать корректную работу оснвного канала
# 8.8.8.8 это DNS от Google. За его доступность можно не беспокоиться
# А значит вероятность ложного срабатывания минимальна
HOST="8.8.8.8"

# Файл-флаг. Появляется при переключении на резервный канал
LOCKFILE="/tmp/check_internet.lock"

# Файл журнала
LOGFILE="/var/log/check_internet.log"

# Пингуем проверочный хост через основной канал
ping -I 1.1.1.2 -c 3 -n -q ${HOST} > /dev/null

# Если возникла ошибка (хост не доступен)
if [ $? -ne "0" ]; then
	# Если нет файла-флага
        if [ ! -f ${LOCKFILE} ]; then
		# Меняем маршрут по умолчанию в основной таблице роутинга
                ip route del default
                ip route add default dev ppp999 metric 100
                # Создаём файл флаг
                touch ${LOCKFILE}
                # Делаем запись в файл журнала
                echo `date +'%Y/%m/%d %H:%M:%S'` Internet connection changet to TBT >> ${LOGFILE}
        fi
# Если же всё хорошо
else
	# Если есть файл-флаг
        if [ -f ${LOCKFILE} ]; then
		# Меняем маршрут по умолчанию в основой таблице роутинга
                ip route del default
                ip route add default via 1.1.1.1 metric 100
                # Удаляем файл-флаг
                rm -f ${LOCKFILE}
                # Записываем событие в файл журнала
                echo `date +'%Y/%m/%d %H:%M:%S'` Internet connetction changed to TatTeleCom >> ${LOGFILE}
        fi
fi

Этот скрипт нужно запускать каждую минуту. Для этого в "/etc/crontab" нужно добавить строку:

*       *       *       *       *       root    /usr/local/scripts/check_internet.sh

Далее ещё нужно включить пересылку пакетов (forwarding) и поднять NAT для локальной сети на обоих интерфейсах. Примеры можно найти например тут и тут.

На этом всё. Приятной работы!

Ключевые слова: iproue, ppp, route, ipparam, shell.

Комментарии:

Anonymous 2012-01-08 11:50:53 (#)

а как на счет проверки упавшей eth0?

MooSE 2012-01-08 13:17:42 (#)

Цитата:

а как на счет проверки упавшей eth0?

не совсем понял вопрос. если 8.8.8.8 не доступен через eth0 то значит там какие-то проблемы. а что за проблемы - не так уж и важно.

Anonymous 2012-01-10 14:31:49 (#)

Имхо лучше пинговать не 8.8.8.8 а свой дефалт роутер. Так как и 8.8.8.8 может лежать а интернет быть. (к примеру упал каналы провайдера в эту сеть)

MooSE 2012-01-11 03:34:03 (#)

Цитата:

Имхо лучше пинговать не 8.8.8.8 а свой дефалт роутер. Так как и 8.8.8.8 может лежать а интернет быть. (к примеру упал каналы провайдера в эту сеть)

у таттелекома пару раз было что я пинговал свой гейт а вот за него трафик не ходил. было очень печально

Anonymous 2012-01-11 22:46:56 (#)

Цитата:

Цитата:

Имхо лучше пинговать не 8.8.8.8 а свой дефалт роутер. Так как и 8.8.8.8 может лежать а интернет быть. (к примеру упал каналы провайдера в эту сеть)

у таттелекома пару раз было что я пинговал свой гейт а вот за него трафик не ходил. было очень печально

Аналогично :)

SinClaus 2012-04-08 15:05:21 (#)

По многолетним наблюдениям DNS от Гугля пропадает вместе с Гуглем довольно часто, поэтому универсального рецепта тут нет. У меня циска пингует следующий после гейта хост, а уж если проблема где-то на маршруте и другой пров идёт другой дорогой, переключаюсь на него вручную. Опять если техподдержка не общает исправления ситуации через пару минут.

djrust 2012-07-03 00:08:26 (#)

подскажите как сделать ppp9 основным каналом в интернет + чтобы доступность по обоим каналам сохранилась!
Т.е как бы все наоборот)

проблему решил....не правильно прописывал
post-up /sbin/ip route add default dev 1.1.1.1 table net_tattelecom
надо
post-up /sbin/ip route add default VIA 1.1.1.1 table net_tattelecom

+ в /etc/ppp/peers
defaultroute
replacedefaultroute

Anonymous 2013-06-07 11:13:08 (#)

Уважаемый MooSE!
Спасибо огромное за труд! Есть вопрос в продолжение данной статьи, можно ли раскрыть процесс внесения изменений в iptables "на лету" при автоматическом переключении каналов? Опишу мой случай в примере:
-A TRY-SNAT -j SNAT --to-source 192.168.0.1 это работа через основной канал
-A TRY-SNAT -j SNAT --to-source 192.168.20.1 а вот так должно получиться при переходе на резервный канал
прикручивание в скрипт действий iptables -t nat -D TRY-SNAT -j SNAT --to-source 192.168.0.1
iptables -t nat -A TRY-SNAT -j SNAT --to-source 192.168.20.1 yyt приводят к желаемому результату!
Подскажите пожалуйста, что делаю не так!

MooSE 2013-06-07 22:49:46 (#)

Цитата:

прикручивание в скрипт действий iptables -t nat -D TRY-SNAT -j SNAT --to-source 192.168.0.1
iptables -t nat -A TRY-SNAT -j SNAT --to-source 192.168.20.1 yyt приводят к желаемому результату!
Подскажите пожалуйста, что делаю не так!



А удаление этих правил тоже есть в скрипте?:)

Anonymous 2013-06-17 12:16:50 (#)

Цитата:

А удаление этих правил тоже есть в скрипте?:)

Да, есть!

MooSE 2013-06-22 02:55:16 (#)

Цитата:

Да, есть!

попытался ещё раз вникнуть в задачу и понял что её не понял. что в итоге хотите получить?

изменение набора правил на лету сделать легко. в крайнем случае при переключении можно тупо flush'ить все правила и набивать заново.

пока не понятно что именно вы хотите получить и потому трудно что-то советовать. что за цепочка TRY-SNAT?

Anonymous 2013-07-03 11:51:04 (#)

Цитата:

попытался ещё раз вникнуть в задачу и понял что её не понял. что в итоге хотите получить?

изменение набора правил на лету сделать легко. в крайнем случае при переключении можно тупо flush'ить все правила и набивать заново.

пока не понятно что именно вы хотите получить и потому трудно что-то советовать. что за цепочка TRY-SNAT?

Согласен, flush'ить правила, это самое первое что приходит в голову!
TRY-SNAT это пользовательская цепочка!
Задача, с точки зрения понимания, совершенно простая: требуется при изменении маршрута по умолчанию менять -A TRY-SNAT -j SNAT --to-source 192.168.0.1 на -A TRY-SNAT -j SNAT --to-source 192.168.20.1

Anonymous 2013-07-22 15:35:51 (#)

Проблемка хоть и не сильно большая но подскажите куда смотреть чтобы понять причину.
Сделано все как тут, только кроме интерфейса ppp
У меня eth0 основной eth1 резервный eth2 локалка
переключение проходит на ура!
Но когда работает на основном все пучком работает особенно !пинги! идут
но при переключении на резервный сайты открываются вроде бы как бы работает но пинги не идут. Пробовал применять по новой iptables с очисткой таблиц. не помогает.
Иногда заметил идут после переключение с минутной примерно задержкой.
В чем может быть проблема подскажите плиз.

MooSE 2013-07-26 03:24:11 (#)

Цитата:

Проблемка хоть и не сильно большая но подскажите куда смотреть чтобы понять причину.
Сделано все как тут, только кроме интерфейса ppp
У меня eth0 основной eth1 резервный eth2 локалка
переключение проходит на ура!
Но когда работает на основном все пучком работает особенно !пинги! идут
но при переключении на резервный сайты открываются вроде бы как бы работает но пинги не идут. Пробовал применять по новой iptables с очисткой таблиц. не помогает.
Иногда заметил идут после переключение с минутной примерно задержкой.
В чем может быть проблема подскажите плиз.



А до того как пойдут пинги странички открываются? Тут же проверка соединения происходит раз в минуту. Т.е. если кончился основной канал то переключение на резерв произойдёт в течении минуты. В это время интернета не будет.

Anonymous 2013-12-14 18:25:40 (#)

У Вас статические адреса, а что делать если оба провайдера выдают динамические IP-адреса?
Как делать настройки в случае динамических IP?
Заранее спасибо за ответ.

MooSE 2013-12-20 21:33:32 (#)

Цитата:

У Вас статические адреса, а что делать если оба провайдера выдают динамические IP-адреса?
Как делать настройки в случае динамических IP?
Заранее спасибо за ответ.

DHCP? Или как?

Anonymous 2014-06-15 11:35:44 (#)

Добрый день!
Поясните ситуацию

Есть два канала интернет с IPoE
domru основной
beeline резервный

sudo cat /etc/iproute2/rt_tables
Код: [Выделить]

#
# reserved values
#
255 local
254 main
253 default
195 beeline
190 domru
0 unspec
#
# local
#
#1 inr.ruhep


sudo cat /etc/rc.local
Код: [Выделить]

#
/sbin/ip rule add from IP1 lookup domru pref 20000
/sbin/ip rule add from IP2 lookup beeline pref 20000
exit 0


sudo cat /etc/network/interfaces

Код: [Выделить]

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address IP1
netmask 255.255.255.0
gateway GW1
mertic 100
dns-nameservers 127.0.0.1
post-up /sbin/ip route add default via GW1 table domru
post-up /sbin/ip route del default via GW2 dev eth2 metric 100
post-up /sbin/ip route add default via GW1 dev eth0 metric 100

# The primary network interface
auto eth1
iface eth1 inet static
address 192.168.0.250
netmask 255.255.255.0
dns-nameservers 127.0.0.1
dns-search domen.ru

auto eth2
iface eth2 inet static
address IP2
netmask 255.255.255.252
#gateway GW2
dns-nameservers 127.0.0.1
post-up /sbin/ip route add default via GW2 table beeline


При таких настройках шлюз доступен по обоим каналам

Код: [Выделить]

default via GW1 dev eth0 metric 100
10.10.40.0/24 via 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope link src 10.10.40.1
NETWORK_IP2/30 dev eth2 proto kernel scope link src IP2
NETWORK_IP1/24 dev eth0 proto kernel scope link src IP1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.250


Использую скрипт переключения на резервный канал

скрипт сперт отсюда http://www.ylsoftware.com/news/649
(Нажмите, чтобы показать/скрыть)

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


Вопрос два,но такой же!

Специально делаю

sudo ifconfig eth0 down

пропадает связь по основному каналу...Дожидаюсь выполнения скрипта
получаю

sudo ip r
Код: [Выделить]

default via GW2 dev eth2 metric 100
10.10.40.0/24 via 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope link src 10.10.40.1
NETWORK_IP2/30 dev eth2 proto kernel scope link src IP2
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.250


делаю sudo ifconfig eth0 up
получаю

Код: [Выделить]

default via GW2 dev eth2 metric 100
10.10.40.0/24 via 10.10.40.2 dev tun0
10.10.40.2 dev tun0 proto kernel scope link src 10.10.40.1
NETWORK_IP2/30 dev eth2 proto kernel scope link src IP2
NETWORK_IP1/24 dev eth0 proto kernel scope link src IP1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.250


интернет идет по резервному каналу, но шлюз по основному каналу не доступен...только по резервному...

Если делаю
Код: [Выделить]

sudo ip r del default via GW2 dev eth2 metric 100 && sudo ip r add default via GW1 dev eth0 metric 100

То интернет идет по основному каналу и шлюз доступен по обоим каналам...

Почему так?почему не сохраняется доступность по основному каналу при падении и последующем подьеме eth0?

И как сделать?
Пользователь решил продолжить мысль 14 Июнь 2014, 23:35:29:проблема как раз в том,что при переходе на резервный канал....почему то теряется доступность по основному каналу....хотя он работает...

Т.е сами убираем доступность,происходит переключение....потом включаем доступность и тут облом...не работает!

Anonymous 2014-06-15 11:56:03 (#)

ошибку нашел при подъеме eth0 не срабатывает
post-up /sbin/ip route add default via GW1 table domru

руками делаешь все начинает работать!

Anonymous 2016-01-13 23:17:11 (#)

Как раз то что нужно для моего сервера. К сожалению у меня проводной интернет пропадает даже когда в подъезде просто пропадает электричество. Маршрутизаторы на чердаке не запитаны от ИБП. Пришлось в качестве резерва использовать CDMA-модем. Сервер работает под управлением TCL.
Так как плата за пользование радиоинтернета взимается именно в момент авторизации в сети, то слишком накладно платить за случайный (ошибочный, кратковременный) не-пинг к серверу 8.8.8.8, даже если потом целые сутки можно сидеть на этом безлимите. Сделал двухступенчатую проверку взяв за основу ваш скрипт. В первый неудачный пинг создается пустой файл, во второй неудачный пинг уже другого проверочного сервера в файл записывается любая строка, и потом уже если файл-флаг есть и он не пустой - стартует резервный CDMA канал. Плюс летит curl запрос на сайт моего DDNS регистратора о факте смены IP сервера.
Новый комментарий



© 2006-2016 Вадим Калинников aka MooSE

ИБП APC andpro.ru/catalog/power_supply/ups/apc/ лучшая цена на рынке.