...
Пути до шаблонов менять не требуется, это редкий случай, когда техническая поддержка подтвердит, что другого способа настроить что-то специфичное нет.
Пароли установить отличные от стандартных и безопасные.
Router ID, как правило, совпадает с IP адресом Carbon Reductor.
Список соседей по BGP имеет формат:
{code}
IP1:AS1 IP2:AS2
{code}
разделитель между записями - пробел.
Нажать назад, применить настройки:
!Screen Shot 2017-03-14 at 14.12.30.png|border=1!
zebra и bgpd должны перезапуститься без ошибок:
!Screen Shot 2017-03-14 at 14.12.36.png|border=1!
|
...
bgpd.conf
Здесь:
* router bgp 65002 - номер AS маршрутизатора.
* bgp router-id 10.0.0.2 - его IP, с которым он доступен Carbon Reductor'у
* 10.0.0.1 - IP адрес Carbon Reductor
* 192.168.255.255 - это IP-адрес, куда будет направляться запрещённый трафик.
{code}
hostname border
password password
log file /var/log/quagga/bgpd.log
!
router bgp 65002
bgp router-id 10.0.0.1
redistribute static
neighbor 10.0.0.2 remote-as 65001
neighbor 10.0.0.2 ebgp-multihop 8
neighbor 10.0.0.2 soft-reconfiguration inbound
neighbor 10.0.0.2 route-map BLACKHOLE ! Это требуется, чтобы запрещённый трафик не шёл на редуктор, а дропался на самом роутере.
!
ip prefix-list ANY permit any
!
route-map BLACKHOLE permit 10
match ip address prefix-list ANY
set ip next-hop 192.168.255.255
set local-preference 10
set community 65002:666 additive
!
line vty
!
{code}
zebra.conf
{code}
hostname border
interface lo666
ip address 192.168.255.255/32
!
ip route 192.168.255.255/32 Null0 !Можно заменить Null0 на reject, тогда будет отправляться host unrecheable в ответ
!
{code}
Можно настроить доступ к сессию BGP и без создания интерфейса lo666 и из route-map убрать "set ip next-hop 192.168.255.255". Тогда запрещённый трафик будет идти на редуктор и дропаться уже там.
{info}
Интеграции с другими роутерами приведены в статье: [https://github.com/carbonsoft/reductor_bgp_rtbh]
{info}
h2. Подводные камни и как их обходить
20.09.2017. Настройка BGP RTBH приводит к появлению Null-маршрутов до запрещённых IP на самом редукторе. Это приводит к тому, что пришедшие в зеркало трафика пакеты, идущие на эти IP адреса не анализируются. В принципе в полностью рабочей схеме это не страшно - пакеты всё равно будут DROP'нуты на стороне бордера. Тем не менее, если что-то пойдёт не так (разорвётся соединение с роутером, не проверили настройки итд) то бордер пакеты отбрасывать не будет, а редуктор не будет их анализировать и в итоге получим пропуск.
Сейчас мы ищем решение, которое позволит обойти эту проблему. Временным решением может быть разворачивание отдельного редуктора на виртуальной машине (мы дадим бесплатную лицензию), которая занимается тем, что скачивает и обрабатывает списки, к трафику не имеет никакого отношения, а основное её предназначение - это контейнер BGP Blackhole. Таким образом получаем двойную фильтрацию и повышение надёжности: роутер дропает пакеты, а основной редуктор посылает ресеты на все запрещённые IP адреса (в итоге пользователю не надо будет дожидаться таймаута установки соединения). Можно это развернуть не на виртуальной машине, а не резервном сервере с Carbon Reductor, который также занимается обработкой того же зеркала трафика.
02.10.2017
Найдено решение с запуском quagga версии 1.1.1 c добавлением нескольких таблиц маршрутизации. Благодаря этому не появляется null-маршрутов в основной таблице на редукторе. Но эту схему требуется ещё проверить.
|
