18 мар. 2011 г.

Настройка резервного интернет-канала

Задача: Есть некий сферический сервер в вакууме, который занимается раздачей интернетов. Интернетов имеется два: толстый и безлимитный - для хорошей и повседневной жизни, а также хилый и помегабайтный - для годины тяжелой. И хочется простого человеческого счастья - вечного интернета. А именно, пока все хорошо, жить на толстом канале, а если он упал, резво переключиться на хилый, не забыв следить за состоянием основного, дабы возвернуться на него по появлении линка.
Как ни странно, на просторах Сети мне так и не удалось найти простого и доступного решения такой, казалось бы, частой возникающей задачи. Нет, варианты решения присутствуют, например, вот тут есть неплохой скрипт на баше, замечательно комментированный. Можно использовать его, можно упростить или усложнить в зависимости от ситуации, с логикой у меня проблем не возникло, код понятный. В иных местах советуют договориться с провайдерами, прикупить AS у RIPE, затариться цисками, etc.
Однако можно обойтись и одной quagga'ой. Да, это мощнейший инструмент, поддерживающий большинство (если не все) протоколов маршрутизации (OSPF, RIP, RIPng, BGP-4), и использовать его в качестве исключительно монитора состояния аплинка и смены маршрута по умолчанию, возможно, неоптимально. Однако найти более простой инструмент для этого функционала мне не удалось, поэтому будем работать с ней. К тому же, в дальшейшем планируется развитие сети, и OSPF будет очень полезным.
Итак, я не буду углубляться в архитектуру и возможности Quagga, об этом можно почитать как на оффсайте, так и в материалах по ней в Сети. Скажу лишь, что буду использовать только демон zebra, который занимается непосредственно таблицами маршрутизации и умеет следить за состоянием сетевых интерфейсов. Собственно, требуется мониторить состояние (подключено/неактивно) двух интерфейсов (eth200 - "толстый инет", ppp200 - "хилый инет") и при неактивности первого переключаться на второй, а при возвращении линка - восстанавливать первоначальное состояние.
Всех дел - создать zebra.conf следующего содержания:
! -*- zebra -*-
!
! zebra sample configuration file
!
hostname zebra
password zebra
enable password ezebra
!
! Interface's description.
!
interface ppp200
description beeline gprs
link-detect
!
interface eth200
description multinex vlan
link-detect
!
ip route 0.0.0.0/0 23.45.67.89 1
ip route 0.0.0.0/0 ppp200 2
ip route 0.0.0.0/0 null0 255
!
log file /var/log/quagga/zebra.log
Поля hostname, password, enable password заполняются произвольно, смысл понятен из названий. Описания интерфейсов: interface - имя интерфейса, за которым следим, description - его описание (для себя), link-detect - включение слежения за состоянием соединения. Маршруты: описываем множественный маршрут по умолчанию, последняя цифра - метрика (меньше - важнее). Если живы оба интерфейса, прописывается маршрут с меньшим значением метрики.
Далее в /etc/quagga/zebra.conf включаем демон zebra:
zebra=yes
Теперь запускаем кваггу и подключаемся с ней telnet'ом:
/etc/init.d/quagga start
Loading capability module if not yet done.
Starting Quagga daemons (prio:10): zebra.
telnet localhost 2601
Если оба линка активны, то в список статических маршрутов выглядеть примерно так:
zebra> show ip route static
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

S   0.0.0.0/0 [255/0] is directly connected, Null0, bh
S   0.0.0.0/0 [2/0] is directly connected, ppp200
S>* 0.0.0.0/0 [1/0] via 23.45.67.89, eth200
Звездочка показывает, какой маршрут в данный момент используется. Если сейчас выдернуть провод из eth200, звездочка переместится на ppp200. При возвращении линка в eth200 маршрут снова переместится, так как метрика у eth200 выше. В момент запуска зебры этой звездочки может и не быть, если демону не приходилось выбирать маршрут.
P.S.: Данное решение также не лишено недостатков. Так как переключение маршрутов основано на состоянии линка, то при проблемах программного харакактера у провайдера (eth200) активный линк не дает гарантии наличия интернета. С ppp-интерфейсами тут проще, они при потере связи с концентратором падают. Все это стоит иметь в виду при построении своей сети.

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

Отправить комментарий