Когда возникает задача по контролю устройств в локальной сети, я сходу не могу придумать решение. Начинаю вспоминать, что в каких-то системах мониторинга с автообнаружением есть уведомления о появлении новых устройств, либо в некотором софте для инвентаризации и базе данных оборудования. А вот что-то отдельное под эту задачу мне было неизвестно до тех пор, пока не узнал про Pi.Alert.
Это небольшое приложение, которое выполняет одну конкретную задачу — периодически сканирует локальную сеть и оповещает тебя, если появляется новое устройство, которого нет в его базе данных. Управление в Pi.Alert осуществляется через веб интерфейс. Соответственно в нём же вы ведёте базу данных всех своих устройств, которые видны в сети.
Для обнаружения устройств используются три метода в зависимости от настроек программы:
1️⃣ По умолчанию используется утилита arp-scan для arp запросов.
2️⃣ Pi.Alert в своём составе имеет известный DNS сервер Pi-hole. Если он используется, то в дополнении к методу 1, проверяется активность на DNS сервере Pi-hole. Там ведётся лог запросов.
3️⃣ Если у вас используется в качестве DHCP сервера dnsmasq, то информация о новых устройствах берётся в том числе и в его leases.
Из особенностей и удобств Pi.Alert отмечу, то у него есть отдельный раздел с календарём, где можно посмотреть видимость различный устройств с привязкой к дням. Выглядит это удобно. Ну и добавлю, что есть лог по каждому устройству.
По названию программы и интеграции с Pi-hole становится понятно, что его можно установить на Raspberry Pi. Именно для этого устройства есть готовый скрипт для установки (есть в репозитории), который актуален и для Debian. На любом другом Linux Pi.Alert можно запустить в Docker. Есть готовый образ с хорошим описанием возможностей и параметров запуска, так что не буду дублировать тут эту информацию.
Уже в процессе тестирования я понял, что Docker образ от другого автора, который взял за основу оригинальный Pi.Alert и очень сильно его доработал, существенно расширив функциональность. Там и интеграция с nmap, с home assistent, API, проверки по snmp, построение карты сети, более расширенная база данных устройств. И вообще много всего полезного. Посмотрите сами в другом репозитории. Получилась полноценная система учёта и контроля устройств в сети.
Так что если вам нужен простой контроль устройств, используйте Pi.Alert от автора (pucherot). Там минимум настроек, которые задаются в процессе установки. Потом даже раздела настроек нет в веб интерфейсе. Если же вам надо расширенный функционал, берите версию от jokob-sk. Я и ту, и другую попробовал. Последняя вообще крутотень. Мне очень понравилась и по возможностям, и по внешнему виду. Там даже мониторинг сайтов есть. По сути это больше похоже на систему мониторинга с простыми сетевыми проверками. Имеет смысл добавить её в подборку с системами мониторинга. Очень просто и быстро запустить и настроить.
#network #мониторинг
Это небольшое приложение, которое выполняет одну конкретную задачу — периодически сканирует локальную сеть и оповещает тебя, если появляется новое устройство, которого нет в его базе данных. Управление в Pi.Alert осуществляется через веб интерфейс. Соответственно в нём же вы ведёте базу данных всех своих устройств, которые видны в сети.
Для обнаружения устройств используются три метода в зависимости от настроек программы:
1️⃣ По умолчанию используется утилита arp-scan для arp запросов.
2️⃣ Pi.Alert в своём составе имеет известный DNS сервер Pi-hole. Если он используется, то в дополнении к методу 1, проверяется активность на DNS сервере Pi-hole. Там ведётся лог запросов.
3️⃣ Если у вас используется в качестве DHCP сервера dnsmasq, то информация о новых устройствах берётся в том числе и в его leases.
Из особенностей и удобств Pi.Alert отмечу, то у него есть отдельный раздел с календарём, где можно посмотреть видимость различный устройств с привязкой к дням. Выглядит это удобно. Ну и добавлю, что есть лог по каждому устройству.
По названию программы и интеграции с Pi-hole становится понятно, что его можно установить на Raspberry Pi. Именно для этого устройства есть готовый скрипт для установки (есть в репозитории), который актуален и для Debian. На любом другом Linux Pi.Alert можно запустить в Docker. Есть готовый образ с хорошим описанием возможностей и параметров запуска, так что не буду дублировать тут эту информацию.
Уже в процессе тестирования я понял, что Docker образ от другого автора, который взял за основу оригинальный Pi.Alert и очень сильно его доработал, существенно расширив функциональность. Там и интеграция с nmap, с home assistent, API, проверки по snmp, построение карты сети, более расширенная база данных устройств. И вообще много всего полезного. Посмотрите сами в другом репозитории. Получилась полноценная система учёта и контроля устройств в сети.
Так что если вам нужен простой контроль устройств, используйте Pi.Alert от автора (pucherot). Там минимум настроек, которые задаются в процессе установки. Потом даже раздела настроек нет в веб интерфейсе. Если же вам надо расширенный функционал, берите версию от jokob-sk. Я и ту, и другую попробовал. Последняя вообще крутотень. Мне очень понравилась и по возможностям, и по внешнему виду. Там даже мониторинг сайтов есть. По сути это больше похоже на систему мониторинга с простыми сетевыми проверками. Имеет смысл добавить её в подборку с системами мониторинга. Очень просто и быстро запустить и настроить.
#network #мониторинг
Задача проверки и регулярного мониторинга за скоростью интернет канала нетривиальна. На первый взгляд кажется, что технически особых проблем нет. Можно придумать какой-то скрипт, который будет регулярно проверять скорость канала и отправлять результат в систему мониторинга.
❓Но когда начинается практическая реализация, возникает множество нюансов. Например, откуда будем что-то скачивать для определения скорости? Как часто будем делать проверки? Какой приоритет будем отдавать этим проверкам? Если максимальный, то у остальных пользователей интернета всё будет тормозить во время тестов. Если минимальный, то что мы в итоге измерим, если в данный момент канал будет загружен чем-то другим?
В итоге мы можем получить набор каких-то значений, с которыми непонятно, что дальше делать, так как невозможно точно понять, что же мы намерили. Тормозить может как наш канал по разным причинам, так и внешний источник, с которым мы делаем проверки. Если использовать публичные сервисы, то провайдеры часто дают к ним максимальный приоритет и скорость, так что тесты всегда будут хорошие.
У меня как-то была задача организовать регулярную проверку скорости интернет канала на сотне филиалов распределённой сети. Я сначала согласился и взял время на подумать. А когда начал продумывать реализацию, понял, что не знаю, как всё это красиво сделать. И имеет ли вообще смысл всё это делать. Изложил свои доводы заказчику и он в итоге отказался от подобного мониторинга. Я объяснил, что проверки сделать смогу, но какие решения он будет принимать на основе этих данных с учётом всех перечисленных нюансов?
✅ Если у вас встанет подобная задача, могу порекомендовать готовый сервис для регулярных проверок, который вы можете развернуть у себя — Speedtest-Tracker. Это обёртка над Ookla's speedtest cli, где бэкенд написан на Laravel (PHP), а фронт на React.
Speedtest-Tracker запускается в докер. Делает регулярные проверки скорости и отправляет уведомления в Telegram/Slack/Discord. Можно посмотреть историю проверок. Всё управление и настройка через браузер. Есть интеграция с healthchecks.io и возможность хранения результатов в Influxdb.
Если захотите сами что-то наколхозить по этой теме, то возьмите упомянутый конcольный клиент speedtest. Другой вариант — воспользоваться iperf. С ним получится более предсказуемый и управляемый результат, но вся инфраструктура для тестов должна быть своя.
Если решали подобную задачу, особенно в какой-то распределённой сети, поделитесь идеями по реализации.
#network
❓Но когда начинается практическая реализация, возникает множество нюансов. Например, откуда будем что-то скачивать для определения скорости? Как часто будем делать проверки? Какой приоритет будем отдавать этим проверкам? Если максимальный, то у остальных пользователей интернета всё будет тормозить во время тестов. Если минимальный, то что мы в итоге измерим, если в данный момент канал будет загружен чем-то другим?
В итоге мы можем получить набор каких-то значений, с которыми непонятно, что дальше делать, так как невозможно точно понять, что же мы намерили. Тормозить может как наш канал по разным причинам, так и внешний источник, с которым мы делаем проверки. Если использовать публичные сервисы, то провайдеры часто дают к ним максимальный приоритет и скорость, так что тесты всегда будут хорошие.
У меня как-то была задача организовать регулярную проверку скорости интернет канала на сотне филиалов распределённой сети. Я сначала согласился и взял время на подумать. А когда начал продумывать реализацию, понял, что не знаю, как всё это красиво сделать. И имеет ли вообще смысл всё это делать. Изложил свои доводы заказчику и он в итоге отказался от подобного мониторинга. Я объяснил, что проверки сделать смогу, но какие решения он будет принимать на основе этих данных с учётом всех перечисленных нюансов?
✅ Если у вас встанет подобная задача, могу порекомендовать готовый сервис для регулярных проверок, который вы можете развернуть у себя — Speedtest-Tracker. Это обёртка над Ookla's speedtest cli, где бэкенд написан на Laravel (PHP), а фронт на React.
Speedtest-Tracker запускается в докер. Делает регулярные проверки скорости и отправляет уведомления в Telegram/Slack/Discord. Можно посмотреть историю проверок. Всё управление и настройка через браузер. Есть интеграция с healthchecks.io и возможность хранения результатов в Influxdb.
Если захотите сами что-то наколхозить по этой теме, то возьмите упомянутый конcольный клиент speedtest. Другой вариант — воспользоваться iperf. С ним получится более предсказуемый и управляемый результат, но вся инфраструктура для тестов должна быть своя.
Если решали подобную задачу, особенно в какой-то распределённой сети, поделитесь идеями по реализации.
#network
Вчера слушал вебинар Rebrain на тему диагностики производительности в Linux. Его вёл Лавлинский Николай. Выступление получилось интересное, хотя чего-то принципиально нового я не услышал. Все эти темы так или иначе разбирал в своих заметках в разное время, но всё это сейчас разрознено. Постараюсь оформить на днях в какую-то удобную единую заметку со ссылками. Заодно дополню той информацией, что узнал из вебинара.
Там не рассмотрели анализ сетевой активности, хотя автор упомянул утилиту bmon. Точнее, я ему подсказал точное название в чате. Я её давно знаю, упоминал в заметках вскользь, а отдельно не писал. Решил это исправить.
Bmon (bandwidth monitor) — классическая unix утилита для просмотра статистики сетевых интерфейсов. Показывает только трафик, не направления. Основное удобство bmon — сразу показывает разбивку по интерфейсам, что удобно, если у вас их несколько. Плюс, удобная визуализация и наглядный вид статистики.
Утилита простая и маленькая, живёт в стандартных репозиториях, так что с установкой никаких проблем нет:
Рекомендую обратить внимание. По наглядности и удобству использования, она мне больше всего нравится из подобных. Привожу список других полезных утилит по этой теме:
◽Iftop — эту утилиту ставлю по дефолту почти на все сервера. Показывает только скорость соединений к удалённым хостам без привязки к приложениям.
◽NetHogs — немного похожа по внешнему виду на iftop, только разбивает трафик не по направлениям, а по приложениям. В связке с iftop закрывает вопрос анализа полосы пропускания сервера. Можно оценить и по приложениям загрузку, и по удалённым хостам.
◽Iptraf — показывает более подробную информацию, в отличие от первых двух утилит. Плюс, умеет писать информацию в файл для последующего анализа. Трафик разбивает по удалённым подключениям, не по приложениям.
◽sniffer — показывает сетевую активность и по направлениям, и по приложениям, и просто список всех сетевых соединений. Программа удобная и функциональная. Минус в том, что нет в репах, надо ставить вручную с github.
А что касается профилирования производительности сетевой подсистемы, то тут поможет набор инструментов netsniff-ng. В заметке разобрано их применение. Это условный аналог perf-tools, только для сети.
#network #perfomance
Там не рассмотрели анализ сетевой активности, хотя автор упомянул утилиту bmon. Точнее, я ему подсказал точное название в чате. Я её давно знаю, упоминал в заметках вскользь, а отдельно не писал. Решил это исправить.
Bmon (bandwidth monitor) — классическая unix утилита для просмотра статистики сетевых интерфейсов. Показывает только трафик, не направления. Основное удобство bmon — сразу показывает разбивку по интерфейсам, что удобно, если у вас их несколько. Плюс, удобная визуализация и наглядный вид статистики.
Утилита простая и маленькая, живёт в стандартных репозиториях, так что с установкой никаких проблем нет:
# apt install bmonРекомендую обратить внимание. По наглядности и удобству использования, она мне больше всего нравится из подобных. Привожу список других полезных утилит по этой теме:
◽Iftop — эту утилиту ставлю по дефолту почти на все сервера. Показывает только скорость соединений к удалённым хостам без привязки к приложениям.
◽NetHogs — немного похожа по внешнему виду на iftop, только разбивает трафик не по направлениям, а по приложениям. В связке с iftop закрывает вопрос анализа полосы пропускания сервера. Можно оценить и по приложениям загрузку, и по удалённым хостам.
◽Iptraf — показывает более подробную информацию, в отличие от первых двух утилит. Плюс, умеет писать информацию в файл для последующего анализа. Трафик разбивает по удалённым подключениям, не по приложениям.
◽sniffer — показывает сетевую активность и по направлениям, и по приложениям, и просто список всех сетевых соединений. Программа удобная и функциональная. Минус в том, что нет в репах, надо ставить вручную с github.
А что касается профилирования производительности сетевой подсистемы, то тут поможет набор инструментов netsniff-ng. В заметке разобрано их применение. Это условный аналог perf-tools, только для сети.
#network #perfomance
Маленькая простая программа для выполнения одной задачи - рисование топологии локальной сети, построенной на коммутаторах с включённой службой snmp - LanTopoLog. Я её знаю очень давно, ещё в бытность работы в техподдержке.
Программа не требует установки, но при желании может работать в качестве службы Windows. Работает, соответственно, только под Windows. По качеству работы эта программа одна из лучших именно для автоматического построения карты сети. Она использует snmp запросы к коммутаторам для получения и сопоставления информации. Так что для её корректной работы включение snmp обязательно на всех коммутаторах. С Микротиками, кстати, тоже нормально работает.
Программа условно-бесплатная. Без лицензии через некоторое время после запуска, отключается часть возможностей. Для разового просмотра схемы не критично. А если захотите пользоваться постоянно, то придётся купить лицензию. Благо она бессрочная, включает все последующие обновления и стоит 50$ для физиков или 9070₽ для юр. лиц.
📌 Помимо построения схемы, имеет другие возможности:
◽может публиковать схему на веб сервере;
◽следит за доступностью узлов и может уведомлять об этом в telegram или email;
◽отображает скорость портов коммутаторов, утилизацию канала;
◽умеет экспортировать схему в Draw.io;
🔥отслеживает все MAC адреса подключенных к коммутаторам устройств, осуществляет поиск по ним.
Описание можно послушать от админа, который реально пользуется этой программой на работе: https://www.youtube.com/watch?v=Js8N70nmYIg Смотрел раньше все видео с канала этого админа, но он что-то забросил его.
Программа, кстати, от нашего соотечественника. До сих пор поддерживается и обновляется, хотя ей уже 17 лет.
⇨ Сайт
#network #отечественное
Программа не требует установки, но при желании может работать в качестве службы Windows. Работает, соответственно, только под Windows. По качеству работы эта программа одна из лучших именно для автоматического построения карты сети. Она использует snmp запросы к коммутаторам для получения и сопоставления информации. Так что для её корректной работы включение snmp обязательно на всех коммутаторах. С Микротиками, кстати, тоже нормально работает.
Программа условно-бесплатная. Без лицензии через некоторое время после запуска, отключается часть возможностей. Для разового просмотра схемы не критично. А если захотите пользоваться постоянно, то придётся купить лицензию. Благо она бессрочная, включает все последующие обновления и стоит 50$ для физиков или 9070₽ для юр. лиц.
📌 Помимо построения схемы, имеет другие возможности:
◽может публиковать схему на веб сервере;
◽следит за доступностью узлов и может уведомлять об этом в telegram или email;
◽отображает скорость портов коммутаторов, утилизацию канала;
◽умеет экспортировать схему в Draw.io;
🔥отслеживает все MAC адреса подключенных к коммутаторам устройств, осуществляет поиск по ним.
Описание можно послушать от админа, который реально пользуется этой программой на работе: https://www.youtube.com/watch?v=Js8N70nmYIg Смотрел раньше все видео с канала этого админа, но он что-то забросил его.
Программа, кстати, от нашего соотечественника. До сих пор поддерживается и обновляется, хотя ей уже 17 лет.
⇨ Сайт
#network #отечественное
Могу посоветовать необычную связку для доступа извне к внутренним ресурсам без необходимости настройки VPN или программных клиентов. Всё будет работать через браузер. Подход нестандартный, но вполне рабочий. Я реализовывал лично на одиночном сервере для безопасного и простого доступа к виртуалкам.
Задача стояла настроить на Proxmox несколько виртуальных машин: Windows Server для работы с 1С, Debian для PostgreSQL + 1С сервер, Debian для локальных изолированных бэкапов. Плюс я добавил сюда одну служебную виртуалку для шлюза с iptables. Задача была максимально упростить доступ клиентов к 1С без дополнительных настроек, но при этом обезопасить его.
В итоге что я сделал. На служебной виртуалке, которая являлась шлюзом в интернет для остальных виртуальных машин, настроил связку:
1️⃣ Labean — простой сервис, который при обнаружении открытия определённого url на установленном рядом веб сервере, добавляет временное или постоянное правило в iptables. Для настройки надо уметь работать с iptables.
2️⃣ Apache Guacamole — шлюз удалённых подключений, через который с помощью браузера можно по RDP или SSH попасть на сервер.
Работает всё это очень просто. Пользователю отправляются две ссылки. При переходе по первой ссылке labean создаёт правило в iptables для ip адреса клиента, разрешающее ему подключиться к Apache Guacamole. А вторая ссылка ведёт к веб интерфейсу Apache Guacamole, куда пользователю открылся доступ. В Apache Guacamole настраивается учётка для каждого пользователя, где добавлены сервера, к которым ему можно подключаться.
Ссылки для labean настраиваются вручную с не словарными путями, которые невозможно подобрать. Нужно точно знать URL. В данном случае Apache Guacamole выступает для удобства подключения пользователей. Если они готовы настраивать себе клиенты RDP, то можно в labean настраивать сразу проброс по RDP. А можно и то и другое. И каждый сам решает, как он хочется зайти: через RDP клиент или через браузер. Работа в браузере накладывает свои ограничения и не всем подходит.
Вместо labean можно использовать port knocking или настроить HTTP доступ через nginx proxy, закрыв его basic auth. Лично мне реализация через url для labean кажется наиболее простой и удобной для конечного пользователя.
Разумеется, помимо labean, должен быть ещё какой-то путь попасть на эти сервера для управления. Белые списки IP или тот же VPN. Администратору, думаю, будет не трудно настроить себе VPN. Я, кстати, на данном сервере в том числе настроил и OpenVPN для тех, кто готов им пользоваться в обход описанной выше схемы.
#security #gateway #network
Задача стояла настроить на Proxmox несколько виртуальных машин: Windows Server для работы с 1С, Debian для PostgreSQL + 1С сервер, Debian для локальных изолированных бэкапов. Плюс я добавил сюда одну служебную виртуалку для шлюза с iptables. Задача была максимально упростить доступ клиентов к 1С без дополнительных настроек, но при этом обезопасить его.
В итоге что я сделал. На служебной виртуалке, которая являлась шлюзом в интернет для остальных виртуальных машин, настроил связку:
1️⃣ Labean — простой сервис, который при обнаружении открытия определённого url на установленном рядом веб сервере, добавляет временное или постоянное правило в iptables. Для настройки надо уметь работать с iptables.
2️⃣ Apache Guacamole — шлюз удалённых подключений, через который с помощью браузера можно по RDP или SSH попасть на сервер.
Работает всё это очень просто. Пользователю отправляются две ссылки. При переходе по первой ссылке labean создаёт правило в iptables для ip адреса клиента, разрешающее ему подключиться к Apache Guacamole. А вторая ссылка ведёт к веб интерфейсу Apache Guacamole, куда пользователю открылся доступ. В Apache Guacamole настраивается учётка для каждого пользователя, где добавлены сервера, к которым ему можно подключаться.
Ссылки для labean настраиваются вручную с не словарными путями, которые невозможно подобрать. Нужно точно знать URL. В данном случае Apache Guacamole выступает для удобства подключения пользователей. Если они готовы настраивать себе клиенты RDP, то можно в labean настраивать сразу проброс по RDP. А можно и то и другое. И каждый сам решает, как он хочется зайти: через RDP клиент или через браузер. Работа в браузере накладывает свои ограничения и не всем подходит.
Вместо labean можно использовать port knocking или настроить HTTP доступ через nginx proxy, закрыв его basic auth. Лично мне реализация через url для labean кажется наиболее простой и удобной для конечного пользователя.
Разумеется, помимо labean, должен быть ещё какой-то путь попасть на эти сервера для управления. Белые списки IP или тот же VPN. Администратору, думаю, будет не трудно настроить себе VPN. Я, кстати, на данном сервере в том числе настроил и OpenVPN для тех, кто готов им пользоваться в обход описанной выше схемы.
#security #gateway #network
Меня часто спрашивают, каким образом можно объединить несколько интернет каналов в один общий. То есть настроить не резервирование, не переключение, не балансировку, а именно одновременное использование нескольких каналов для увеличения суммарной пропускной способности. При этом сами каналы чаще всего разного типа. То есть это не то же самое, что объединить порты на свитчах.
У меня никогда не было опыта подобной настройки. Я понимаю, что технически это сложная задача, как логически, так и архитектурно. Честное суммирование каналов будет приводить к явным проблемам. Например, у клиента канал 1000 мегабит, а у сервиса 3 канала по 100 мегабит. Клиент на полной скорости пытается забрать контент с сервера, который вынужден будет для максимальной скорости утилизировать все 3 канала одновременно. Получается один клиент будет забирать контент с трёх разных маршрутов с разными метриками, откликами, source ip шлюзов и т.д.
Ну и в обратную сторону те же самые проблемы, когда у клиента 3 канала, а у сервиса один. Всё это нужно как-то собирать в единую последовательность, чтобы данные не превращались в кашу. А есть ещё привязки аутентификаций и кук к IP. Что с ними будет?
К чему я всё это? Если у вас возникнет подобная задача (постарайтесь от неё отмахнуться), то дам вам подсказку в виде бесплатного OpenMPTCProuter. Это open source проект программного роутера, который умеет честно суммировать интернет каналы. Для этого он состоит из двух частей. Одна клиентская, которую вы ставите там, где суммируете каналы. А вторая часть располагается где-то в интернете для объединения подключений со всех интернет каналов. Только такая схема может обеспечить реальное объединение каналов и возможность приложениям нормально работать при такой схеме без потери пакетов и разрыва соединений.
Клиентская часть, где будут подключены интернет каналы, может быть установлена на обычный x86, x86_64 Linux, Raspberry PI 2B/3B/3B+/4B, Linksys WRT3200ACM/WRT32X, Teltonika RUTX12, Banana PI BPI-R2. Она построена на базе OpenWRT. Суммирующий сервер может быть развёрнут в интернете на обычном VPS на базе Debian или Ubuntu.
Настройка, на удивление для такого продукта, не сложная. Я сам не пробовал, но есть руководство на сайте и инструкции в интернете. Настраивается суммирующий сервер с помощью готового скрипта. Потом поднимаем из образа клиентскую часть. Через веб интерфейс настраиваем интернет каналы и указываем настройки подключения к суммирующему серверу. Этого минимума будет достаточно, чтобы всё заработало.
Это единственное бесплатное решение, которое мне знакомо по данной задаче. Все другие входят в состав дорогих коммерческих продуктов. Из не очень дорогого я когда-то видел коробочку с несколькими USB модемами, но не уверен, что там было честное объединение, а не резервирование и переключение. Да и то название забыл.
Если кто-то пользовался подобными или конкретно этой системой, то дайте обратную связь. Как на практике работает объединение каналов? Тут же куча сопутствующих проблем возникает от банальной настройки файрвола до проброса портов. Не понятно, как это должно работать в таких схемах.
#network
У меня никогда не было опыта подобной настройки. Я понимаю, что технически это сложная задача, как логически, так и архитектурно. Честное суммирование каналов будет приводить к явным проблемам. Например, у клиента канал 1000 мегабит, а у сервиса 3 канала по 100 мегабит. Клиент на полной скорости пытается забрать контент с сервера, который вынужден будет для максимальной скорости утилизировать все 3 канала одновременно. Получается один клиент будет забирать контент с трёх разных маршрутов с разными метриками, откликами, source ip шлюзов и т.д.
Ну и в обратную сторону те же самые проблемы, когда у клиента 3 канала, а у сервиса один. Всё это нужно как-то собирать в единую последовательность, чтобы данные не превращались в кашу. А есть ещё привязки аутентификаций и кук к IP. Что с ними будет?
К чему я всё это? Если у вас возникнет подобная задача (постарайтесь от неё отмахнуться), то дам вам подсказку в виде бесплатного OpenMPTCProuter. Это open source проект программного роутера, который умеет честно суммировать интернет каналы. Для этого он состоит из двух частей. Одна клиентская, которую вы ставите там, где суммируете каналы. А вторая часть располагается где-то в интернете для объединения подключений со всех интернет каналов. Только такая схема может обеспечить реальное объединение каналов и возможность приложениям нормально работать при такой схеме без потери пакетов и разрыва соединений.
Клиентская часть, где будут подключены интернет каналы, может быть установлена на обычный x86, x86_64 Linux, Raspberry PI 2B/3B/3B+/4B, Linksys WRT3200ACM/WRT32X, Teltonika RUTX12, Banana PI BPI-R2. Она построена на базе OpenWRT. Суммирующий сервер может быть развёрнут в интернете на обычном VPS на базе Debian или Ubuntu.
Настройка, на удивление для такого продукта, не сложная. Я сам не пробовал, но есть руководство на сайте и инструкции в интернете. Настраивается суммирующий сервер с помощью готового скрипта. Потом поднимаем из образа клиентскую часть. Через веб интерфейс настраиваем интернет каналы и указываем настройки подключения к суммирующему серверу. Этого минимума будет достаточно, чтобы всё заработало.
Это единственное бесплатное решение, которое мне знакомо по данной задаче. Все другие входят в состав дорогих коммерческих продуктов. Из не очень дорогого я когда-то видел коробочку с несколькими USB модемами, но не уверен, что там было честное объединение, а не резервирование и переключение. Да и то название забыл.
Если кто-то пользовался подобными или конкретно этой системой, то дайте обратную связь. Как на практике работает объединение каналов? Тут же куча сопутствующих проблем возникает от банальной настройки файрвола до проброса портов. Не понятно, как это должно работать в таких схемах.
#network
Современные операционные системы сегодня живут своей жизнью. Иногда бывает забавно посмотреть на сетевой трафик и ужаснуться от того, сколько там различных сетевых соединений, которые инициировали не вы. Проще всего их отследить по DNS запросам, настроив свой DNS сервер с логированием всех запросов.
Но есть способы проще. Например, взять open source приложение Sniffnet и посмотреть в удобном виде всю сетевую активность. Причём приложение кроссплатформенное. Я сначала не понял, как такая простая и маленькая программа на Rust может одинаково работать на всех платформах. Оказалось, она использует библиотеку pcap: libpcap в unix и npcap в windows. Для тех, кто не в курсе, поясню, что это та же библиотека, что используется в Nmap и Wireshark.
Sniffnet позволяет подключиться к конкретному сетевому интерфейсу и посмотреть его активность. Работает в том числе с VPN интерфейсами. Например, если вы заворачиваете весь трафик в VPN, то на основном интерфейсе увидите только трафик в сторону VPN сервера. А если заглянете в VPN интерфейс, там уже будет детальна информация. Можно быстро проверить, точно ли весь нужный трафик идёт в VPN.
В Sniffnet можно настроить 3 типа уведомлений:
1️⃣ Превышение порога по частоте передачи пакетов.
2️⃣ Превышение порога полосы пропускания.
3️⃣ Соединение с указанными IP адресами.
Уведомления фиксируются и отображаются в отдельной вкладке интерфейса.
Поддерживаются оба протокола: ipv4 и ipv6. В программе, в принципе, ничего особенного нет. Но сделана добротно и удобно, приятный интерфейс, есть русский язык. Можно взять на заметку, если понадобится подобный функционал. Я, к примеру, так сходу и не вспомню, чем так же трафик посмотреть на Windows. Первыми на ум приходят различные application firewalls, но это немного не то. Более навороченные и функциональные программы.
В Windows предварительно надо будет установить Npcap (installer), в Linux libpcap и звуки со шрифтами:
А потом уже сам Sniffnet.
⇨ Сайт / Исходники
#network
Но есть способы проще. Например, взять open source приложение Sniffnet и посмотреть в удобном виде всю сетевую активность. Причём приложение кроссплатформенное. Я сначала не понял, как такая простая и маленькая программа на Rust может одинаково работать на всех платформах. Оказалось, она использует библиотеку pcap: libpcap в unix и npcap в windows. Для тех, кто не в курсе, поясню, что это та же библиотека, что используется в Nmap и Wireshark.
Sniffnet позволяет подключиться к конкретному сетевому интерфейсу и посмотреть его активность. Работает в том числе с VPN интерфейсами. Например, если вы заворачиваете весь трафик в VPN, то на основном интерфейсе увидите только трафик в сторону VPN сервера. А если заглянете в VPN интерфейс, там уже будет детальна информация. Можно быстро проверить, точно ли весь нужный трафик идёт в VPN.
В Sniffnet можно настроить 3 типа уведомлений:
1️⃣ Превышение порога по частоте передачи пакетов.
2️⃣ Превышение порога полосы пропускания.
3️⃣ Соединение с указанными IP адресами.
Уведомления фиксируются и отображаются в отдельной вкладке интерфейса.
Поддерживаются оба протокола: ipv4 и ipv6. В программе, в принципе, ничего особенного нет. Но сделана добротно и удобно, приятный интерфейс, есть русский язык. Можно взять на заметку, если понадобится подобный функционал. Я, к примеру, так сходу и не вспомню, чем так же трафик посмотреть на Windows. Первыми на ум приходят различные application firewalls, но это немного не то. Более навороченные и функциональные программы.
В Windows предварительно надо будет установить Npcap (installer), в Linux libpcap и звуки со шрифтами:
# apt install libpcap-dev libasound2-dev libfontconfig1-devА потом уже сам Sniffnet.
⇨ Сайт / Исходники
#network
Запомнился один момент с недавней конференции, где я присутствовал. Выступающий рассказывал, если не ошибаюсь, про технологию VDI и оптимизацию полосы пропускания, что позволяет комфортно общаться по видеосвязи. В подтверждение своих слов с цифрами показал картинку, где справа окно терминала.
Я сразу же узнал, чем они измеряли скорость. Это утилита iftop, которую я сам почти всегда ставлю на сервера под своим управлением. Привык к ней. Удобно быстро посмотреть потоки трафика на сервере с разбивкой по IP адресам и портам.
Ну и чтобы добавить пользы посту, приведу список утилит со схожей функциональностью, но не идентичной. То есть они дополняют друг друга: bmon, Iptraf, sniffer, netsniff-ng.
#network #perfomance
Я сразу же узнал, чем они измеряли скорость. Это утилита iftop, которую я сам почти всегда ставлю на сервера под своим управлением. Привык к ней. Удобно быстро посмотреть потоки трафика на сервере с разбивкой по IP адресам и портам.
Ну и чтобы добавить пользы посту, приведу список утилит со схожей функциональностью, но не идентичной. То есть они дополняют друг друга: bmon, Iptraf, sniffer, netsniff-ng.
#network #perfomance
Когда вы настраиваете VPN, встаёт вопрос выбора размера MTU (maximum transmission unit) внутри туннеля. Это размер полезного блока с данными в одном пакете. Как известно, в сетевом пакете часть информации уходит для служебной информации в заголовках. Различные технологии VPN используют разный объём служебных заголовков. А если VPN пущен поверх другого VPN канала, то этот вопрос встаёт особенно остро.
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Если ошибиться с размером MTU, то пакеты начнут разбиваться на несколько, чтобы передать полезный блок с данными. Это очень сильно снижает скорость передачи данных. Минимум в 2 раза, но на деле гораздо больше.
Правильно выбрать размер MTU можно с помощью готового калькулятора - Visual packet size calculator. Его автор, кстати, Даниил Батурин, который иногда ведёт бесплатные вебинары Rebrain, которые я периодически рекламирую. Рекомендую послушать, интересно.
К сожалению, в калькуляторе нет OpenVPN. И я как-то сходу не смог найти информацию, сколько места занимают служебные заголовки этого протокола. Покажу пример для WireGuard, если я всё правильно понимаю. Если ошибаюсь, прошу поправить.
Мы устанавливаем туннель WireGuard, чтобы гонять по нему ipv4 трафик. Идём в калькулятор и выстраиваем там цепочку:
IPv4 (20 bytes) ⇨ WireGuard (40 bytes) ⇨ IPv4 (20 bytes)
Имея на родительском интерфейсе MTU 1500, внутри туннеля нам необходимо установить его 1420. Если не ошибаюсь, это как раз значение по умолчанию для WireGuard.
Тема MTU довольно сложная. Если вы не сетевой инженер и специально ей не интересовались, то вникнуть непросто. На практике я сталкивался с подобными проблемами. Решал их в меру своих сил и способностей - просто уменьшал MTU до некоторых значений, когда проблем пропадала. Если вы не разбираетесь детально в этой теме, рекомендую поступать так же. И важно знать, что если у вас PPPoE соединение от провайдера, то оно дополнительно 8 байт занимает на заголовки. Часто дефолтные значения различного софта не учитывают этого нюанса и нужно будет поправить вручную.
#vpn #network
Часто слышал выражение, что трафик отправляют в blackhole. Обычно это делает провайдер, когда вас ддосят. Вас просто отключают, отбрасывая весь адресованный вам трафик. А что за сущность такая blackhole, я не знал. Решил узнать, заодно и вам рассказать.
Я изначально думал, что это какое-то образное выражение, которое переводится как чёрная дыра. А на деле предполагал, что соединения просто дропают где-то на файрволе, да и всё. Оказывается, blackhole это реальная запись в таблице маршрутизации. Вы на своём Linux сервере тоже можете отправить весь трафик в blackhole, просто создав соответствующий маршрут:
Проверяем:
Все пакеты с маршрутом до 1.2.3.4 будут удалены с причиной No route to host. На практике на своём сервере кого-то отправлять в blackhole большого смысла нет. Если я правильно понимаю, это провайдеры отправляют в blackhole весь трафик, адресованный какому-то хосту, которого ддосят. Таким образом они разгружают своё оборудование. И это более эффективно и просто, чем что-то делать на файрволе.
Если я правильно понимаю, подобные маршруты где-то у себя имеет смысл использовать, чтобы гарантированно отсечь какой-то исходящий трафик в случае динамических маршрутов. Например, у вас есть какой-то трафик по vpn, который должен уходить строго по определённому маршруту. Если этого маршрута не будет, то трафик не должен никуда идти. В таком случае делаете blackhole маршрут с максимальной дистанцией, а легитимные маршруты с дистанцией меньше. В итоге если легитимного маршрута не будет, весь трафик пойдёт в blackhole. Таким образом можно подстраховывать себя от ошибок в файрволе.
#network
Я изначально думал, что это какое-то образное выражение, которое переводится как чёрная дыра. А на деле предполагал, что соединения просто дропают где-то на файрволе, да и всё. Оказывается, blackhole это реальная запись в таблице маршрутизации. Вы на своём Linux сервере тоже можете отправить весь трафик в blackhole, просто создав соответствующий маршрут:
# ip route add blackhole 1.2.3.4Проверяем:
# ip r | grep blackholeblackhole 1.2.3.4Все пакеты с маршрутом до 1.2.3.4 будут удалены с причиной No route to host. На практике на своём сервере кого-то отправлять в blackhole большого смысла нет. Если я правильно понимаю, это провайдеры отправляют в blackhole весь трафик, адресованный какому-то хосту, которого ддосят. Таким образом они разгружают своё оборудование. И это более эффективно и просто, чем что-то делать на файрволе.
Если я правильно понимаю, подобные маршруты где-то у себя имеет смысл использовать, чтобы гарантированно отсечь какой-то исходящий трафик в случае динамических маршрутов. Например, у вас есть какой-то трафик по vpn, который должен уходить строго по определённому маршруту. Если этого маршрута не будет, то трафик не должен никуда идти. В таком случае делаете blackhole маршрут с максимальной дистанцией, а легитимные маршруты с дистанцией меньше. В итоге если легитимного маршрута не будет, весь трафик пойдёт в blackhole. Таким образом можно подстраховывать себя от ошибок в файрволе.
#network
