1. Статьи
Заметки пользователей
04.07.2017 08:40
PDF
9186
15

Перенаправление трафика на фильтрацию (URL, Layer 7, etc.) с применением BGP FlowSpec

Реализация на сети технологий MPLS и VPN позволяет реализовать гибкую схему управляемого перенаправления трафика на узлы фильтрации Layer7, URL, etc. Узлы фильтрации могут быть интегрированы в общую геораспределенную сеть ISP, оператора защиты от DDoS или, в зависимости от особенностей топологии сети, может быть реализована централизованная схема фильтрации.

Схема типового узла приведена ниже:

Перенаправление трафика на фильтрацию (URL, Layer 7, etc.) с применением BGP FlowSpec

В схеме без фильтрации по L7 трафик из WAN поступает через форвардинг таблицы default.inet.0 на устройство фильтрации трафика по Layer 3 и Layer 4. Очищенный трафик направляется в сеть клиента через vrf protected.

Для перенаправления трафика на L7 фильтрацию создан новый routing-instances proxy c RD 65000:200, в котором маршрутная информация распространяется между всеми маршрутизаторами в сети, в iBGP включена кроме AFI inet-vpn-unicast дополнительно AFI inet-vpn-flow в MP-BGP, позволяющая передавать информацию FlowSpec в соответствующем vrf.

PE-1> show bgp neighbor 192.168.1.2 | match "NLRI for this session: |Table|Received prefixes:| Accepted prefixes:"
NLRI for this session: inet-unicast inet-vpn-unicast l2vpn inet6-labeled-unicast inet-vpn-flow

Table proxy.inet.0 Bit: b0000
Received prefixes: 4
Accepted prefixes: 4
Table protected.inetflow.0 Bit: c0000
Received prefixes: 1
Accepted prefixes: 1


Конфигурация routing-instances proxy приведена ниже:

PE-1>show configuration routing-instances proxy
instance-type vrf;
interface ae0.800;
interface ae0.801;
interface ae0.924;
route-distinguisher 65000:200;
vrf-target {
import target:65000:200;
export target:65000:200;
}
vrf-table-label;
routing-options {
static {
route 0.0.0.0/0 {
next-table protected.inet.0;
preference 200;
}
}
flow {
term-order standard;
}
}
protocols {
bgp {
import default-proxy;
export reject-all;
group Redirect {
type external;
passive;
peer-as 65501;
multipath;
neighbor 10.0.2.202 {
local-address 10.0.2.201;
}
neighbor 10.0.2.206 {
local-address 10.0.2.205;
}
}
}
}

В конфигурации протокола BGP routing-instances proxy указаны два neighbors устройств фильтрации по Layer7 для обеспечения избыточности одного узла.

Перенаправление трафика на L7 фильтрацию осуществляется следующим образом:
С Control Server (сервер управления), имеющего поднятую eBGP-сессию с family inet flow в routing-instances protected анонсируется по FlowSpec маршрут с соответствующими атрибутами для перенаправления трафика из routing-instances protected в routing-instances proxy. Пример ниже:
 

192.168.200.1*,proto=6,dstport=80,dscp=48/term:1
*[BGP/170] 4d 19:59:37, localpref 100, from 10.22.2.2
AS path: 65501 I, validation-state: unverified
Fictitious


Данный анонс распространяется по всем маршрутизаторам сети по inet-vpn-flow.

Конфигурация протокола BGP маршрутизатора для FlowSpec с Control Server приведена ниже:

PE-1> show configuration routing-instances protected protocols bgp group Servers neighbor 10.22.2.2
description "Proxy FlowSpec";
passive;
import Import_proxy_flowspec;
family inet {
flow {
prefix-limit {
maximum 200;
teardown;
}
no-validate Redirect-to-proxy;
}
}
export reject-all;
peer-as 65501;


Параметр no-validate позволяет FlowSpec маршрутам быть активными без валидации данных анонсов в inet.0. Примененное к neighbor policy осуществляет match по передаваемому FlowSpec community и перенаправляет трафик в routing-instances proxy. Пример конфигурации policy и community приведен ниже:

PE-1> show configuration policy-options policy-statement Redirect-to-proxy
term 1 {
from community redirect;
to instance proxy;
then accept;
}
term 2 {
then accept;
}
{master}
PE-1> show configuration policy-options community redirect
members redirect:65000:200;
{master}


Далеко не положительной особенностью является общий forwarding для всех instances, участвующих во FlowSpec, что приводит к постоянному циклическому форвардингу пакетов между instances, где они "умирают" по ТТL. Решением данной проблемы стало раскраска трафика маркерами dscp на выходе устройств фильтрации Layer3,4 и сброс этих маркеров для трафика на выходе vrf proxy. Данное решение реализовано применением интерфейсных firewall filters и анонсом во FlowSpec match dscp, совпадающего с раскраской dscp на выходе устройств фильтрации Layer3,4. Примеры обоих фильтров приведены ниже:

PE-1> show configuration firewall filter mark_dscp_proxy
term 1 {
from {
protocol tcp;
destination-port [ 80 483 ];
}
then {
accept;
dscp cs6;
}
}
term 2 {
then accept;
}

PE-1> show configuration firewall filter clear_dscp
term 1 {
from {
protocol tcp;
destination-port [ 80 483 ];
}
then {
accept;
dscp cs0;
}
}
term 2 {
then accept;
}
{master}


Для маршрутизации трафика на фильтры Layer7 с каждым из них поднята BGP-сессия, в которой всеми фильтрами анонсируется маршрут 0.0.0.0/0, являющийся anycast и основным маршрутом в таблице:

PE-2> show route table proxy.inet.0 0/0 exact
roxy.inet.0: 6 destinations, 9 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[BGP/170] 5d 20:56:48, localpref 100, from 192.168.1.4
AS path: 65501 I, validation-state: unverified
> to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE4
to 10.10.48.1 via ae0.1062, label-switched-path BE-PE2-PE4
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE4
[BGP/170] 5d 21:01:12, localpref 100, from 192.168.1.3
AS path: 65501 I, validation-state: unverified
> to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE3
to 10.10.48.1 via ae0.1062, label-switched-path BE-PE2-PE3
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE3
[BGP/170] 5d 21:32:11, localpref 100, from 192.168.1.1
AS path: 65501 I, validation-state: unverified
> to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE1
to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE1-1
to 10.10.68.1 via ae0.1064, label-switched-path BE-PE2-PE1
to 10.10.48.1 via ae0.1062, label-switched-path PRIORITY-PE2-PE1
to 10.10.68.1 via ae0.1064, label-switched-path PRIORITY-PE2-PE1-1
[Static/200] 5d 20:54:19
to table protected.inet.0


В данном vrf существует статический маршрут 0.0.0.0/0 с более высоким preference 200, и с next-table protected.inet.0, который служит bypass-маршрутом в случае каких-либо проблем с устройствами фильтрации Layer7.

15 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews

Материал:

Реализация на сети технологий MPLS и VPN позволяет реализовать гибкую схему управляемого перенаправления трафика на узлы фильтрации Layer7, URL, etc.

 

Полный текст

ne-vlezay80
ne-vlezay80

Фильтрующее устройство лучше всего ставить на уровне второй модели OSI. На счёт MPLS - для него пойдёт не всякое фильтрующее устройство. Например extfilter(https://github.com/max197616/extfilter) для фильтрации mpls-потока не подойдёт.

tec1
tec1

Фильтрующее устройство лучше всего ставить на уровне второй модели OSI. На счёт MPLS - для него пойдёт не всякое фильтрующее устройство. Например extfilter(https://github.com/max197616/extfilter) для фильтрации mpls-потока не подойдёт.

 

"extFilter - Программа для блокирования сайтов из списка РКН с использованием DPDK. Программа осуществляет блокировку сайтов путем анализа зеркалированного трафика от пользователей."

Как Вы себе представляете "зеркалированного трафика от пользователей" и его доставку в больших операторских сетях?

MPLS в сочетании с MP-BGP и BGP Flow-Spec в данной статье рассмотрен исключительно как транспорт для доставки перенаправленного трафика.

Tosha
Tosha

Как Вы себе представляете "зеркалированного трафика от пользователей" и его доставку в больших операторских сетях?

Имхо технически правильно такое реализовывать на региональных узлах. Вот стоит в регионе узел связи - на нем и СОРМ и фильтрация. И всю область или район обрабатывает.

tec1
tec1

Как Вы себе представляете "зеркалированного трафика от пользователей" и его доставку в больших операторских сетях?

Имхо технически правильно такое реализовывать на региональных узлах. Вот стоит в регионе узел связи - на нем и СОРМ и фильтрация. И всю область или район обрабатывает.

 

 

Естественно, можно все обрабатывать на региональных узлах, зеркалировать через сплиттеры, или на коммутаторах, ну еще и несколько стоек серверов с портами 10GE, чтоб обработать весь трафик. :)

zhenya`
zhenya`

Фильтрующее устройство лучше всего ставить на уровне второй модели OSI. На счёт MPLS - для него пойдёт не всякое фильтрующее устройство. Например extfilter(https://github.com/max197616/extfilter) для фильтрации mpls-потока не подойдёт.

Нет проблем жевать ему трафик с мплс метками. Мплс не означает, что пейлоад поменялся.

YuryD
YuryD

Как Вы себе представляете "зеркалированного трафика от пользователей" и его доставку в больших операторских сетях?

Имхо технически правильно такое реализовывать на региональных узлах. Вот стоит в регионе узел связи - на нем и СОРМ и фильтрация. И всю область или район обрабатывает.

Я это триста лет назад придумал. Для оператора - хорошо, для ловящих террористов - плохо. Регион - он большой, масса народу за нат.

zhenya`
zhenya`

Естественно снимать трафик надо до нат

Sergey Gilfanov
Sergey Gilfanov

Я это триста лет назад придумал. Для оператора - хорошо, для ловящих террористов - плохо. Регион - он большой, масса народу за нат.

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

ne-vlezay80
ne-vlezay80

Я это триста лет назад придумал. Для оператора - хорошо, для ловящих террористов - плохо. Регион - он большой, масса народу за нат.

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

Одного забанят - все будут страдать