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

Известными представителями подобных продуктов являются Nebula, Tailscale, Netmaker, Netbird и ZeroTier. На последнем я бы хотел остановиться поподробнее. Он выделяется из этого списка своим протоколом передачи данных, в то время как остальные в основном используют WireGuard. Плюс, Mikrotik в RouterOS7 имеет реализацию, как клиента, так и своего контроллера на базе ZeroTier.

Я раньше только слышал про него, сам не пробовал. Решил исправить это, развернул и протестировал. Сразу скажу, что это не инструмент для обхода блокировок. Он не для этого придуман и в данной роли работает плохо. Не стоит эту тему развивать.

ZeroTier - платный SaaS сервис. Регистрируетесь, платите деньги и получаете личный кабинет для управления всеми своими сетями. Но при этом серверная часть выложена в open source. Каждый может развернуть свой локальный сервер и управлять им через CLI. Я немного изучил команды, там на самом деле всё относительно просто.

В связи с этим появилось очень много реализаций бесплатного веб интерфейса для управления сервером. Я недавно читал статью про настройку Self-Hosted ZeroTier с помощью интерфейса ZTNET, поэтому не стал смотреть другие интерфейсы, а их много, взял сразу этот. В целом, там всё необходимое для управления есть.

Запускаем так:

# wget -O docker-compose.yml https://raw.githubusercontent.com/sinamics/ztnet/main/docker-compose.yml
# sed -i "s|http://localhost:3000|http://$(hostname -I | cut -d' ' -f1):3000|" docker-compose.yml
# docker compose up -d

Можно и вручную всё это сделать. В репозитории есть описание. Теперь можно идти на 3000 порт сервера и регистрировать учётку админа.

Принцип объединения устройств в единую сеть следующий:

1️⃣ Скачиваете клиента под свою систему (есть под все, в том числе мобильные)
2️⃣ В клиенте указываете Network ID или сканируете QR код, который видно в веб интерфейсе. В этом ID, как я понял, закодирован IP контроллера.
3️⃣ Клиент подключается к серверу, на сервере вы подтверждаете его подключение.
4️⃣ Клиент получает IP адрес внутренней сети.

Я объединил Windows, Linux и Mikrotik. Получилось всё без проблем. Узлы сети сразу же напрямую увидели себя по внутренним адресам сети ZeroTier. Заработали RDP, SSH, Winbox.

Вы можете назначить Mikrotik шлюзом для какой-то подсети, которая находится за ним. Клиенты, которые подключатся к общей mesh-сети, могут ходить в ту сеть через него. А какой-нибудь Linux сервер назначить шлюзом для доступа в другую инфраструктуру. То есть каждый узел может выступать в роли и клиента, и шлюза для других. Настраивается это очень просто, буквально в несколько кликов в веб интерфейсе.

Если клиенты не видят друг друга напрямую, то общаются через контроллер. По умолчанию локальный ZeroTier подключается к набору публичных серверов для связи клиентов, которые не могут через ваш сервер увидеть друг-друга. Например, если сервер не в публичном доступе для всех.

В ZTNET это отключается в разделе настроек ZT Controller, где вы можете создать так называемый Custom Planet, который будет работать только локально и никуда подключаться не будет. Вам нужно будет обеспечить к нему прямой доступ всех клиентов, либо опубликовав контроллер напрямую в интернете, либо пробросив к нему порт 9993/udp.

Я всё это настроил. Разобрался со всем за пару-тройку часов. Не могу подробно расписать установку клиентов и команды, потому что лимит на длину заметки. В сети всё это есть, там ничего сложного.

Продукт простой, функциональный, бесплатный и известный. Много кем поддерживается. Так что если нужно что-то подобное, то можете смело использовать. Единственное, я бы поискал какой-то другой GUI. Этот показался немного кривоват, хотя вся необходимая функциональность присутствует.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#vpn #network

Расскажу, как можно быстро проанализировать трафик с любого роутера или шлюза, которые поддерживают отправку данных в формате Netflow. Как самый наглядный пример возьмём Mikrotik.

Ранее я уже рассказывал, как его трафик можно смотреть в режиме реального времени в Wireshark. Для этого его туда надо направить через Packet Sniffer и его возможность Streaming. Сегодня расскажу про более универсальный способ через отправку и анализ Netflow.

Допустим, вам надо быстро посмотреть, к каким DNS серверам у вас обращается оборудование в локальной сети. Для этого можно пытаться что-то разглядеть в IP ⇨ Firewall ⇨ Connections или в Torch сетевого интерфейса, но это неудобно.

Возьмём любую машину на базе Linux и поставим туда nfdump. Это консольная утилита для анализа NetFlow. В Debian/Ubuntu она есть в базовых репозитория:

# apt install nfdump

В составе этого пакета также присутствует утилита nfcapd. Она работает в роли netflow collector, собирает и хранит данные о трафике, а nfdump в консоли анализирует. Так что запускаем сначала сборщик:

# nfcapd -z -l /mnt/mikrotik -t 60 -p 23456

-z - сжимать данные
-l - директория, где храним дампы
-t - каждые 60 секунд записываем данные в файл
-p - сборщик работает на порту UDP 23456
-D - этот ключ запустит сборщика в режиме службы

Теперь идём в Mikrotik, открываем раздел IP ⇨ Traffic Flow ⇨ Enables. Открываем здесь же раздел Targets и добавляем наш сборщик:
◽️Src. Address: IP адрес МИкротика
◽️Dst. Address: IP адрес сборщика
◽️Port: 23456

Остальные параметры оставляем по умолчанию. Сохраняем. Как только польются данные о трафике, на сборщике в директории /mnt/mikrotik начнут появляться файлы вида nfcapd.202512250054 nfcapd.202512250056 и т.д. Они нам и нужны.

Запускаем анализатор трафика nfdump:

# nfdump -R /mnt/mikrotik

Увидим в консоли информацию по всему собранному трафику. Её может быть много. Тут простой и интуитивный синтаксис для поиска нужных данных. Выводим только DNS запросы:

# nfdump -R /mnt/mikrotik 'dst port 53'

Можем агрегировать вывод для простоты восприятия. Объединим одинаковые потоки и отобразим только адрес источника и назначения:

# nfdump -R /mnt/mikrotik 'dst port 53' -A srcip,dstip

Можем сузить поиск и дополнительно показать пакеты с конкретного IP адреса:

# nfdump -R /mnt/mikrotik 'src ip 192.168.137.10 and dst port 53' -A srcip,dstip

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

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

# nfcapd -D -S 2 -w /mnt/netflow -p 23456

Если у вас несколько шлюзов и вы хотите разделить их трафик, то можно сделать это через ключ -n, добавив название источника, его IP адрес и директорию, где будут храниться данные:

# nfcapd -z -t 60 -D -S 2 -p 23456 -n r01,192.168.137.1,/mnt/r01 -n r02,192.168.161.1,/mnt/r02

В таком режиме он будет собирать данные и автоматически раскладывать их по директориям в формате %Y/%m/%d/%H, то есть year/month/day/hour. Потом можно легко вернуться к нужному интервалу и посмотреть трафик, проанализировать его каким-то софтом. Например, nfsen-ng.

Nfdump наиболее простой и дешёвый по ресурсам инструмент для работы с NetFlow. Подходит и для анализа в режиме реального времени, и для долгосрочного хранения.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#netflow #mikrotik #network

В одном из недавних видео увидел обзор сетевого сканера Scanopy, который умеет автоматически искать новые узлы и добавлять их на схему. По описанию работы и внешнему виду всё понравилось, поэтому решил попробовать. Развернул у себя дома и поразбирался с ним. Для тех, кто не захочет читать всю заметку, сразу передам суть:

◽️Проект новый, ещё не настоялся. Для домашней или тестовой инфраструктуры сойдёт, в прод я бы пока не ставил.
◽️Выглядит красиво, реально всё делает автоматически: ищет узлы, сканирует порты, сам определяет, как может, работающие сервисы, добавляет всё это на схему.
◽️Возможностей гибких настроек мало, сами настройки неинтуитивны. Я некоторое время возился, пока разобрался, как там всё устроено.

В итоге принял решение дома его оставить. У меня много всевозможных сетевых устройств (компы, ноуты, сервера, камеры, бытовые устройства, свитчи, смартфоны). Вручную рисовать схемы лень, особо не надо. Смотреть на неизвестное устройство иду в DHCP-сервер. Даже в таком виде, как это делает Scanopy, выглядит неплохо. Лучше, чем ничего, и красивее, чем я нарисовал в Zabbix 😁.

Scanopy состоит из трёх компонентов:
1️⃣ Сервер с веб интерфейсом
2️⃣ Сканирующий агент
3️⃣ СУБД Postgresql для хранения состояния

Всё это упаковано в Docker и описано в Compose. Запускается в 3 действия:

# curl https://get.docker.com | bash -
# curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
# docker compose up -d

Идём в http://<server-ip>:60072 и создаём учётку администратора. Scanopy определяет локальную сеть, в которой работает, автоматически запускает сканирование сети и построение схемы. То есть даже настраивать ничего не надо. Развернули, зашли, выполнили пару шагов для регистрации и процесс пошёл.

Для быстрого запуска в LXC контейнере Proxmox есть готовый скрипт из набора Proxmox VE Helper-Scripts. Думаю, у себя в таком исполнении установлю.

Сканирование сети длится относительно долго (у меня минут 15), в зависимости от количества узлов. Для каждого узла сканируются все открытые порты и определяются службы по типу того, как это делает Nmap. Возможно он, или, как минимум, признаки служб из его набора используются для определения. В документации не уточнён этот момент. Просто указано, что написан сканер с распознаванием служб по различным признакам.

Далее для узлов делаются более тонкие настройки - указание имени, редактирование служб, настройка связей, расположение на схеме и т.д. В целом, получается наглядно и симпатично, особенно если доработать схему самому. Но даже автоматически нормально получается.

Вместо своей схемы, которую я ещё не доработал, покажу примеры с сайта, как это может выглядеть. Прикрепил некоторые картинки.

В целом, продукт интересный. Если получится развитие, то будет неплохо. А автор, судя по всему, задумал развивать, так как сразу одновременно с self-hosted версией, сделал платную по модели SaaS, написал документацию. Так что пожелаю ему успехов в этом деле. Думаю, подобная программа многим упростит рутину.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#network

На днях до глубокой ночи занимался настройкой одиночного гипервизора Proxmox, потому что кое-что не получалось. Нужно было ложиться спать, но не могу уснуть с недоделанной задачей. В итоге так и лёг. Утром проснулся и понял, где ошибся. Мысль как бы невзначай сама пришла. А вот то, что настраивал, расскажу вам. Это может кому-то пригодиться.

Есть одиночный выделенный сервер с одним внешним IP под PVE. Он будет работать в связке с другими, но связь только через интернет по VPN. Тут есть 2 варианта организации сети:

1️⃣ Настраиваем на гипервизоре файрвол, NAT, возможно SDN с DHCP, пробрасываем порты в виртуальные машины и там настраиваем всё, что нужно. Например, VPN сервер.
➕ Простота и скорость настроек.
➖ Настраивать нужно сам гипервизор и потом бэкапить его настройки. Это осложняет перенос, если нужно переехать. Да и в целом концепция с настройками чего-то на самом гипервизоре не очень удобна. От уровня железа лучше абстрагироваться, перенося всё в виртуальные машины. Сам гипервизор становится точкой входа в инфраструктуру, что тоже не очень удобно и безопасно.

2️⃣ На гипервизоре настраивается виртуальная машина в роли шлюза. В неё прокидывается внешний IP адрес. Она становится шлюзом по умолчанию для всех виртуалок и самого гипервизора.
➕ Все настройки внутри VM, которую можно забэкапить и перенести. На гипервизоре настраивается только сеть и больше ничего. Внутри виртуальной машины можно настроить всё, что угодно, ни в чём себя не ограничивая. Это может быть CHR с RouterOS или OPNSense.
➖ Более сложные сетевые настройки и очень желательно постоянный доступ по IP-KVM. У некоторых провайдеров бывают проблемы с такой схемой из-за их особенностей сети. Если VM со шлюзом не поднимется по какой-то причине, доступа к гипервизору не будет.

Есть третий вариант - купить несколько IP адресов на один сервер. Если сервера дорогие, то экономить на IP смысла нет, лучше заказать. Это и проще, и функциональнее. Я так часто делал. Но если сервак бюджетный, то переплачивать за /29 или /28 подсеть, а с дедиками обычно сразу подсеть продают, не хочется. Там цена адресов может быть сопоставима с самим сервером.

Я настраивал сеть по второму примеру. Нарисовал схему, как это выглядит на практике, и прикрепил внизу. Пример взял с реально настроенного сервера. Пишу по шагам, как настраивал.

1️⃣ На железном сервере 1 сетевой интерфейс eth0 с IP адресом 45.95.177.210. Ставлю на этот сервер PVE. Доступ к веб интерфейсу, соответственно, по этому IP адресу.

2️⃣ Создаю на этом сервере бридж vmbr0 и добавляю в него интерфейс eth0. Сетевые настройки IP адреса из eth0 переношу в vmbr0. Делаю это напрямую в файле /etc/network/interfaces, так как через веб интерфейс PVE не получится.

3️⃣ Добавляю ещё один бридж vmbr1 без привязки к физическому интерфейсу. Этот бридж будет использоваться для связи виртуальных машин и гипервизора между собой.

4️⃣ Проверяю внимательно настройки и перезагружаю сервер. После перезагрузки он поднимется с двумя настроенными интерфейсами:
◽️vmbr0 - внешний IP адрес
◽️vmbr1 - локальный IP адрес

5️⃣ Создаю виртуальную машину под шлюз, подключаю к ней vmbr0 и vmbr1. Ставлю эту VM в автозагрузку, чтобы поднималась вместе с гипервизором.

6️⃣ Переношу настройки внешнего IP адреса с vmbr0 гипервизора на сетевой интерфейс VM, где подключен vmbr0. На vmbr1 настраиваю локальный IP адрес и убеждаюсь, что гипервизор и виртуалка видят друг друга.

7️⃣ Комментирую настройки внешнего IP адреса на гипервизоре, чтобы они остались только внутри VM.

8️⃣ Перезагружаю гипервизор и подключаюсь по внешнему IP к VM со шлюзом.

9️⃣ Настраиваю проброс портов со шлюза на гипервизор, чтобы к нему был доступ.

Схема полностью рабочая. Описывал её в своей старой статье по организации сети в PVE. В Selectel она нормально работает. Я ошибся с тем, что временно на VM во время настройки сделал выход в интернет через гипервизор, а потом забыл поменять шлюз по умолчанию. После перезагрузки терял доступ к гипервизору.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX

#proxmox #network