Выбор средств для построения маршрутизатора

Недавно, в центре обработки звонков (Call Center - далее СС), где я работаю связистом, возникла задача связать на основе свободного совта, центральный офис с удалённым. Пришлось познакомится с множеством различных вариантов решения задачки. Как результат, появился некий новый опыт, наработки и соображения на вынесенную в заголовок тему. Цель заметки - ознакомить читателя с отобранными для работы средствами.

Постановка задачи

Есть два офиса распределённого (т.е. географически разнесённого) СС. Центральный и удалённый. Между ними бегает голос - SIP VoIP over VPN over Internet. В каждой точке - два Интернет подключения (для отказоустойчивости). Соответственно, маршрутизатор должен быть подключен к обоим провайдерам Интернета, мониторить доступность Интернета (каких - то IP адресов) через этих провайдеров и в случае, падения основного - переключаться на резервного. Для обеспечения высокой доступности (High Availability - далее НА) - маршрутизаторов - должно быть не меньше двух в каждой точке. При неисправности основного, резервный - должен занять его место.

Голос (в нашем случае - SIP VoIP), ввиду особенностей протоколов, - не любит NAT. Соответственно, что бы избежать проблем с NATом, голос - бегает по VPN туннелям, и NAT - нам не нужен. Кроме того, VPN - позволяет нам не думать об изменившихся реальных IP адресах, в случаях, когда мы (например ввиду неисправности) переключаемся между основным и резервным поставщиками Интернета.

Для голоса, так же важна приоритезация.

Средства

pfSense.

Вначале поисков, наша ИТ команда попробовала использовать готовую сборку с единым интегрированным интерфейсом управления. После общего ознакомления с возможными вариантами, остановились на pfSense. В сети о нём есть много позитивных отзывов, а список его возможностей - впечатляет. Сам pfSense, сделан, на основе BSD и хорошо демонстрирует сетевые возможности BSD операционных систем.

Видимо, на простых задачах - pfSense - действительно - не плох. Однако, печальная практика, показала, что, в нашей - не тривиальной задаче - pfSense, со временем - начинает чудить.

Не вдаваясь в детальные подробности, скажу, что от его использования - пришлось отказаться. После этого неприятного опыта, было принято решение, отказаться от использования готовых сборок и поднять всё - самим.

BSD

pfSense - продемонстрировал возможности BSD систем. В особенности, в сетевых вопросах, постарались товарищи из OpenBSD. Они, например, создали протокол CARP для обеспечения High Availability. Написали много всего полезного. По этой причине, для второй попытки был выбран OpenBSD.

Однако и этот опыт - оказался не удовлетворительным. Когда работаешь с OpenBSD - тебя постоянно преследует ощущение упадничества и «разложения». Построить требуемую систему на платформе OpenBSD - можно, но с гораздо большими трудозатратами чем на базе Линукса. Это путь - для любителей сложностей. Опять таки, конкретные детали, что бы не перегружать заметку - я опускаю. Однако - для любителей 'Holly Wars', замечу, что, я не ставлю себе цели убеждать и доказывать. Я хочу поделится опытом, впечатлениями и (в данном случае) - предостеречь.

Linux

Работа была продолжена за, горячо любимым Debian-ом. После неуклюжей OpenBSD, особенно сильно чувствуешь, как же они хороши эти apt-get и apt-cashe ;-)

встроенные Linux средства

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

В линуксе, что бы решить эту задачку, нужно воспользоваться дополнительными таблицами маршрутизации. Работа с дополнительными таблицами маршрутизации осуществляется с помощью команд из пакета iproute2. Внимательно прочитайте документацию к iproute2. Для наших задач, в нём - нет особых сложностей.

Этот же пакет позволяет настроить приоритезацию.

После того, как вы создадите таблицы, наполните их содержанием (с помощью - ip route add), вам нужно будет создать правила, по которым сетевой трафик будет направлятся в конкретную таблицу. Делается это с помощью команды - ip rule add.

Следует предупредить об одной заковырке, с которой я столкнулся 'играясь' с таблицами. Маршрут по умолчанию ( ip add default via ...) не всегда добавляется в таблицу если в ней есть уже какие то записи. По этой причине в скриптах, сперва следует вписать в таблицу маршрут по умолчанию, и лишь после этого делать в неё остальные записи.

VPN

Для построения VPN, я предпочитаю использовать tinc - www.tinc-vpn.org. Он гибкий. Может работать как в режиме TCP, так и в UDP режиме. В режиме коммутатора и маршрутизатора. Впечатления от работы с ним - самые положительные.

High Availability

High Availability (высокая доступность) можно реализовать на практике следующим образом. Представьте себе, что у вас для выхода в Интернет предусмотрены два маршрутизатора. Основной и запасной. Оба включены. Запасной следит за состоянием основного. Если основной - выходит из строя, запасной - берёт на себя его функции по отношению к пользователям, например LAN сети. Для этого он, начнёт использовать LAN IP адрес основного маршрутизатора. Тот адрес, который у пользователей прописан как default route в таблице маршрутизации.

Построить НА можно как сложно, так и просто. Можно взять софтик для создания кластеров, например - Pacemaker. Тогда путь будет сложным и неприятным. Я рекомендую избегать его.

Самый простой и приятный из известных мне способов - использовать - ucarp. Man страница - хорошо иллюстрирует, как его использовать.

Динамическая маршрутизация

Возьмём ситуацию, когда в одной из точек стал 'подглючивать' (например, терять 10% пакетов) основной провайдер Интернета. Маршрутизатор в этой точке меняет свои настройки и начинает использовать 'запасные' VPN туннели, через резервного провайдера. Вопрос. Как маршрутизаторы в удалённой точке узнают о том, что им нужно тоже перенастроиться на использование 'запасных' VPN туннелей? Для их оповещения можно использовать протокол динамической маршрутизации - OSPF. Пожалуй, на сегодняшний день, самый популярный софтик под линукс, позволяющий поднять OSPF - это quagga - BGP/OSPF/RIP routing daemon. Но, я рекомендую использовать BIRD - http://bird.network.cz/. Он - проще и легче в настройке, логичней организован.

hping3

Протокол динамической маршрутизации, сам по себе способен заметить разрыв соединения. Но, как быть, если разрыв не наступил, но качество ухудшилось. Например, основной Интернет провайдер стал терять 10 % пакетов. Качество голоса - станет отвратительным, но OSPF - проблем на линии не заметит. Во избежание таких ситуаций, нам, придётся создать демон, который будет следить за качеством. Как вариант, - пинговать некие IP адреса в сети. Для построения, подобных демонов, я рекомендую использовать - hping3 - hping.org.

hping - можно использовать и как утилиту и , писать скрипты с использованием, моего любимого языка программирования - TCL.

TCL - необычайно прост и лёгок в использовании и изучении. Для знакомства с ним можно воспользоваться - http://tclstudy.narod.ru/

Есть так же online книга от автора hping3 - http://www.invece.org/tclwise/

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

Как сказал Брайан Керниган (Brian Kernighan) http://ru.wikipedia.org/wiki/Керниган,_Брайан :

"Tcl/Tk is wonderfully productive; in a few hours one can accomplish what might well take days or even weeks with C-based tools. The package is extremely robust, very well documented, and has an active and cooperative group of users. The source code is freely available and of exceptionally high quality. It is clearly possible to build production-quality user interfaces with Tcl/Tk, and to do so far faster than with competing tools."

а так же:

''Tcl/Tk is a surprisingly well-kept secret.''

Совет

В заключении, хочу дать очень важный совет. Прежде чем приступать к конфигурации 'коробок', нарисуйте всё, что собираетесь конфигурировать. В нашем случае, понадобится выполнить не меньше двух рисунков: рисунок IP уровня самих 'коробок' и рисунок IP уровня VPN инфраструктуры. Первый будет содержать, коробки и их не VPN интерфейсы. Второй будет отображать то, как 'бегает' VPN.

Тот кто не ленится рисовать - решает проблемы ещё на этапе планирования работ. Это очень сокращает потери времени во время проведения самих работ.

Обзорчик очень сжатый, но в нём достаточно информации, что бы стартовать без излишних сложностей.