Асинхронная маршрутизация

Skip to end of metadata
Go to start of metadata
Вы просматриваете старую версию данной страницы. Смотрите текущую версию. Сравнить с текущим  |   просмотр истории страницы
<< Предыдущий Версия 16 Следующий >>

Наиболее правильным способом обеспечить надёжность фильтрации при больших объёмах трафика является комбинирование асинхронной маршрутизации с обработкой зеркала трафика.

Словарь

Несколько синонимов для лучшего понимания:

  • разрыв - активная схема включения DPI
  • зеркало - пассивная схема включения DPI
  • NAS - network access server, маршрутизатор, агрегирующий подключения абонентов
  • Border - центральный маршрутизатор провайдера, подключающийся к аплинкам

Схема сети

Описание

В данной схеме используется два сервера Carbon Reductor 8.

Используемые подсети:

  • абонент-NAS - 
  • NAS-Reductor (разрыв)
  • NAS, Reductor (разрыв) и Reductor (зеркало) - Border

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

Reductor (зеркало) анализирует весь исходящий трафик, зеркалируемый с Border'а.

Reductor (разрыв) анонсирует известные ему IP адреса запрещённых ресурсов на NAS с помощью BGP. При этом фильтрации по самим IP адресам в большей части случаев не происходит, на Reductor (разрыв) производится анализ пакетов и решение принимается на основе их содержимого. Такая схема повышает надёжность фильтрации, устраняя небольшую вероятность потерь исходящих от абонентов пакетов зеркалирующим оборудованием и потерь отправленных редиректов. В этой схеме не решается проблема с ресурсами, часто изменяющими свой IP адрес - они анализируются в зеркале трафика. Основная проблема, которую решает эта схема - сделать надёжным анализ 90-98% ресурсов, IP адреса которых известны.

Какие адреса анонсирует reductor (разрыв):

  • ip_block_subnet - список IP адресов подсетей, которые должны быть заблокированы по всем портам и протоколам.
  • ip_forward - список IP адресов, которые должны отправляться в разрыв через reductor.
    • на текущий момент этот список формируется из списков ip_http_plus, ip_https и ip_https_plus.

Адреса подсетей в этих двух списках не должны пересекаться. Это обеспечивается системой обработки списков Carbon Reductor 8, приоритет отдаётся ip_block_subnet.

Обработка пересечений учитывает вхождение небольших подсетей в более крупные подсети.

Настройки

Carbon Reductor (разрыв)

Сеть

Необходимо также настроить обратные маршруты до сетей абонентов на reductor (разрыв). Это можно сделать настроив связку с NAS-серверами по OSPF, либо прописав статические маршруты (что удобнее - зависит от того как устроена сеть). Например NAS сервера доступны на Carbon Reductor через интерфейс eth2. Тогда его настройки приёма трафика будут выглядеть следующим образом.

/app/reductor/cfg/userinfo/mirror.conf

eth2 - 10.30.20.1/24 forward

forward - новое поле в конфигурации приёма трафика, означает "роль" интерфейса. Возможные значения:

  • "forward" указывает, что трафик, пришедший на этот интерфейс в итоге должен быть смаршрутизирован после анализа.
  • "mirror" указывает, что трафик, пришедший на этот интерфейс должен быть отброшен после анализа.
  • Если роль не указана, считается что роль интерфейса - "mirror".

Из этой строчки будет сгенерирован конфиг /etc/sysconfig/network-scripts/ifcfg-eth2 вида:

IPADDR=10.30.20.1
PREFIX=24
DEFROUTE=no
ONBOOT=yes
BOOTPROTO=static
NM_CONTROLLED=no

В /etc/sysconfig/network-scripts/route-eth2 нужно вручную прописать маршруты вида:

  • 10.30.33.0/24 - сеть абонентов
  • 10.30.32.0.24 - сеть абонентов
  • 10.30.20.2 - NAS, через который она доступна

конфиг будет выглядеть так:

10.30.32.0/24 via 10.30.20.2
10.30.33.0/24 via 10.30.20.2

app reductor

  1. Включите сбор IP адресов ресурсов, блокируемых по HTTP.
  2. Включите использование подсетей для синхронизации с маршрутизатором.

app bgp_blackhole

  1. Включите BGP Blackhole
  2. Настройте связку с BGP-"соседями"
  3. Убедитесь, что корректно работает отправка blackhole-маршрутов, только после этого переходите к следующему пункту
  4. Включите опцию "Асинхронная маршрутизация в разрыв"
  5. Если необходимо, переопределите IP адрес шлюза для маршрутизируемого трафика (может пригодиться в очень сложной нестандартной схеме сети). По умолчанию он определяется автоматически.

Применение настроек

На сервере по SSH выполните:

# сетевые настройки
/etc/init.d/network restart

# разбор реестра с новыми опциями для получения всех нужных IP адресов и их обработка
chroot /app/reductor /usr/local/Reductor/bin/update.sh

# перестроения firewall, запуск BGP/Zebra
/etc/init.d/apps restart

Carbon Reductor (зеркало)

Обычная типовая настройка Carbon Reductor 8, описанная в этой документации. Ничего особенного делать не нужно.

NAS

Связка по BGP

На NAS нужно настроить связку по BGP с reductor (разрыв).

В случае с Linux - как это сделать описано в нашей статье о настройке Remote Triggered Blackhole.

Отключение rp_filter

Также возможно потребуется отключение reverse path filtering (rp_filter), так как запросы на IP адреса запрещённых ресурсов будут уходить с одного интерфейса, а ответы на них будут приходить на другой. Сделать это можно следующим образом. Отключить на ходу:

for i in $(grep '' /proc/sys/net/ipv4/conf/*/rp_filter | awk -F: '{print $1}'); do
  echo 2 > $i
done

и чтобы опция оставалась выключенной после перезагрузки, в /etc/sysctl.conf правим строчку:

net.ipv4.conf.default.rp_filter = 2

Border

На Border нужно настроить отправку зеркала трафика для reductor (зеркало).

Это необязательно должно быть именно на бордере, но этой самый простой для реализации пример.

Наиболее надёжной и эффективной работы reductor (зеркало) можно добиться тремя способами:

  1. Сложный, но более эффективный - reductor (зеркало) должен быть включен в абонентские сети и отсылать редиректы напрямую, например с помощью статических маршрутов.
  2. Проще, но менее эффективно - reductor (зеркало) должен иметь OSPF-сессии со всеми NAS-серверами и отправлять редиректы абонентам через тот NAS-сервер к которому абонент подключен.
  3. Значительно проще, но наименее эффективно - reductor (зеркало) перекладывает задачу маршрутизации редиректа к абоненту на плечи Border.

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

Вариации этой схемы

Использование одного сервера Carbon Reductor

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

Ограничение - не получится отправлять в один интерфейс и зеркало трафика и трафик в разрыв.

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

Несколько NAS-серверов

NAS-серверов может быть несколько и со всеми будет устанавливаться BGP сессия.

Просто укажите через пробел несколько NAS серверов в настройке "Список маршрутизаторов" при настройке BGP Blackhole.

Формат:

<IP адрес>:<номер AS> [<IP адрес>:<номер AS>] ...

Пример:

10.30.22.2:65002 10.30.22.3:65002

Фильтрация публичных DNS

Можно отправлять в списке анонсируемых также IP адреса популярных публичных DNS серверов.

Для этого необходимо добавить их в /app/reductor/var/lib/reductor/lists/provider/our.ip_http_plus для повышения надёжности фильтрации DNS трафика

Примечания

Скорее всего доля трафика, анализируемого в разрыв будет довольно мала.

Точных замеров мы пока не проводили, но есть предположение, что если, например, для захвата зеркала трафика вам была необходима хорошая 10Гбит/сек сетевая карта, то для маршрутизируемого трафика хватит двух 1Гбит/сек карт.

Также возрастают требования к сетевой карте, обеспечивающей выход в интернет - желательна поддержка нескольких очередей и правильно настроенное распределение прерываний.

Пример сети для тестирования в виртуальной среде

Пример, на котором успешно собиралась и тестировалась данная схема в виртуальной среде.

vm_server:
  networks:
    management: 10.35.0.0/16	# сеть управления, например для подключения по SSH
    abonent: 10.30.20.0/24	# абонентская сеть
    reductor_route: 10.30.21.0/24	# сеть между NAS и Reductor, через которую он шлёт трафик для анализа в разрыв
    border: 10.30.22.0/24		# подключение к Border, выход в интернет для всех серверов сети (NAS, Reductor)
  vms:
    abonent:			# тестовый абонент, с него можно совершать запросы и смотреть tcpdump'ом как он идёт по сети
      network:
        abonent:		# default route, выходим в интернет через NAS
          eth0: 10.30.20.2/24 via 10.30.20.1
        management: 		# нужен чтобы подключаться к тестовой машине по SSH
          eth1: 10.35.15.18/16
    gate:			# NAS-сервер
      network:
        border:			# default route, выходим в инет через бордер
          eth1: 10.30.22.2/24 via 10.30.22.1
        abonent:		# агрегация абонентов
          eth2: 10.30.20.1/24
        reductor_route:		# линк к Carbon Reductor, здесь живёт BGP-сессия с ним
          eth3: 10.30.21.2/24
        management:		# подключение к виртуалке по SSH с ноутбука
          eth0: 10.35.140.213/16
    border:			# бордер, центральный маршрутизатор, точка подключения к аплинку(ам)
      network:
        management:		# defroute, по совместительству подключение к виртуалке по SSH
          eth0: 10.35.140.211/16 via 10.35.0.4
        border:			# подключение NAS-серверов к нему, должны быть обратные маршруты до сетей абонентов
          - eth1
          - 10.30.22.1/24
          - 10.30.20.0/24 via 10.30.22.2
    reductor:			# Carbon Reductor 8
      network:
        border:			# default route, выход в интернет
          eth1: 10.30.22.3/24 via 10.30.22.1
        reductor_route:
          eth2:			# линк к NAS-серверу(ам), здесь живёт BGP-сессия с ним(и), + короткий обратный маршрут к абонентам
          - 10.30.21.1/24
          - 10.30.20.0/24 via 10.30.21.2
        management:		# нужен чтобы подключаться к тестовой машине по SSH
          eth0: 10.35.140.215
Введите метки, чтобы добавить к этой странице:
Please wait 
Ищите метку? просто начните печатать.