|
Ключ
Эта строка удалена.
Это слово было удалено. Это слово было добавлено.
Эта строка добавлена.
|
Изменения (15)
просмотр истории страницы... |
* зеркало - пассивная схема включения DPI * NAS - network access server, маршрутизатор, агрегирующий подключения абонентов |
* Border - центральный пограничный маршрутизатор провайдера, подключающийся к аплинкам |
|
|
h2. Схема сети |
... |
Обработка пересечений учитывает вхождение небольших подсетей в более крупные подсети. |
h2. Вариации этой схемы В принципе Reductor (зеркало) и Reductor (разрыв) можно совместить на одном сервере, но в таком случае возрастают требования к аппаратной части этого сервера. NAS-серверов может быть несколько и со всеми будет устанавливаться BGP сессия. Можно отправлять в списке анонсируемых также IP адреса популярных публичных DNS серверов, для этого необходимо добавить их в /app/reductor/var/lib/reductor/lists/provider/our.ip_http_plus для повышения надёжности фильтрации DNS трафика |
h2. Настройки |
|
h3. Carbon Reductor (разрыв) |
|
h4. Сеть |
Необходимо также настроить обратные маршруты до сетей абонентов на *reductor (разрыв)*. Это можно сделать настроив связку с NAS-серверами по OSPF, либо прописав статические маршруты (что удобнее - зависит от того как устроена сеть). Например NAS сервера доступны на Carbon Reductor через интерфейс eth2. Тогда его настройки приёма трафика будут выглядеть следующим образом. |
/app/reductor/cfg/userinfo/mirror.conf |
... |
{code} |
forward - новое поле в конфигурации приёма трафика, означает "роль" интерфейса. Возможные значения: * "forward" указывает, что трафик, пришедший на этот интерфейс в итоге должен быть смаршрутизирован после анализа. * "mirror" указывает, что трафик, пришедший на этот интерфейс должен быть отброшен после анализа. * Если роль не указана, считается что роль интерфейса - "mirror". |
Из этой строчки будет сгенерирован конфиг /etc/sysconfig/network-scripts/ifcfg-eth2 вида: |
... |
h4. app reductor |
# Включите сбор IP адресов ресурсов, блокируемых по HTTP. # Включите использование подсетей для синхронизации с маршрутизатором. |
|
|
h4. app bgp_blackhole |
# Включите BGP Blackhole # Настройте связку с BGP-"соседями" # Убедитесь, что корректно работает отправка blackhole-маршрутов, только после этого переходите к следующему пункту # Включите опцию "Асинхронная маршрутизация в разрыв" # Если необходимо, переопределите IP адрес шлюза для маршрутизируемого трафика (может пригодиться в очень сложной нестандартной схеме сети). По умолчанию он определяется автоматически. |
|
h4. Применение настроек На сервере по SSH выполните: {code} # сетевые настройки /etc/init.d/network restart # разбор реестра с новыми опциями для получения всех нужных IP адресов и их обработка chroot /app/reductor /usr/local/Reductor/bin/update.sh # перестроения firewall, запуск BGP/Zebra /etc/init.d/apps restart {code} h3. Carbon Reductor (зеркало) Обычная типовая настройка Carbon Reductor 8, описанная в этой документации. Ничего особенного делать не нужно. |
h3. NAS |
h4. Связка по BGP На NAS нужно настроить связку по BGP с *reductor (разрыв).* В случае с Linux - как это сделать описано в нашей [статье о настройке Remote Triggered Blackhole|http://docs.carbonsoft.ru/pages/viewpage.action?pageId=69926929#IPфильтрация%28BGPRemoteTriggeredBlackHole%29-ПримернастройкисоседаReductorапоBGP]. h4. Отключение rp_filter Также возможно потребуется отключение reverse path filtering (rp_filter), так как запросы на IP адреса запрещённых ресурсов будут уходить с одного интерфейса, а ответы на них будут приходить на другой. Сделать это можно следующим образом. Отключить на ходу: {code} for i in $(grep '' /proc/sys/net/ipv4/conf/*/rp_filter | awk -F: '{print $1}'); do echo 2 > $i done {code} и чтобы опция оставалась выключенной после перезагрузки, в /etc/sysctl.conf правим строчку: {code} net.ipv4.conf.default.rp_filter = 2 {code} |
h3. Border |
h2. Пример сети для тестирования в виртуальной среде |
|
h4. Настройка зеркала На Border нужно настроить отправку зеркала трафика для *reductor (зеркало).* Это необязательно должно быть именно на бордере, но этой самый простой для реализации пример. h4. Улучшение эффективности Наиболее надёжной и эффективной работы *reductor (зеркало)* можно добиться тремя способами: # Сложный, но более эффективный - *reductor (зеркало)* должен быть включен в абонентские сети и отсылать редиректы напрямую, например с помощью статических маршрутов. # Проще, но менее эффективно - *reductor (зеркало)* должен иметь OSPF-сессии со всеми NAS-серверами и отправлять редиректы абонентам через тот NAS-сервер к которому абонент подключен. # Значительно проще, но наименее эффективно - *reductor (зеркало)* перекладывает задачу маршрутизации редиректа к абоненту на плечи Border. В любой из этих схем основным фактором, влияющим на эффективность является число промежуточных машин (хопов), которые занимаются доставкой пакета с редиректом абоненту. Чем их меньше - тем быстрее будет реагировать reductor, тем надёжнее будет работать фильтрация. h2. Вариации этой схемы h3. Использование одного сервера Carbon Reductor В принципе Reductor (зеркало) и Reductor (разрыв) можно совместить на одном сервере, но в таком случае возрастают требования к аппаратной части этого сервера. *Ограничение* \- не получится отправлять в один интерфейс и зеркало трафика и трафик в разрыв. Обойти его можно с помощью VLAN, но лучше использовать отдельную сетевую карту или отдельный порт сетевой карты. h3. Несколько NAS-серверов NAS-серверов может быть несколько и со всеми будет устанавливаться BGP сессия. Просто укажите через пробел несколько NAS серверов в настройке "Список маршрутизаторов" при настройке BGP Blackhole. Формат: |
{code} |
<IP адрес>:<номер AS> [<IP адрес>:<номер AS>] ... {code} Пример: {code} 10.30.22.2:65002 10.30.22.3:65002 {code} h3. Фильтрация публичных DNS Можно отправлять в списке анонсируемых также IP адреса популярных публичных DNS серверов. Для этого необходимо добавить их в /app/reductor/var/lib/reductor/lists/provider/our.ip_http_plus для повышения надёжности фильтрации DNS трафика h2. Примечания Скорее всего доля трафика, анализируемого в разрыв будет довольно мала. Точных замеров мы пока не проводили, но есть предположение, что если, например, для захвата зеркала трафика вам была необходима хорошая 10Гбит/сек сетевая карта, то для маршрутизируемого трафика хватит двух 1Гбит/сек карт. Также возрастают требования к сетевой карте, обеспечивающей выход в интернет - желательна поддержка нескольких очередей и правильно настроенное распределение прерываний. h2. Пример сети для тестирования в виртуальной среде Пример, на котором успешно собиралась и тестировалась данная схема в виртуальной среде. {code:xhtml} |
vm_server: networks: |
... |