В современных реалиях у корпоративного сегмента нет желания хранить данные своей компании за рубежом)
К тому же ФЗ это регулирует:
152-ФЗ "О персональных данных" - персональные данные россиян должны храниться в России
187-ФЗ "О безопасности критической информационной инфраструктуры" - Запрещает хранение и обработку данных о критически важных объектах за пределами РФ.
Во первых - Наша локация Москва, а у них, судя по всему, европейские дата-центры
Почему rclone а не restic? - rclone более универсальный, может работать с разными облачными хранилищами помимо S3, а так же умеет chunked upload для больших файлов
если нужна простая система бэкапов с дедупликацией — restic топ
ProxMark3 более узко направленное устройство для работы с RFID/NFC, в то время как Flipper более универсальный, и отлично подходит для начального уровня
Чтобы собрать часть метки (например, только имя интерфейса), нужно настроить relabel_configs в конфиге прометеуса. Если не ошибаюсь можно попробовать так:
Для тех, кто столкнулся с подобной проблемой, важно помнить, что путь в конфиге и путь в контейнере должны совпадать. Если контейнер «ждёт» конфиги по определённому пути, это нужно учитывать при монтировании.
Спасибо за мнение! улыбнуло) SNMP + Zabbix действительно отлично закрывает большинство задач и проверено временем. Но, как говорится, "кому шашечки, а кому ехать" :) Prometheus, конечно, изначально заточен под мониторинг сервисов и приложений, а не сетевого железа. Однако, когда в инфраструктуре уже крутится Prometheus, добавление MKTXP или подобных экспортеров – это скорее путь наименьшего сопротивления, чем попытка забить шуруп молотком. Так же выше я описал в комментарии, что по API мы получим больше метрик, может кому-то необходимо визуализировать правила по firewall, или мониторить dB кажного Wi-Fi клиента. С другой стороны, SNMP и Zabbix прекрасно справляются с задачами мониторинга железа. особенно когда дело касается базовых метрик и алертов.Тут согласен, что прямые инструменты проще и надёжнее. В общем, это как спорить, что лучше – отвертка или шуруповёрт. Оба крутят, просто с разной скоростью и удобством :)
Подход с заббиксом и SNMP действительно надёжное решение, особенно если вся линия поддержки опирается в основном на его данные, но связка MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana тоже имеет место быть, так как даёт больше гибкости. Например, некоторые метрики недоступны через SNMP, ввиду того, что мы будем упираться в возможности OID (например, мониторинг DHCP — leases, pool, PPP, Hotspot — users, sessions, или Firewall — количество соединений по каждому правилу), а через API они легко тянутся. К тому же API позволяет опрашивать устройства чаще, чем SNMP. В конечном итоге выбор инструмента зависит от ваших требований к мониторингу, ведь как говорится, важен не инструмент, а результат, который он приносит.
ну в openvpn есть привязка выдаваемых ip адресов к клиентам на основе их Common Name (CN), это не проблема, я активно этим пользуюсь. для этого достаточно добавить в конфиг строку ifconfig-pool-persist ipp.txt после чего будет создан файл ipp.txt в формате: client1,10.8.0.10 client2,10.8.0.11 client3,10.8.0.12
Действительно, более корректно указывать 192.168.1.1/32 для обозначения конкретного IP-адреса. Однако, в данном контексте 192.168.1.1/24 подразумевает, что устройство находится в общей сети с маской 255.255.255.0, и это означает что вы можете использовать любой адрес из описанного мной диапазона сети на вашем устройстве, для того, что бы подключиться к сети и получить связанность с OpenWRT
На Kinetic действительно WireGuard может выдавать результаты ближе к максимуму, всё зависит от аппаратной платформы. В моём случае я выбрал OpenVPN, потому что MikroTik hAP ax³ поддерживает аппаратное ускорение AES-256, что даёт приличный прирост производительности для OpenVPN в TCP. Помимо этого, WireGuard не имеет встроенных механизмов для маскировки трафика под обычный HTTPS, как это может делать OpenVPN.
В современных реалиях у корпоративного сегмента нет желания хранить данные своей компании за рубежом)
К тому же ФЗ это регулирует:
152-ФЗ "О персональных данных" - персональные данные россиян должны храниться в России
187-ФЗ "О безопасности критической информационной инфраструктуры" - Запрещает хранение и обработку данных о критически важных объектах за пределами РФ.
перетаскивать терабайты данных через половину континента интересное занятие наверное)
мы предлагаем локацию в датацентре Москвы!
да, тянуть терабайты данных в Европу из РФ— то ещё удовольствие
Во первых - Наша локация Москва, а у них, судя по всему, европейские дата-центры
Почему rclone а не restic? - rclone более универсальный, может работать с разными облачными хранилищами помимо S3, а так же умеет chunked upload для больших файлов
если нужна простая система бэкапов с дедупликацией — restic топ
ProxMark3 более узко направленное устройство для работы с RFID/NFC, в то время как Flipper более универсальный, и отлично подходит для начального уровня
да, действительно эта часть больше теоретическая, ее цель дать базу для тех, кто хотел бы подробнее разобраться как это работает
практический опыт использования будет в следущей части статьи
Чтобы собрать часть метки (например, только имя интерфейса), нужно настроить
relabel_configsв конфиге прометеуса. Если не ошибаюсь можно попробовать так:Для тех, кто столкнулся с подобной проблемой, важно помнить, что путь в конфиге и путь в контейнере должны совпадать. Если контейнер «ждёт» конфиги по определённому пути, это нужно учитывать при монтировании.
Добрый день, проверьте поступают ли данные от экспортера в прометеус.
Остальные устройства можно добавить так:
Спасибо за мнение! улыбнуло)
SNMP + Zabbix действительно отлично закрывает большинство задач и проверено временем. Но, как говорится, "кому шашечки, а кому ехать" :)
Prometheus, конечно, изначально заточен под мониторинг сервисов и приложений, а не сетевого железа. Однако, когда в инфраструктуре уже крутится Prometheus, добавление MKTXP или подобных экспортеров – это скорее путь наименьшего сопротивления, чем попытка забить шуруп молотком. Так же выше я описал в комментарии, что по API мы получим больше метрик, может кому-то необходимо визуализировать правила по firewall, или мониторить dB кажного Wi-Fi клиента.
С другой стороны, SNMP и Zabbix прекрасно справляются с задачами мониторинга железа. особенно когда дело касается базовых метрик и алертов.Тут согласен, что прямые инструменты проще и надёжнее.
В общем, это как спорить, что лучше – отвертка или шуруповёрт. Оба крутят, просто с разной скоростью и удобством :)
Подход с заббиксом и SNMP действительно надёжное решение, особенно если вся линия поддержки опирается в основном на его данные, но связка MikroTik API ⟶ MKTXP ⟶ Prometheus ⟶ Grafana тоже имеет место быть, так как даёт больше гибкости. Например, некоторые метрики недоступны через SNMP, ввиду того, что мы будем упираться в возможности OID (например, мониторинг DHCP — leases, pool, PPP, Hotspot — users, sessions, или Firewall — количество соединений по каждому правилу), а через API они легко тянутся. К тому же API позволяет опрашивать устройства чаще, чем SNMP.
В конечном итоге выбор инструмента зависит от ваших требований к мониторингу, ведь как говорится, важен не инструмент, а результат, который он приносит.
ну в openvpn есть привязка выдаваемых ip адресов к клиентам на основе их Common Name (CN), это не проблема, я активно этим пользуюсь.
для этого достаточно добавить в конфиг строку ifconfig-pool-persist ipp.txt
после чего будет создан файл ipp.txt в формате:
client1,10.8.0.10
client2,10.8.0.11
client3,10.8.0.12
Действительно, более корректно указывать 192.168.1.1/32 для обозначения конкретного IP-адреса. Однако, в данном контексте 192.168.1.1/24 подразумевает, что устройство находится в общей сети с маской 255.255.255.0, и это означает что вы можете использовать любой адрес из описанного мной диапазона сети на вашем устройстве, для того, что бы подключиться к сети и получить связанность с OpenWRT
На Kinetic действительно WireGuard может выдавать результаты ближе к максимуму, всё зависит от аппаратной платформы. В моём случае я выбрал OpenVPN, потому что MikroTik hAP ax³ поддерживает аппаратное ускорение AES-256, что даёт приличный прирост производительности для OpenVPN в TCP.
Помимо этого, WireGuard не имеет встроенных механизмов для маскировки трафика под обычный HTTPS, как это может делать OpenVPN.