artem
25.05.2016
7876

Policy-based routing в CentOS 6 на примере Dual WAN

В данной статье будет описано, как настроить Policy-based routing в CentOS 6.

Обычно при маршрутизации IP-пакетов маршрут дальнейшего следования пакета выбирается только на основе адреса назначения пакета. Механизм Policy Based Routing (PBR) в Linux позволяет принимать решение о маршрутизации пакета на основе любых полей пакета, метки, присвоенной пакету файрволом и, если понадобится, вообще любых данных, содержащихся в пакете.

Типичное применение Policy-based routing — ситуация, в которой Вам хотелось бы, чтобы основной шлюз, через который будут отправляться пакеты, зависел от сетевого интерфейса, через который пришёл первый пакет соединения. Такая ситуация возникает, например, при использовании более одного интернет-канала.

Настройка Policy-based routing на примере Dual WAN

Описание тестового сервера:

Интерфейс eth0

(первый канал доступа в интернет)

IP-адрес: 1.1.1.1/30

Шлюз по умолчанию: 1.1.1.2

Интерфейс eth1

(второй канал доступа в интернет)

IP-адрес: 2.2.2.1/30

Шлюз по умолчанию: 2.2.2.2

Интерфейс eth2

(локальная сеть)

IP-адрес: 192.168.100.1/24

Отключение Reverse Path Filtering

В современных дистрибутивах Linux обычно по умолчанию включен механизм rp_filter (Reverse Path Filtering). Этот механизм проверяет адрес отправителя каждого входящего пакета по FIB (Forwarding information base), если оказывается, что ответ на пакет должен быть отправлен через интерфейс, отличный от того, через который пришел пакет, то пакет сбрасывается.

Для работы механизма Policy-based routing используются пользовательские таблицы маршрутов, маршруты из которых не попадают в FIB. Поэтому rp_filter нужно отключить на всех интерфейсах, участвующих в Policy-based routing, иначе rp_filter будет сбрасывать входящие пакеты из интернет на всех интерфейсах, кроме того, на который указывает маршрут по умолчанию в таблице main. В нашем случае в Policy-based routing будут участвовать интерфейсы eth0 и eth1.
Для отключения rp_filter на них нужно выполнить команды:

sysctl -w net.ipv4.conf.eth0.rp_filter=0
sysctl -w net.ipv4.conf.eth1.rp_filter=0

Для того, чтобы rp_filter на интерфейсах eth0 и eth1 был выключен и после перезагрузки, нужно добавить в файл /etc/sysctl.conf следующие строки:

net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0

Создание пользовательских таблиц маршрутов, добавление маршрутов

Пользовательские таблицы маршрутизации нужно дописать в конец файла /etc/iproute2/rt_tables.

Имена пользовательских таблиц могут быть произвольными, но не должны совпадать с зарезервированными именами (local, main, default, unspec — они указаны в том же файле).

Номера пользовательских таблиц можно выбирать из диапазона 1-252 (тоже не должны совпадать с занятыми номерами). В данном случае будут добавлены таблицы isp1 и isp2:

#
# reserved values
#
255 local
254 main
253 default
0 unspec
#
# local
#
#1 inr.ruhep

10 isp1
11 isp2

Добавляем маршруты по умолчанию в созданные пользовательские таблицы маршрутов. В таблицу isp1 добавим маршрут через первого провайдера, а в таблицу isp2 — через второго.

ip route add default via 1.1.1.2 table isp1
ip route add default via 2.2.2.2 table isp2

Добавление правил файрвола для метки соединений и пакетов, добавление правил маршрутизации.

Теперь нужно заставить ядро использовать в определённых случаях маршруты из пользовательских таблиц вместо маршрутов из таблицы main. Для этого будут использоваться правила файрвола для метки пакетов и правила маршрутизации. Добавляем правила файрвола:

# Следующие два правила метят новые соединения через разных провайдеров разными метками

iptables -t mangle -A PREROUTING -i eth0 -n state —state NEW -j CONNMARK —set-mark 10
iptables -t mangle -A PREROUTING -i eth1 -n state —state NEW -j CONNMARK —set-mark 11

# Следующее правило копирует метку соединения на метку пакета (чтобы все пакеты соединения использовали один WAN-интерфейс)

# Это нужно для пакетов, проходящих через данный хост, если данный хост не является шлюзом, это правило не нужно

iptables -t mangle -A PREROUTING -j CONNMARK —restore-mark

# Следующее правило аналогично предыдущему, но находится в цепочке OUTPUT и нужно для соединений, адресованных данному хосту

iptables -t mangle -A OUTPUT -j CONNMARK —restore-mark

# Следующие правила нужны для того, чтобы исходящие соединения, устанавливаемые с определённого IP-адреса данного хоста,

# использовали правильный шлюз, вне зависимости от шлюза по умолчанию в таблице main

iptables -t mangle -s 1.1.1.1 -A OUTPUT -j MARK —set-mark 10
iptables -t mangle -s 2.2.2.1 -A OUTPUT -j MARK —set-mark 11

В правилах выше были использованы метки 10 и 11 для соединений и пакетов, эти метки являются произвольными и никак не связаны с номерами пользовательских таблиц маршрутизации. Теперь нужно связать метки пакетов с таблицами маршрутов с помощью правил маршрутизации.

Правила маршрутизации являются основным инструментом PBR в Linux, они позволяют использовать для выбора маршрута пользовательские таблицы маршрутов вместо таблицы main, если пакет удовлетворяет определённым условиям. В данном случае будут использоваться правила, использующие таблицу isp1 для пакетов с меткой 10 и таблицу isp2 для пакетов с меткой 11.

Прежде, чем это будет сделано, нужно учесть одну проблему — в каждой из наших пользовательских таблиц есть только маршрут по умолчанию, это означает, что пакеты с меткой 10 или 11, адресованные локальной сети, будут отправляться через соответствующего провайдера, а не в локальную сеть.

Для избежания этой проблемы можно добавить маршрут в локальную сеть в каждую из пользовательских таблиц, но это создаст дополнительные проблемы, когда появятся ещё локальные сети или понадобится добавить статический маршрут — каждый новый маршрут, добавляемый в таблицу main, нужно будет вручную добавлять в пользовательские таблицы, иначе эти маршруты не будут доступны для пакетов с метками. Вместо этого можно добавить правила, которые будут использовать таблицу main для пакетов, адресованных в частные подсети IPv4 (убедитесь перед этим, что вам не нужно, чтобы метки влияли на маршрутизацию пакетов, адресованных в частные подсети).

Добавляем правила маршрутизации:

ip rule add fwmark 10 table isp1
ip rule add fwmark 11 table isp2
ip rule add to 192.168.0.0/16 table main
ip rule add to 10.0.0.0/8 table main
ip rule add to 172.16.0.0/12 table main

Обратите внимание на то, что правила маршрутизации нужно добавлять в обратном порядке.
Если потом выполнить команду «ip rule ls», мы увидим следующий вывод:

0: from all lookup local
32760: from all to 172.16.0.0/12 lookup main
32761: from all to 10.0.0.0/8 lookup main
32762: from all to 192.168.0.0/16 lookup main
32763: from all fwmark 0xb lookup isp2
32764: from all fwmark 0xa lookup isp1
32766: from all lookup main
32767: from all lookup default

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

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

Сохранение настроек

Внесённые настройки будут утеряны после перезагрузки сервера, нужно сохранить их.

Для сохранения правил файрвола достаточно выполнить команду:

service iptables save

Маршруты и правила маршрутизации нужно внести в соответствующие файлы настроек в директории /etc/sysconfig/network-scripts.

Записываем в файл /etc/sysconfig/network-scripts/route-eth0

default via 1.1.1.2 table isp1

Записываем в файл /etc/sysconfig/network-scripts/route-eth1

default via 2.2.2.2 table isp2

Записываем в файл /etc/sysconfig/network-scripts/rule-eth1

fwmark 10 table isp1
fwmark 11 table isp2
to 192.168.0.0/16 table main
to 10.0.0.0/8 table main
to 172.16.0.0/12 table main

Обратите внимание на то, что маршрут по умолчанию добавляется в каждую пользовательскую таблицу маршрутов после поднятия соответствующего сетевого интерфейса, это должно быть соблюдено.

Правила маршрутизации можно добавлять в любой момент, их можно было внести в файл rule-eth0 или rule-eth2 вместо rule-eth1.

Теперь внесённые настройки будут работать и после перезагрузки сервера.

Подписаться
Уведомить о
guest
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Остались вопросы?

Я - Компаниец Никита, менеджер компании Voxlink. Хотите уточнить детали или готовы оставить заявку? Укажите номер телефона, я перезвоню в течение 3-х секунд.

VoIP оборудование

ближайшие курсы

ближайшие Вебинары

ONLINE

10 доводов в пользу Asterisk

Распространяется бесплатно.

Asterisk – программное обеспечение с открытым исходным кодом, распространяется по лицензии GPL. Следовательно, установив один раз Asterisk вам не придется дополнительно платить за новых абонентов, подключение новых транков, расширение функционала и прочие лицензии. Это приближает стоимость владения станцией к нулю.

Безопасен в использовании.

Любое программное обеспечение может стать объектом интереса злоумышленников, в том числе телефонная станция. Однако, сам Asterisk, а также операционная система, на которой он работает, дают множество инструментов защиты от любых атак. При грамотной настройке безопасности у злоумышленников нет никаких шансов попасть на станцию.

Надежен в эксплуатации.

Время работы серверов некоторых наших клиентов исчисляется годами. Это значит, что Asterisk работает несколько лет, ему не требуются никакие перезагрузки или принудительные отключения. А еще это говорит о том, что в районе отличная ситуация с электроэнергией, но это уже не заслуга Asterisk.

Гибкий в настройке.

Зачастую возможности Asterisk ограничивает только фантазия пользователя. Ни один конструктор шаблонов не сравнится с Asterisk по гибкости настройки. Это позволяет решать с помощью Asterisk любые бизнес задачи, даже те, в которых выбор в его пользу не кажется изначально очевидным.

Имеет огромный функционал.

Во многом именно Asterisk показал какой должна быть современная телефонная станция. За многие годы развития функциональность Asterisk расширилась, а все основные возможности по-прежнему доступны бесплатно сразу после установки.

Интегрируется с любыми системами.

То, что Asterisk не умеет сам, он позволяет реализовать за счет интеграции. Это могут быть интеграции с коммерческими телефонными станциями, CRM, ERP системами, биллингом, сервисами колл-трекинга, колл-бэка и модулями статистики и аналитики.

Позволяет телефонизировать офис за считанные часы.

В нашей практике были проекты, реализованные за один рабочий день. Это значит, что утром к нам обращался клиент, а уже через несколько часов он пользовался новой IP-АТС. Безусловно, такая скорость редкость, ведь АТС – инструмент зарабатывания денег для многих компаний и спешка во внедрении не уместна. Но в случае острой необходимости Asterisk готов к быстрому старту.

Отличная масштабируемость.

Очень утомительно постоянно возвращаться к одному и тому же вопросу. Такое часто бывает в случае некачественного исполнения работ или выбора заведомо неподходящего бизнес-решения. С Asterisk точно не будет такой проблемы! Телефонная станция, построенная на Asterisk может быть масштабируема до немыслимых размеров. Главное – правильно подобрать оборудование.

Повышает управляемость бизнеса.

Asterisk дает не просто набор полезных функций, он повышает управляемость организации, качества и комфортности управления, а также увеличивает прозрачность бизнеса для руководства. Достичь этого можно, например, за счет автоматизации отчетов, подключения бота в Telegram, санкционированного доступа к станции из любой точки мира.

Снижает расходы на связь.

Связь между внутренними абонентами IP-АТС бесплатна всегда, независимо от их географического расположения. Также к Asterisk можно подключить любых операторов телефонии, в том числе GSM сим-карты и настроить маршрутизацию вызовов по наиболее выгодному тарифу. Всё это позволяет экономить с первых минут пользования станцией.