Наверное когда-нибудь я буду перечитывать эту запись, снисходительно улыбаясь, но сейчас данное решение проблемы мне кажется верным и приемлимым. Вкратце о задаче:
Сеть провайдера, имеется доступ в Интернет и пиринговый стык с популярными ресурсами (ВК, Google, Yandex и т.д.) - широкий и недорогой.
Было решено отдать абонентам все это сокровище без ограничения скорости.
Схема под кат'ом.
Организовано это было просто:
Итак, приступим.
.png)
Сеть провайдера, имеется доступ в Интернет и пиринговый стык с популярными ресурсами (ВК, Google, Yandex и т.д.) - широкий и недорогой.
Было решено отдать абонентам все это сокровище без ограничения скорости.
Схема под кат'ом.
Организовано это было просто:
- ставим отдельный маршрутизатор, который выполняет только функции NAT (без QoS) (7);
- поднимаем на нем сессию BGP c граничным маршрутизатором ;
- с граничного маршрутизатора (6) по BGP отдаем маршруты на автономные системы сетей, доступ в которые мы планируем предоставлять без ограничения скорости;
- с маршрутизатора (7) по OSPF отдаем полученные маршруты в ядро сети, после чего все клиентские запросы к этим пиринговым ресурсам маршрутизируются через роутер (7) вместо роутера (5), на котором скорости клиентов ограничиваются согласно тарифов;
- ...
- PROFIT!!!??? Как бы не так! Есть клиентские сетки (2), которые подключены на магистрали со скоростями менее 100 Мб/с, из этих сетей весь трафик нужно ограничивать по скорости, иначе клиенты сами себе "положат" канал, учитывая, что 70% трафика составляет детище Дурова.
Итак, приступим.
Схема
Примечание: В этой статье я не буду описывать настройку протоколов маршрутизации для разделения трафика. Будет рассмотрена только технология PBR (policy based routing)
Оборудование
Привожу список только того оборудования, которое будет настраиваться.
- Маршрутизатор ядра сети (3) - Cisco Catalyst 6509 под управлением IOS
- Сервер клиентского доступа (5) (NAT и QoS) - Linux-based router, дистрибутив Fedora Core.
Задача
Направить трафик из клиентской сети (2) таким образом, чтобы он в случае направления в глобальную сеть проходил только через сервер доступа (5), при этом при направлении трафика в служебную сеть (4) он должен направляться согласно таблицы маршрутизации роутера ядра (3).
Кроме того, будет здорово, если эта клиентская сеть не сможет общаться с другими клиентскими сетями (1), т.к. локальный трафик тоже не ограничивается.
Настройка
Смотрим, как у нас сейчас идет трафик на ВКонтакте из клиентской сети (2):
client@network2:~/$ traceroute vk.com traceroute to vk.com (87.240.131.120), 64 hops max 1 172.16.x.1 (CORE-3) 0.328ms 0.249ms 0.238ms 2 10.x.x.x (NAT7) 0.173ms 0.110ms 0.137ms 3 Z.Z.Z.Z (BORDER.GATEWAY6) 0.287ms 0.230ms 0.326ms -- SKIPPED -- 12 87.240.131.120 (87.240.131.120) 2.949ms 3.158ms 3.329msНа маршрутизаторе ядра сети (3) пишем ACL:
ip access-list extended LOW-UPLINK-NETWORK
! Запрещаем сеть служебных сервисов (4)
10 deny ip any 10.x.x.0 0.0.255.255
! Запрещаем админскую сеть, чтобы иметь возможность
! контролировать доступность хостов
20 deny ip any 172.16.x.0 0.0.0.255
! Разрешаем клиентские сети
30 permit ip 172.16.0.0 0.7.255.255 any
Пишем карту маршрутизации:
route-map NET2-TO-BRAS match ip address LOW-UPLINK-NETWORK set ip next-hop <Адрес_NAT'а(5)>
В Cisco IOS есть две похожие настройки для указания следующего хоста маршрутизации:
set ip next-hop <router_address> и set ip default next-hop <router_address>
вторая версия настройки говорит, что, сначала надо поискать маршрут в таблице маршрутизации и, если присутствует, отправить пакет по нему, в противном случае использовать default next-hop. Первой командой мы говорим, что безотносительно таблицы маршрутизации пакет должен быть отправлен на next-hop, что в нашем случае и требуется.
Теперь применяем route-map к IP интерфейсу клиентской сети, трафик которой мы хотим завернуть только на NAT (5):
interface Vlan <Номер_Клиентского_Vlan'а> ip policy route-map NET2-TO-BRAS
Вроде готово, проверим:
client@network2:~/$ traceroute vk.com traceroute to vk.com (87.240.131.120), 64 hops max 1 172.16.x.1 (CORE-3) 0.328ms 0.249ms 0.238ms 2 10.x.x.y (NAT-5) 0.173ms 0.110ms 0.137ms 3 10.x.x.x (NAT-7) 0.173ms 0.110ms 0.137ms 4 Z.Z.Z.Z (BORDER.GATEWAY-6) 0.287ms 0.230ms 0.326ms -- SKIPPED -- 13 87.240.131.120 (87.240.131.120) 2.949ms 3.158ms 3.329ms
... оппа! А что это у нас 3-им хопом? Неужели опять NAT (7)? И не удивительно, ведь NAT (7) отдает маршруты на пиринговые сети в OSPF, а поскольку оба маршрутизатора находятся в одной магистральной сети, то данный маршрут будет вычислен OSPF как кратчайший.
На сервере клиентского доступа (5) для обеспечения протокола OSPF у нас используется Quagga, в которой нет возможности фильтровать полученные по OSPF маршруты (что, собственно и верно, т.к. в этом протоколе передаются не сами маршруты, а состояния каналов [LSA], другой демон маршрутизации BIRD вроде как поддерживает такую фильтрацию, но не менять же из за этого зебру на птичку). Поэтому, мы снова применим policy based routing но уже на linux-роутере.
Итак, определим дополнительную таблицу маршрутизации:
На сервере клиентского доступа (5) для обеспечения протокола OSPF у нас используется Quagga, в которой нет возможности фильтровать полученные по OSPF маршруты (что, собственно и верно, т.к. в этом протоколе передаются не сами маршруты, а состояния каналов [LSA], другой демон маршрутизации BIRD вроде как поддерживает такую фильтрацию, но не менять же из за этого зебру на птичку). Поэтому, мы снова применим policy based routing но уже на linux-роутере.
Для поддержки ядром policy-routing оно должно быть собрано с включенными опциями IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) и IP: policy routing (CONFIG_IP_MULTIPLE_TABLES), находящимися в разделе Networking support -> Networking options -> TCP/IP networking[отсюда].Обычно, в Linux для маршрутизации используется одна таблица, в нашем случае нам потребуется две: одна для всех клиентов, в которой содержатся все маршруты (Можно было бы спросить "А почему бы не выключить OSPF и не написать нужные маршруты статикой", однако, в глобальной таблице есть и другие маршруты кроме пиринга) и вторая - для клиентов из сетей (2), в которой будет только один маршрут по умолчанию на граничный маршрутизатор (6).
Итак, определим дополнительную таблицу маршрутизации:
nat-5:~/# echo "100 specDefault" >> /etc/iproute2/rt_tables
пишем в нее маршрут (адрес роутера, тот же, что и в основной таблице маршрутизации для дефолта):
nat-5:~/# ip route add default table specDefault \
via <Адрес_роутера_по_умолчанию>
назначаем фильтр, при трафике с каких сетей будет использоваться эта таблица
nat-5:~/# ip rule add from <Клиентская_сеть(2)/префикс> table specDefault
и проверяем из клиентской сети
client@network2:~/$ traceroute vk.com traceroute to vk.com (87.240.131.120), 64 hops max 1 172.16.x.1 (CORE-3) 0.328ms 0.249ms 0.238ms 2 10.x.x.y (NAT-5) 0.173ms 0.110ms 0.137ms 3 Z.Z.Z.Z (BORDER.GATEWAY-6) 0.287ms 0.230ms 0.326ms -- SKIPPED -- 12 87.240.131.120 (87.240.131.120) 2.949ms 3.158ms 3.329ms
Все? Нет. Надо бы сделать так, чтобы после перезагрузки роутера конфигурация восстановилась. В Red Hat based дистрибутивах для этого служат файлы конфигурации rule-<имя_интерфейса> и route-<имя_интерфейса>, которые располагаются в каталоге /etc/sysconfig/network-scripts/
В нашем случае интерфейс eth0, поэтому создаем два файлика с таким содержимым:
nat-5:~/# cat /etc/sysconfig/network-scripts/route-eth0 default via <Адрес_роутера_по_умолчанию> table specDefault cat /etc/sysconfig/network-scripts/rule-eth0 from <Клиентская_сеть(2)/префикс> lookup specDefault
Вот теперь все.
Ссылки
Более подробно про policy rouuting в Linux можно прочитать тут: http://habrahabr.ru/post/108690/ и здесь http://lartc.org/howto/lartc.rpdb.html
Про Cisco PBR можно почитать здесь http://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/47121-pbr-cmds-ce.html
Комментариев нет:
Отправить комментарий