Фильтр анонсируемых адресов

Продолжаю делать записи для себя. На этот раз потребовалось отфильтровать роуты, отдаваемые другим. OSPF для этого не подходит: стандарт такого попросту не предусматривает. Значит, переключаемся на BGP. Минимальный конфиг для FRR

!
router bgp 65000
 bgp router-id 10.0.0.2
 no bgp ebgp-requires-policy
 neighbor 10.0.0.3 remote-as 65000
 !
 address-family ipv4 unicast
  redistribute connected
  redistribute static
  neighbor 10.0.0.3 next-hop-self
 exit-address-family
exit
!

На другой стороне есть адрес 6.7.8.9, котрый не должен попасть на этот роутер.

!
ip route 6.7.8.9/32 10.1.0.254
!
router bgp 65000
 bgp router-id 10.0.0.3
 no bgp ebgp-requires-policy
 neighbor 10.0.0.2 remote-as 65000
 !
 address-family ipv4 unicast
  redistribute connected
  redistribute static
  neighbor 10.0.0.2 next-hop-self
  neighbor 10.0.0.2 prefix-list nobad-out out
 exit-address-family
exit
!
ip prefix-list nobad-out seq 5 deny 6.7.8.9/32 le 32
ip prefix-list nobad-out seq 10 permit 10.1.0.0/24 le 32
!

Проверяем

router2# show ip route bgp
Codes: K - kernel route, C - connected, S - static, R - RIP,
       O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
       T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued, r - rejected, b - backup
       t - trapped, o - offload failure

B>* 10.1.0.0/24 [200/0] via 10.0.0.3, ens19, weight 1, 00:16:06

ВНИМАНИЕ: правка “на живую” permit-list не приведет к перечитыванию правил на другой стороне. Надо вручную в router bgp прицепить-отцепить их. Почему так – хз.

Вариант лечения: не важно где сказать clear ip bgp 10.0.0.3 (ессно, на передатчике адрес приемника и наоборот), это сбросит сессию bgp и заставит перечитать роуты.

MultiWAN без боли и шума

О, сколько боли в слове MultiWAN! Стоит погуглить что-нибудь типа “есть два провайдера, как сделать так, чтобы можно было пользоваться одновременно или использовать второй как бекапный”, так сразу высыпается куча советов про метрики, маркировку трафика с помощью iptables и так далее. Правда, в последнее время все поутихло, но это потому, что в большинстве прошивок для домашних роутеров наконец-то доделали этот функционал.

Но я-то другой! У меня закидоныпросы! Вот прямо сейчас мне надо разрулить аж трех “провайдеров” на одной точке. Плюс пустить один из адресов через одного провайдера… В общем, попробовал я сначала натыкать галочек в любимом кинетике, потом сдался в сторону {pf|opn}sense, но и так не преуспел… Нет, наверняка можно было допинать, но я устал и сдался.

Итак, первоначальные условия. Есть три провайдера: через сотовую связь, ADSL и GPON. Работают одновременно. Рядом стоит сервер, который легко потянет кучу виртуалок. Необходимо клиентов (то есть меня) пускать в интернет, при этом приоритет gpon, adsl, сотик. Но один из служебных маршрутов должен уходить через ADSL. Вроде бы просто, да?

Для начала я вообще решил проверить, а возможно ли это без боли. Для этого я сделал стенд из трех виртуалок. Две я обозвал router1 и router2, а клиента – естественно client.

internet - (ens18)router1(ens19) - 10.0.0.1 - network
internet - (ens18)router2(ens19) - 10.0.0.2 - network
                  client (ens19) - 10.0.0.3 - network

Я опускаю настройку роутеров и клиента. Все друг друга видят, на роутерах включен форвард пакетов и SNAT, в общем, все работает на ручном приводе хорошо. Теперь необходима автоматика.

Ставлю на каждый хост FRR. Редактирую /etc/frr/daemons на предмет включения ospfd и запускаю. Далее скармливаю на всех хостах одну и ту же конструкцию, только меняю router id

!
interface ens18
 ip ospf passive
exit
!
interface ens19
 ip ospf dead-interval 30
exit
!
router ospf
 ospf router-id 10.0.0.1
 network 10.0.0.0/24 area 0.0.0.0
exit
!

Никакой авторизации и прочих заморочек. Поднимаю OSPF, запрещаю ему спамить в сторону провайдера и говорю, что все в сети 10/24 – наше. Проверяю, что роутеры видят друг друга.

client# show ip ospf neighbor 

Neighbor ID     Pri State           Dead Time Address         Interface                        RXmtL RqstL DBsmL
10.0.0.1          1 Full/DR           27.376s 10.0.0.1        ens19:10.0.0.3                       0     0     0
10.0.0.2          1 Full/Backup       28.362s 10.0.0.2        ens19:10.0.0.3                       0     0     0

В принципе, теперь можно расставлять роуты куда надо и радоваться жизни. Но мне-то надо рулить default роутом. И тут засада: по-умолчанию, чтобы не расхреначить все, роутеры по умолчанию дропают роуты на 0.0.0.0/0. Можно, конечно, воспользоваться хаком имени OpenVPN и анонсировать роуты 0.0.0.0/1 и 128.0.0.0/1, но это не наш метод. Немного погуглив, выянил, что достаточно добавить default-information originate always в секцию router ospf и все получится. Дескать, я edge/border/ваще_крутой роутер и ходи через меня.

client# show ip ospf route 
============ OSPF network routing table ============
N    10.0.0.0/24           [1] area: 0.0.0.0
                           directly attached to ens19

============ OSPF router routing table =============
R    10.0.0.1              [1] area: 0.0.0.0, ASBR
                           via 10.0.0.1, ens19

============ OSPF external routing table ===========
N E2 0.0.0.0/0             [1/1] tag: 0
                           via 10.0.0.1, ens19

И действительно, стоило мне такое сказать, как client тут же все увидел и обновил. Добавляю ту же строку в конфиг второго. Вуаля!

root@client:~# ip r
default nhid 22 proto ospf metric 20 
	nexthop via 10.0.0.1 dev ens19 weight 1 
	nexthop via 10.0.0.2 dev ens19 weight 1 
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 

Клиент прописал себе оба роута и казалось бы наступила красота. И даже все заработало, как положено: если один из роутеров исчезал или я дропал на нем интерфейс, то соответствующий роут исчезал тоже. И тут я познал боль (правда, небольшую, на уровне фейспалма)

В чем боль? А боль возникла из-за того, что для клиента оба роутера видны через один интерфейс. И он совершенно справедливо полагает, что между ними нет разницы. А если нет разницы, то роутим туда, куда получится.

Ладно, моя ошибка. Добавляю еще одну сеть, сажу туда router3 и один из интерфейсов клиента. В остальном повторяю все выше. Проверяю, что все завелось.

client# show ip ospf neighbor 

Neighbor ID     Pri State           Dead Time Address         Interface                        RXmtL RqstL DBsmL
10.0.0.1          1 Full/DR           24.884s 10.0.0.1        ens19:10.0.0.3                       0     0     0
10.0.0.2          1 Full/Backup       25.013s 10.0.0.2        ens19:10.0.0.3                       0     0     0
10.1.0.4          1 Full/Backup       22.051s 10.1.0.4        ens20:10.1.0.3                       0     0     0

client# 

client# show ip ospf border-routers 
============ OSPF router routing table =============
R    10.0.0.1              [1] area: 0.0.0.0, ASBR
                           via 10.0.0.1, ens19
R    10.0.0.2              [1] area: 0.0.0.0, ASBR
                           via 10.0.0.2, ens19
R    10.1.0.4              [1] area: 0.0.0.0, ASBR
                           via 10.1.0.4, ens20

root@client:~# ip r
default nhid 79 proto ospf metric 20 
	nexthop via 10.0.0.1 dev ens19 weight 1 
	nexthop via 10.0.0.2 dev ens19 weight 1 
	nexthop via 10.1.0.4 dev ens20 weight 1 
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 
10.1.0.0/24 dev ens20 proto kernel scope link src 10.1.0.3 

Как видно, теперь у меня аж три некстхопа. Ходи – не хочу.

Проверяю, как OSPF на client видит интерфейсы

client# show ip ospf interface 
ens19 is up
  ifindex 3, MTU 1500 bytes, BW 4294967295 Mbit <UP,BROADCAST,RUNNING,MULTICAST>
  Internet Address 10.0.0.3/24, Broadcast 10.0.0.255, Area 0.0.0.0
  MTU mismatch detection: enabled
  Router ID 10.0.0.3, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DROther, Priority 1
  Designated Router (ID) 10.0.0.1 Interface Address 10.0.0.1/24
  Backup Designated Router (ID) 10.0.0.2, Interface Address 10.0.0.2
  Saved Network-LSA sequence number 0x80000004
  Multicast group memberships: OSPFAllRouters
  Timer intervals configured, Hello 10s, Dead 30s, Wait 30s, Retransmit 5
    Hello due in 6.368s
  Neighbor Count is 2, Adjacent neighbor count is 2
ens20 is up
  ifindex 4, MTU 1500 bytes, BW 4294967295 Mbit <UP,BROADCAST,RUNNING,MULTICAST>
  Internet Address 10.1.0.3/24, Broadcast 10.1.0.255, Area 0.0.0.0
  MTU mismatch detection: enabled
  Router ID 10.0.0.3, Network Type BROADCAST, Cost: 1
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 10.0.0.3 Interface Address 10.1.0.3/24
  Backup Designated Router (ID) 10.1.0.4, Interface Address 10.1.0.4
  Multicast group memberships: OSPFAllRouters OSPFDesignatedRouters
  Timer intervals configured, Hello 10s, Dead 30s, Wait 30s, Retransmit 5
    Hello due in 0.712s
  Neighbor Count is 1, Adjacent neighbor count is 1

Все правильно, по умолчанию для ethernet cost 1.

Добавляю на клиенте на интерфейс ens19, который смотрит на первые два роутера, опцию ip ospf cost 100. Согласно мануалам, это должно сказать, что туда надо трафик отправлять в последнюю очередь (ведь 100>1)

Проверяю. Вот это было до.

root@client:~# ip r
default nhid 87 proto ospf metric 20 
	nexthop via 10.0.0.1 dev ens19 weight 1 
	nexthop via 10.0.0.2 dev ens19 weight 1 
        nexthop via 10.1.0.4 dev ens20 weight 1
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 
10.1.0.0/24 dev ens20 proto kernel scope link src 10.1.0.3 

Включаю ip ospf cost

root@client:~# ip r
default nhid 91 via 10.1.0.4 dev ens20 proto ospf metric 20 
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 
10.1.0.0/24 dev ens20 proto kernel scope link src 10.1.0.3 

Проверяю, что вообще-то роуты вернутся, если что-то случится с router3

root@client:~# ip link set ens20 down
root@client:~# ip r
default nhid 95 proto ospf metric 20 
	nexthop via 10.0.0.1 dev ens19 weight 1 
	nexthop via 10.0.0.2 dev ens19 weight 1 
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 

Работает, прямо как я и задумал. Теперь садим на каждый роутер по скрипту, который будет проверять доступность интернета. Таких скриптов уйма на любой вкус, цвет и запах. Можно вообще какой-нибудь zabbix присобачить. Но главное, чтобы они шли и пускали два скриптика

root@router3:~# cat enable.sh 
#!/bin/bash
cat << EOF | /usr/bin/vtysh
conf t
router ospf
default-information originate always
exit
exit
exit
EOF

root@router3:~# cat disable.sh 
#!/bin/bash
cat << EOF | /usr/bin/vtysh
conf t
router ospf
no default-information originate always
exit
exit
exit
EOF

Их названия говорят сами за себя, как и то, что они делают. Позапускал их, проверил, что таблица роутинга перестраивается, как и положено, согласно правилам.

Теперь последнее: пустить определенный маршрут через определенный роутер. Пусть это будет 1.2.3.4/32 на router2. Это вообще просто. Просто создаем статический роут и просим распростанить статику.

root@router2:~# vtysh

Hello, this is FRRouting (version 8.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

router2# conf t
router2(config)# ip route 1.2.3.4/32 192.168.1.1
router2(config)# router ospf
router2(config-router)# redistribute static

И все получается согласно заветам лучших сетевиков.

root@client:~# ip r
default nhid 113 via 10.1.0.4 dev ens20 proto ospf metric 20 
1.2.3.4 nhid 115 via 10.0.0.2 dev ens19 proto ospf metric 20 
10.0.0.0/24 dev ens19 proto kernel scope link src 10.0.0.3 
10.1.0.0/24 dev ens20 proto kernel scope link src 10.1.0.3 

Теперь осталось развести router1 и router2 по разным подсетям, донастроить точно так же, как и router3, забекапить все и забыть до появления новых вводных.

А, да. Ну и всех жаждущих интернета отправить на client. Теперь точно все.

Видеонаблюдение, часть 1

В целях покупки домика загорелось мне устроить видеонаблюдение. И чтобы потом как в фильмах “вот преступник, увеличь кадр. еще! ага, попался!”. У меня преступников не ожидается, но хотелку осуществить очень охота.

И в процессе погружения в мир видеонаблюдения оказалось, что все в нем совсем не так просто. Вернее наоборот, просто, но совершенно перпендикулярно сознанию обычного ИТшника.

В начале было самое простое: система будет аналоговая или цифровая? В пользу первой говорит ровно два фактора: сейчас она очень (подчеркиваю очень) дешевая и она базируется на отработанных решениях. Все давно изучено, вылизано и понятно. Самое простое решение: купить валяющийся на складе готовый комплект, раскидать кабеля и успокоиться.

Но у аналогов есть и минус: от каждой камеры нужен прямой кабель до регистратора. 16 камер? 16 линков на коаксиале. В общем, не мой размерчик от слова совсем.

Значит, цифровая. Тем более, что ethernet с wifi у меня точно будет в каждом угле.

Открываю браузер, иду в магазин и немного охреневаю от изобилия камер со всякими аббревиатурами. А цены скачут на три порядка. Что делать, куда бежать?

Первое условие “никаких облаков” сразу отсеивает большую половину камер. Эти камеры потому и дешевы, что сливают китайцам и корейцам все, что можно слить. Новомодным системам надо же на чем-то обучаться? Да и безопасность таких камер хромает на обе ноги – достаточно погуглить и вы обнаружите кучу кредов на любой вкус: хоть напрямую, хоть через “облако”.

А вот следующее условие я не смог внятно сформулировать. Слишком уж много было разноплановой информации. Поэтому я поступил старым проверенным способом: тупо накидал в корзину несколько камер разных производителей и с разной ценой, чтобы лично пощупать и оценить.

Пока камеры ехали, я принялся изучать, чем же их обслуживать. Или, говоря другими словами, DVR, NVR или ip-видеорегистратор. Тут я тоже сразу задрал планку “работает под linux, управление через браузер”. Казалось бы, софта на рынке дофига и больше – бери и пробуй.

Ан, нет. 99% софта – это откровенные поделки, лишь бы было. Особенно этим отличаются отечественные производители. Ни инструкций по настройке, ни поддержки чего-то более-менее распространенного… ничего вообще. Я ставил, смотрел, плевался и удалял. “серверные” версии, которые требуют qtgui? да легко!

Где-то тут приехали и сами камеры, сразу же добавив много интересных аспектов. Например, некоторые камеры сами по себе видеорегистраторы. Можно вставить sd карту, обрисовать зоны для детектора движений и вуаля – все заработает.

Но в итоге самым важным оказалось совершенно другое. Формат, в котором передается видео. MJPEG, H264 и самый моднявый, H265 с плюсиками и буквами на конце. Внезапно для меня это стало могильным камнем для 99,99% видеорегистраторов. Дело в том, что чем моднее формат, тем меньше он требует диска для хранения. В проспектах буржуев я встречал, что H265 S+ требует до 70% меньше места, чем H264.

В итоге с банальной задачей “смотри в камеры, если обнаружишь движение, пиши на диск” справился только один видеорегистратор – AgentDVR. Все остальные, включая широко известный ZoneMinder – тупо крешились, жрали проц и память и так далее и тому подобное. Отдавать им такую важную задачу – глупость высшего уровня.

Выше – скриншот с тестовой инсталляции AgentDVR. Три камеры – 4МП, 2МП и 2МП. Пишется по детектору движения. Как видите, за 11 дней сожрало 120 гигов. И процессор совершенно не нагружен. Было бы прелестно, если бы была хоть какая-то интеграция со сторонними системами. Нет, она вроде заявлена, но за помесячную денежку. Не подходит – я готов заплатить за софт, но единоразово.

Увидев подобные цифры потребления, я воспрял духом. Никаких петабайт на глубину в неделю не нужно – хватит и обычных объемов! А их, как вы понимаете, есть у меня!

Следующий шаг – это полностью “аппаратные” решения. Специализированные, заточенные на работу с камерами и только с камерами. Ну и за кучу (или не очень) денежек.

И тут очередная засада. Как выбрать видеорегистратор? Ни одна собака не пишет, сколько камер он может понятнуть. Вместо этого вовсю рекламируют, сколько потоков с каким разрешением он может одновременно отображать. Но мне-то это не надо…

Когда ко мне приехала очередная пачка железок, то тайна оказалась не такой-то уж и тайной. У каждого приличного видеорегистратора есть параметр “максимальный входной поток”. Он измеряется в мегабитах. И чтобы подсчитать, сколько камер потянет регистратор, надо просто принять “1 мегапиксел камеры = 1 мегабит на регистраторе”. И не смотрите, что 4МП камера выдает по сети всего 600-800 килобайт в секунду – это не те потоки, не итшные. В итоге для трех камер на 4, 2 и 2 мегапикселя нужен регистратор, умеющий переваривать поток в 9+ мегабит. Почему не 8? Оставьте небольшой процент на всякие просадки, усушки и утруски.

С дисками вообще все просто: подойдет абсолютно любой. Но если деньги есть, то надо взять именно для систем видеонаблюдения. Во-первых, они все медленные, 5200, а значит холодные и тихие. А во-вторых, в них льется спецпрошивка, которая оптимизирована для постоянной записи в кучу потоков. Мелочь, но по словам бывалых, на нагруженных системах увеличивает срок службы с года до трех практически гарантированно.

Вот мой, купленный на пробу от tiandy. Два диска, 200МБ входного. Усб справа для ориентира в размерах.

Сами регистраторы тоже разные. Самые простые умеют просто писать поток с камеры на диск. Платы таких на али можно найти от 1500 рублей. У регистраторов покруче добавляется возможность писать на внешние диски, в случае каких-то событий отправлять письма, включать что-то внешнее и прочее подобное.

И тут меня настигла первая засада: у “дешевых” регистратов вся аналитика (распознование человек-машина, границы и так далее) ложится исключительно на камеры. Если камера не умеет (или железка не знает про возможности камеры) – то регистратор напишет “ой, и я тоже не могу”. Вот мой, к примеру, не может.

Вторая засада та же, что и с отечественными: документации нет. Вообще. Пара-тройка страничек с общими телодвижениями и все. Поначалу я думал, что это мне так повезло. Но нет, даже у хваленого HikVision та же фигня.

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