Цифровой дворник

Практические заметки о сетях, self-hosting, виртуализации, мониторинге, автоматизации и локальном ИИ.

Telegram: @digclean

Обложка

Агентский аппетит и «цена» каждого вызова

Бывает так: пишешь субагентов, автоматизации, скрипты — и каждый вызов модели кажется бесплатным, «ну это же бесплатный режим». Но как только начинаешь гонять их по многу раз в день, расходы всё равно набегают. Claude Opus 5 — отличная модель, но даже при цене $5 за миллион входных токенов при постоянной нагрузке бюджет чувствуется. GPT-5 — вообще роскошь. А есть ли путь, где можно не думать о каждом запросе и всё же получать приличные результаты?

Здесь на сцену выходит OpenRouter — агрегатор с одной фишкой: один API-ключ, сотни моделей, и у многих из них есть бесплатные версии с суффиксом :free. Цена — ноль. Пафос — ноль. Но и лимиты соответствующие: без пополнения счёта всего 50 запросов в день на все свободные модели вместе. Для агента этого обычно мало.

Что такое OpenRouter и зачем он нам, хомлабистам

OpenRouter — это прокси-агрегатор LLM API. Один эндпоинт, один ключ, и ты получаешь доступ к Claude, GPT, Gemini, Qwen, Nemotron и ещё множеству моделей. Формат запросов OpenAI-совместимый: сменить модель можно заменой параметра model в запросе. Никаких отдельных аккаунтов под каждого провайдера и лишней волокиты.

И среди этого зоопарка есть модели с суффиксом :free. Их цена в токенах — 0. То есть ты можешь слать запрос, и с баланса не спишется ни копейки. Но есть важная оговорка: общий лимит на все бесплатные модели вместе взятые — 50 запросов в день. Пытаешься использовать субагента 60 раз — получаешь ошибку и начинаешь думать о платных вариантах.

Как поднять лимит с 50 до 1000 (разово)

Помогает разовое пополнение счёта на $10. Это не подписка и не ежемесячный платёж. Один раз вносишь десять долларов — и лимит поднимается до 1000 запросов в день на все свободные модели суммарно. 1000 — уже достаточно для рутины: проверки, черновики, лёгкие субагенты, ежедневные отчёты.

Проверить свой статус можно одной командой curl:

curl https://openrouter.ai/api/v1/auth/key \
  -H "Authorization: Bearer YOUR_KEY_HERE"

В ответе JSON будет поле is_free_tier: – true — лимит 50 запросов/день. – false — лимит 1000 запросов/день.

Проверено на нашем стенде: после пополнения поле сменилось на false, и лимит стал 1000.

Живые free-модели: таблица, которую можно повесить на стенд

Не все :free модели одинаково полезны. Вот список проверенных в день написания статьи (21 августа 2026):

Модель Контекст Примечание
nvidia/nemotron-3.5-lightning:free 1 000 000 токенов Агентный режим, вызовы функций (tool calls) — работают
nvidia/nemotron-3-super-120b-a12b:free 262 000 токенов Хороша для общих задач
google/gemma-4-31b-it:free 262 000 токенов Часты 429 из-за перегрузки
z-ai/glm-5.2:free 256 000 токенов Сильная, но тоже бывают 429
openai/gpt-oss-20b:free 131 000 токенов Есть vision, не всегда стабильна

Примечание: лимит 1000 запросов/день общий на все free-модели, а не на каждую отдельно. И 20 req/мин — потолок, его нужно учитывать.

Именно nemotron-3.5-lightning:free с её миллионным контекстом стал главным героем наших тестов: субагент на этой модели успешно решил задачу, потратив около 20 000 токенов — и всё это бесплатно. Плюс эта модель корректно отдаёт вызовы функций — удобно для автоматизаций, скриптов и управления через функции.

Грабли: 429, нестабильность и общий пул лимитов

Если просто заменить все запросы на nemotron-3.5-lightning:free, радость может быстро оборваться. Free-модели живут на общих серверах провайдеров, и в пиковые моменты они отдают HTTP 429 с ошибкой «Provider returned error». Это не блокировка — это перегрузка очереди. Решение: повтор с паузой (retry) или переключение на вторую свободную модель из списка.

Также важно помнить, что лимит 1000/день — общий. Если одновременно запустить десятки субагентов на разных :free моделях, часть упрётся в потолок и будет ждать следующего дня. Помогает умный каскад: сначала вычерпываем бесплатный лимит на рутину, затем падаем на дешёвые платные модели (они стоят копейки за 1K токенов), а дорогие — только по особым случаям, когда нужен Claude Opus или GPT-5.

Главный козырь: вызовы функций бесплатно

Самое интересное — nvidia/nemotron-3.5-lightning:free поддерживает вызовы функций (tool calls). Это значит, что субагент может не просто отвечать текстом, а инициировать вызовы пользовательских функций: читать файлы, выполнять скрипты, обращаться к внешним сервисам. И всё это — без затрат на токены.

Пример из практики: субагент на nemotron-3.5-lightning:free получил задачу, сам составил запрос к API, достал данные и отформатировал markdown-отчёт. Никаких трат, никаких заморочек — полноценный агентный режим на бесплатной модели.

Стратегия каскада: от бесплатного к платному

  1. Free-уровень (:free модели) — 1000 req/день, 20 req/мин. Для рутины: субагенты, проверки здоровья, генерация черновиков, простые вопросы.
  2. Дешёвый платный — glm-5.2, gemma-4-31b-it и др. за копейки за 1K токенов. Когда free-лимит исчерпан, но бюджет ещё ограничен.
  3. Платные флагманы — Claude Opus 5, GPT-5. Только если задача требует максимального качества или специфических возможностей, которых нет в дешёвых моделях.

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

Вывод

OpenRouter с его бесплатными моделями — рабочее решение для повседневных задач: лимиты скромные, но после разового пополнения на $10 получаешь 1000 запросов/день на общий пул :free. Главное — учитывать 429, ставить паузы на повторы и помнить про общий лимит. Плюс — поддержка вызовов функций на nemotron-3.5-lightning:free, что позволяет запускать автоматизации без токенных затрат.

Если давно считаешь расходы на LLM-API, попробуй OpenRouter. У нас лимит уже активирован, субагент на nemotron-3.5-lightning:free сегодня решил несколько задач — и ни копейки не списалось. Возможно, это будет тем самым «бесплатным апгрейдом» для твоих автоматизаций.


Публикация в канал «Цифровой дворник» — homelab, самохостинг, ИИ‑инфраструктура. Факты взяты из открытых настроек OpenRouter на дату написания статьи. Личный опыт может отличаться.

#selfhosting #openclaw #llm

Обложка

Цикл «Виды связности и SDN», часть 2. Предыдущая часть: «SDN без магии: карта видов связности».

Ось: underlay и overlay (транспорт).

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

Интернет в этой схеме — underlay. Туннель — overlay.

Что происходит с пакетом

Приложение формирует обычный IP-пакет. Overlay-компонент добавляет к нему свой заголовок, затем внешний IP-заголовок. Underlay видит только наружные адреса узлов туннеля и доставляет контейнер целиком.

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

VXLAN обычно вкладывает Ethernet-кадр в UDP. Geneve делает похожее, но имеет расширяемые поля параметров. IPIP помещает IPv4-пакет внутрь другого IPv4-пакета. GRE добавляет собственный заголовок между внешним IP и полезной нагрузкой. WireGuard не только инкапсулирует, но и шифрует содержимое.

Внешний заголовок не всегда UDP. IPIP использует IP protocol 4, GRE — protocol 47. У них нет номера TCP- или UDP-порта.

Требования к underlay

Минимальное требование почти всегда одно: адреса конечных точек туннеля должны быть достижимы друг для друга. Но дальше начинаются детали.

Для VXLAN и Geneve межсетевые экраны должны пропускать соответствующий UDP. Порт зависит от реализации, а не только от названия протокола:

Механизм Внешний транспорт Типичный порт
VXLAN по IANA UDP 4789
VXLAN в Linux, Cilium, Flannel UDP 8472
VXLAN в Calico UDP 4789
Flannel VXLAN на Windows UDP 4789
Geneve UDP 6081
WireGuard UDP 51820; Cilium — 51871
IPIP IP protocol 4 порта нет
GRE IP protocol 47 порта нет

Если firewall разрешает только TCP и UDP, правило «порт для IPIP» не поможет: такого порта не существует.

Цена заголовков

Обычный Ethernet часто имеет MTU 1500. После добавления внешних заголовков внутри туннеля остаётся меньше места.

Примерные накладные расходы:

Механизм IPv4 IPv6
IPIP 20 — (это IPv4-in-IPv4)
VXLAN 50 70
Geneve без options ~50 ~70
WireGuard 60 80

VXLAN 50 байт на IPv4 складываются так: внешний IPv4 (20) + UDP (8) + VXLAN (8) + внутренний Ethernet (14). IPIP Ethernet внутрь не кладёт, поэтому налог меньше. Options у Geneve увеличивают размер сверху базовых 50. VXLAN поверх WireGuard складывает расходы обоих слоёв.

Если inner MTU не уменьшить, большой пакет придётся фрагментировать или отправитель должен узнать допустимый размер через Path MTU Discovery. Когда ICMP-сообщения о необходимости уменьшить пакет фильтруются, возникает PMTUD black hole.

Для IPv4 это ICMP Type 3 Code 4 (Fragmentation Needed). Для IPv6 — ICMPv6 Packet Too Big: промежуточные маршрутизаторы IPv6 не фрагментируют, поэтому без PTB большой пакет просто не проходит.

Маленький ping проходит, SSH открывается, а загрузка страницы или передача большого файла зависает. Администратор смотрит на зелёный мониторинг и начинает подозревать приложение. Приложение обычно ни при чём.

Overlay не повышает качество underlay

Если underlay теряет 3% пакетов, WireGuard их не вернёт. Если между площадками 90 мс задержки, VXLAN не сделает 2 мс. Если маршрутизация асимметрична, stateful firewall может продолжать отбрасывать часть трафика.

Добавляется собственная служебная нагрузка:

  • keepalive для сохранения NAT mapping;
  • сообщения control plane;
  • STUN и negotiation для mesh-сетей;
  • BFD или другие проверки доступности;
  • дополнительная обработка и шифрование.

Поэтому сначала проверяют underlay: адреса, маршруты, потери, задержку, MTU, ECMP и firewall. Затем — overlay.

Overlay и ECMP

Внешняя сеть принимает решение по внешним заголовкам. Если все внутренние потоки между двумя узлами получают одинаковую внешнюю пару адресов и портов, underlay может считать их одним большим потоком и отправлять по одному ECMP-пути.

Некоторые реализации меняют UDP source port на основе хеша внутреннего потока. Тогда разные пользовательские соединения лучше распределяются между равнозначными путями. Это важная деталь для производительности фабрики ЦОД, хотя конечные виртуальные машины о ней не знают.

Где ставить границу

Overlay можно завершить на:

  • физическом маршрутизаторе;
  • коммутаторе с VTEP;
  • гипервизоре;
  • Kubernetes-узле;
  • отдельном шлюзе площадки;
  • клиентском ноутбуке.

Чем ближе конечная точка к приложению, тем меньше незашифрованный участок и точнее политики. Но тем больше агентов, ключей, туннелей и состояний приходится обслуживать.

Практический порядок диагностики

  1. Проверить достижимость внешних адресов конечных точек.
  2. Проверить разрешённый внешний протокол и порт.
  3. Измерить максимальный пакет без фрагментации.
  4. Посмотреть route lookup до внешнего адреса туннеля.
  5. Проверить состояние интерфейса туннеля.
  6. Снять дамп одновременно до и после инкапсуляции.
  7. Только после этого разбирать маршруты и политики внутри overlay.

Где это ломается

  • Inner MTU оставили 1500, а ICMP Fragmentation Needed или IPv6 Packet Too Big отфильтровали.
  • Ищут «порт VXLAN», а реализация слушает 8472 вместо 4789 — или наоборот.
  • Пытаются открыть «порт IPIP» на firewall, который пропускает только TCP/UDP.
  • Overlay считают лечением потерь и асимметрии underlay.
  • Все внутренние потоки схлопываются в один ECMP-путь из-за одинаковой внешней 5-tuple.

В следующей части поднимемся на L2 и попробуем растянуть Ethernet. Посмотрим, зачем VXLAN понадобился VNI, какую работу выполняет EVPN и почему broadcast-домен через несколько площадок нужно создавать только при наличии уважительной причины.

Предыдущая часть: «SDN без магии: карта видов связности»

Оглавление цикла: «SDN без магии: карта видов связности»

Следующая часть: «L2-overlay: VLAN, VXLAN, Geneve и EVPN»

Схема

#network #selfhosting

Обложка

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

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

Часть этой проблемы можно решить двумя функциями, которые есть во многих аналоговых радиостанциях:

  1. тоновым шумоподавителем CTCSS или DCS;
  2. скремблером.

Они решают разные задачи и лучше всего работают вместе. Но сначала важно понять, чего они не делают: они не очищают эфир и не добавляют новую частоту.

Что именно нам мешает

В динамике рации могут оказаться три разных вида неприятностей.

Шум свободного канала. Шипение, треск и короткие открытия шумоподавителя из-за слабых сигналов или промышленной помехи.

Чужие переговоры. Кто-то законно или не очень работает на той же частоте. Его сигнал достаточно сильный, поэтому ваша рация принимает его как обычную передачу.

Настоящая радиопомеха. Два передатчика говорят одновременно, рядом работает мощный источник излучения либо приёмник перегружается сигналом с соседней частоты. Здесь страдает уже не только душевное спокойствие оператора, но и возможность разобрать полезную речь.

Тоны хорошо помогают с первыми двумя пунктами на уровне динамика. С третьим они почти ничего сделать не могут.

Что такое CTCSS и DCS

CTCSS — это непрерывный низкочастотный тон, который рация незаметно добавляет к голосу при передаче. DCS решает ту же задачу, но передаёт специальную цифровую кодовую последовательность.

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

Происходит примерно следующее:

  • наш сотрудник нажимает PTT — его рация передаёт голос и служебный тон;
  • рации нашей группы узнают тон и включают динамики;
  • посторонний передатчик приходит без нашего тона — индикатор занятого канала может загореться, но динамик останется закрытым.

В меню и программах настройки встречаются два отдельных поля:

TX Tone, Encode, передающий тон — код, который рация добавляет к нашей передаче.

RX Tone, Decode, принимающий тон — код, без которого наша рация не откроет динамик.

Чтобы группа работала предсказуемо, обычно задают одинаковый код и на TX, и на RX у всех её радиостанций.

Это и называют «закрыть приём и передачу тоном». Название немного обманчивое. Передача не становится закрытой или секретной. Любая рация с отключённым RX-тоном услышит нас совершенно нормально. Тон лишь управляет тем, когда открывать динамик.

Производители иногда называют такие коды privacy codes или «субканалами», но отдельного канала они не создают. Десять групп с разными тонами на одной частоте всё равно делят один и тот же кусок эфира и могут мешать друг другу.

Тогда зачем нужен скремблер

Простой аналоговый скремблер изменяет звуковой сигнал перед передачей — чаще всего переворачивает его частотный спектр. Для обычной рации речь после этого звучит как смесь утиного голоса, бульканья и переговоров инопланетного диспетчера.

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

Получается удобное разделение обязанностей:

  • CTCSS/DCS не даёт динамику открываться на чужие передачи;
  • скремблер не даёт случайному слушателю с обычной рацией понимать наши переговоры.

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

Как канал выглядит до и после

Схема 1. Что меняется после включения RX CTCSS/DCS

До настройки рация воспроизводит все сигналы, после RX CTCSS/DCS динамик открывается только при правильном тоне Обратите внимание: после настройки из динамика исчезает лишний звук.

Ситуация Открытый аналоговый канал CTCSS/DCS CTCSS/DCS + скремблер
Посторонний говорит на нашей частоте с другим тоном Слышим его полностью Динамик обычно молчит Динамик обычно молчит
Посторонний слушает нашу передачу обычной рацией Понимает речь Всё ещё понимает речь Слышит искажённую, обычно непонятную речь
В эфире короткий треск без нужного тона Рация может открыться и захрипеть Обычно остаётся тихой Обычно остаётся тихой
Два человека передают одновременно Речь ломается или побеждает более сильный сигнал Происходит то же самое Происходит то же самое, иногда разборчивость ещё хуже
Наш сигнал слабый, на границе покрытия Слышны шумы и пропадания Тон может определяться нестабильно, начало фразы иногда обрезается К шумам добавляются артефакты скремблера
Дальность связи Исходная Не увеличивается Не увеличивается, иногда полезная разборчивость немного снижается

То есть субъективно после настройки эфир становится намного чище. В комнате больше не бубнят посторонние, рация не вскрикивает от каждого случайного сигнала, а рабочие переговоры слышны только тогда, когда говорит своя группа.

Физически же частота остаётся ровно такой же занятой, как и раньше.

Что будет с помехами после включения тонов

Здесь полезно разделять «не слышу помеху» и «помеха не влияет».

Если в эфире появился слабый шум или чужая передача без нужного тона, динамик не откроется. Для сотрудника проблема будто исчезла.

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

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

Поэтому результат выглядит так:

  • помеха без нужного тона и без одновременной полезной передачи — скорее всего, мы её просто не услышим;
  • помеха одновременно с нашей передачей — связь может оборваться или стать неразборчивой;
  • очень сильная или широкополосная помеха — тон не спасёт от перегрузки приёмника;
  • слабый полезный сигнал — декодирование тона и работа скремблера могут добавить задержки, обрывы начала фразы и артефакты.

Схема 2. Где скремблер и тон уже не могут помочь

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

Ещё одна полезная настройка: Busy Channel Lockout

Есть отдельная функция BCL или BCLO — блокировка передачи на занятом канале. Она не даёт рации начать передачу, пока приёмник видит чужую несущую.

Если задача — не говорить поверх посторонних, лучше использовать блокировку по наличию несущей, а не только по совпадению тона. Иначе чужая группа с другим CTCSS будет для динамика невидимой, а сотрудник спокойно нажмёт PTT и затрёт сразу обе передачи.

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

Практический рецепт

Для одной рабочей группы на всех станциях выставляем:

  1. одинаковую частоту и ширину канала;
  2. одинаковый CTCSS-тон или DCS-код на передачу и приём;
  3. одинаковый тип и режим скремблера;
  4. обычный, не чрезмерно «тугой» уровень шумоподавителя;
  5. при необходимости — блокировку передачи по занятой несущей.

После программирования обязательно проверяем три сценария:

  1. Все свои рации слышат друг друга в обоих направлениях.
  2. Передача без правильного тона не открывает динамик, но отображается как занятость канала.
  3. На границе реальной зоны покрытия речь остаётся разборчивой со включённым скремблером.

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

Как это выглядит на Baofeng и TYT

Baofeng и TYT здесь особенно удобны как примеры: недорогих раций этих марок много, программируются они относительно просто, но набор функций сильно зависит от модели и даже её аппаратной ревизии.

Baofeng

У классического Baofeng UV-5R есть CTCSS и DCS с раздельной настройкой приёма и передачи. В меню используются вполне говорящие названия:

  • R-CTCS — CTCSS на приём;
  • T-CTCS — CTCSS на передачу;
  • R-DCS — DCS на приём;
  • T-DCS — DCS на передачу.

В программе для настройки те же параметры могут называться Tone, ToneSql, DTCS, RX DTCS или Cross Mode. Смысл не меняется: передатчик должен отправлять правильный код, а приёмник — ждать его.

Но у базового UV-5R нет штатного голосового скремблера. На нём можно закрыть динамик тоном и избавиться от чужих разговоров, но нельзя штатными средствами сделать свою речь непонятной постороннему слушателю.

У более новых Baofeng скремблер уже встречается. Например, производитель отдельно заявляет его для UV-17R Plus, K6 и некоторых других моделей. Поэтому при закупке надо смотреть характеристики именно выбранной модификации, а не ориентироваться на надпись Baofeng на корпусе: внешне похожие рации могут иметь совсем разный набор функций.

TYT

У TYT картина похожая, но моделей со скремблером заметно больше. Например, у портативной TYT TH-UV88 заявлены CTCSS/DCS и несколько режимов скремблера. У автомобильной TYT TH-9000D Plus производитель указывает CTCSS, DCS, восемь групп скремблера и Busy Channel Lockout.

В меню или программе TYT нужные поля могут называться CTCSS/DCS Encode, CTCSS/DCS Decode, QT/DQT, Scrambler, Scramble Group или Voice Encrypt. Последнее название не должно вводить в заблуждение: в аналоговом режиме речь обычно идёт всё о том же простом скремблере, а не о стойком цифровом шифровании.

Если в одном парке есть обе марки

Стандартные CTCSS-тоны обычно нормально работают между Baofeng и TYT. С DCS нужно дополнительно проверить не только номер кода, но и его вариант — Normal или Inverted, иногда обозначаемый буквами N и I.

А вот одинаковая цифра в пункте Scrambler ещё не означает совместимость. Производители могут использовать разные частоты инверсии и разные алгоритмы. В результате две рации вроде бы включают «скремблер № 1», но вместо нормального голоса по-прежнему выдают утку, упавшую в ведро.

Поэтому смешанный парк настраиваем поэтапно:

  1. Выключаем скремблер и добиваемся нормальной связи между всеми моделями.
  2. Настраиваем одинаковые TX/RX CTCSS или DCS и снова проверяем всю группу.
  3. Включаем скремблер на одной паре Baofeng и TYT и проверяем речь в обоих направлениях.
  4. Если совместимости нет, формируем группы из одинаковых моделей либо оставляем скремблер выключенным. Тона при этом продолжат работать.

Это тот случай, когда десятиминутная проверка двух образцов перед закупкой полезнее длинной таблицы характеристик из магазина.

А может, сразу купить недорогие DMR?

Короткий ответ: можно, и базовая станция для этого не нужна.

В DMR есть режим Direct Mode, он же DMO, simplex или point-to-point. Две или несколько раций связываются непосредственно друг с другом на одной частоте — примерно как обычные аналоговые портативки. Никакой регистрации на базовой станции, SIM-карт, интернета и центрального сервера не требуется.

В контексте обычной профессиональной радиосвязи под «базовой станцией» чаще имеют в виду ретранслятор: он принимает передачу одной рации и повторяет её для остальных. В Direct Mode такого промежуточного узла просто нет.

DMR Tier II умеет работать и напрямую, и через ретранслятор. Поэтому небольшую сеть можно начать с комплекта портативных раций, а инфраструктуру добавить позднее, если понадобится расширять покрытие. Само наличие слов Tier II или Repeater capable не означает, что без ретранслятора устройство превратится в кирпич.

Схема 3. DMR сейчас и возможное развитие сети

DMR-рации работают напрямую без базовой станции, ретранслятор добавляется для расширения покрытия В Direct Mode рации общаются друг с другом напрямую. Ретранслятор можно добавить позднее — для увеличения зоны покрытия, а не для того, чтобы связь вообще заработала.

Что должно совпадать у DMR-раций

Для аналоговой группы достаточно согласовать частоту и тон. У DMR параметров больше. Для прямой связи обычно настраивают:

  • одинаковую частоту приёма и передачи, то есть simplex-канал;
  • цифровой режим канала;
  • одинаковый Color Code — условный цифровой аналог тонового фильтра;
  • одинаковый таймслот, если модель использует его в прямом режиме;
  • одинаковую группу вызова, или Talk Group;
  • включение этой группы в список принимаемых групп;
  • уникальный Radio ID для каждой рации;
  • совместимый режим допуска к передаче — обычно сначала выбирают вариант, не позволяющий говорить поверх занятого канала.

Color Code и Talk Group не шифруют разговор. Они помогают рации понять, к какой логической группе относится принятый цифровой вызов. Человек с подходящей DMR-рацией и правильно настроенным приёмом всё ещё может услышать передачу.

Сначала цифровой канал лучше поднимать без шифрования и дополнительных privacy-функций. Когда все модели устойчиво слышат друг друга, можно отдельно проверять поддерживаемую защиту. У бюджетных радиостанций режимы с названиями Basic Privacy, Enhanced Privacy, Encryption и AES могут отличаться по реализации и не работать между разными марками.

Один или два разговора на одной частоте

Обычный DMR Direct Mode даёт один разговор в канале шириной 12,5 кГц. Более интересный вариант называется Dual Capacity Direct Mode, DCDM, Dual Slot Direct или «два таймслота point-to-point».

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

Но DCDM — функция, которую надо проверять у конкретной модели. Если одна рация умеет два таймслота напрямую, а другая — только обычный DMO, красивый пункт в характеристиках не поможет. Для смешанного парка разумнее сначала добиться связи в обычном прямом режиме и только потом испытывать два таймслота.

Что DMR меняет в зашумлённом эфире

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

Но цифровая связь не отменяет физику:

  • чужой сигнал с другим Color Code может не открывать динамик, но продолжает занимать частоту;
  • две одновременные передачи могут столкнуться;
  • мощная помеха способна сорвать декодирование;
  • на границе покрытия вместо всё более шумного голоса появляется «цифровой обрыв»: сначала металлические артефакты, затем речь исчезает целиком;
  • дальность без ретранслятора определяется мощностью, антеннами, рельефом и качеством приёмников, а не надписью DMR на коробке.

Поэтому DMR часто делает связь субъективно чище, но не гарантирует большую дальность и не лечит постоянно занятую частоту.

А что с реальной дальностью

Сначала разберёмся с названиями:

  • VHF — обычно портативная связь в районе 136–174 МГц;
  • UHF — обычно 400–470 МГц;
  • LPD433 — маломощные каналы внутри UHF-диапазона около 433 МГц;
  • DMR — цифровой способ передачи, который может работать как на VHF, так и на UHF.

Поэтому отдельной «дальности DMR» не существует. DMR-рация на 433 или 446 МГц распространяет радиосигнал примерно по тем же законам, что и аналоговая UHF-рация той же мощности с такой же антенной.

Ниже — не паспортные обещания, а практический ориентир для двух портативных раций со штатными короткими антеннами, без ретранслятора. Обе находятся примерно на высоте 1,5 метра. Под «полем» понимается открытая относительно ровная местность с прямой видимостью, под «городом» — связь с улицы на улицу среди среднеэтажной и плотной застройки. Внутри зданий результат может быть заметно хуже.

Диапазон Мощность Открытое поле Городская застройка
VHF 136–174 МГц 3 Вт примерно 3–6 км примерно 0,8–2 км
VHF 136–174 МГц 5 Вт примерно 4–8 км примерно 1–3 км
VHF 136–174 МГц 10 Вт примерно 5–10 км примерно 1,5–4 км
UHF 400–470 МГц 3 Вт примерно 2–5 км примерно 0,5–1,5 км
UHF 400–470 МГц 5 Вт примерно 3–7 км примерно 0,8–2,5 км
UHF 400–470 МГц 10 Вт примерно 4–9 км примерно 1–3,5 км

Для DMR Direct Mode используем ту же строку VHF или UHF.

VHF обычно выгоднее на открытой местности, среди растительности и при работе через невысокие препятствия. UHF удобнее для компактных портативок и нередко лучше ведёт себя внутри зданий, в коридорах и среди металлических конструкций. Но в конкретном городе расположение домов, железобетон, перепады высот и промышленный шум легко оказываются важнее выбора между 160 и 430 МГц.

Почему 10 Вт не дают вдвое большую дальность

Переход с 3 до 5 Вт добавляет всего около 2,2 дБ, а с 5 до 10 Вт — 3 дБ. В идеальном свободном пространстве удвоение мощности увеличивает дальность примерно в 1,4 раза. В городе выигрыш обычно ещё скромнее.

Кроме того, увеличение мощности улучшает только передачу. Чувствительность приёмника, чужой передатчик, помехи и радиогоризонт от этого не меняются. Поднять рацию выше, выйти из-за железобетонной стены или поставить нормальную антенну зачастую полезнее, чем переключиться с 5 на 10 Вт. Зато аккумулятор на 10 Вт разряжается быстрее, а сама станция сильнее нагревается.

Для двух раций на высоте человеческого роста радиогоризонт (с учётом рефракции) находится около 9–10 км. Поэтому обещанные на коробке 20–50 км для портативок возможны лишь с вершины на вершину, с высокой точки на открытую местность или в других специально удачных условиях.

Отдельно про LPD433

LPD расшифровывается как Low Power Device — маломощное устройство. В российском решении ГКРЧ для маломощных радиостанций 433,075–434,750 МГц указана максимальная излучаемая мощность 10 мВт, то есть 0,01 Вт.

Для настоящей LPD-рации на 10 мВт разумно ожидать примерно 0,3–1,5 км в открытом поле и 0,1–0,5 км в городе. Через несколько железобетонных стен дальность может сократиться до сотен или даже десятков метров.

Если выставить на частоте из сетки LPD мощность 3, 5 или 10 Вт, с точки зрения физики получится обычная UHF-связь — можно ориентироваться на строки UHF в таблице. Но с точки зрения разрешённого маломощного режима это уже не LPD. Возможность выбрать такую частоту и мощность в китайской рации ещё не означает, что подобная передача разрешена.

Главный вывод по дальности простой: частота и мощность задают только исходные возможности. Реальную связь определяют высота, антенна, прямая видимость, застройка и уровень помех.

Какие недорогие модели посмотреть

Не как окончательный рейтинг, а как отправную точку можно рассмотреть несколько распространённых моделей.

Модель Что интересно Что проверить перед закупкой
Baofeng DM-1701 Двухдиапазонная аналоговая/DMR-рация, Tier I/II, заявлен прямой двухслотовый режим Удобство штатной CPS, нужный диапазон частот, совместимость DCDM и защиты с остальным парком
Baofeng DM-32UV Более новая многодиапазонная DMR-модель с двумя таймслотами Не переплачиваем ли за функции, которыми никто не будет пользоваться; стабильность прошивки и программирования
TYT MD-UV380 Аналог + DMR, два диапазона, производитель заявляет два таймслота point-to-point Конкретную аппаратную версию, комплектный кабель, версию CPS и требуемые функции защиты
TYT MD-UV390 Похожая логика, но корпус с заявленной защитой IP67; есть point-to-point dual slot Реальную герметичность конкретной поставки, совместимость аксессуаров и одинаковую прошивку всей партии

Для обычной рабочей группы я бы начинал с TYT MD-UV380/390 или Baofeng DM-1701, если важна минимальная цена и есть человек, который один раз нормально соберёт codeplug. Более новая и мощная модель не обязательно окажется удобнее в повседневной эксплуатации.

Главный риск дешёвого DMR — не качество цифрового стандарта, а зоопарк прошивок, программ, драйверов кабеля и по-разному реализованных дополнительных функций. Поэтому правильная закупка выглядит так:

  1. Берём две рации выбранной модели, а не сразу двадцать.
  2. Создаём аналоговый канал для совместимости со старым парком.
  3. Создаём простой DMR Direct-канал без шифрования.
  4. Проверяем связь в здании, на улице и в тех местах, где аналог сейчас хрипит или пропадает.
  5. Отдельно проверяем Color Code, групповые вызовы, блокировку занятого канала и DCDM.
  6. Если нужна защита разговоров, проверяем её на записи и между всеми моделями группы.
  7. Только после этого фиксируем прошивку, сохраняем эталонный codeplug и покупаем партию.

Аналог со скремблером или DMR Direct?

Задача Аналог + CTCSS/DCS + скремблер DMR Direct Mode
Сохранить существующий парк дешёвых раций Отлично подходит Потребуется замена или постепенная миграция
Убрать чужие голоса и шипение Тон закрывает динамик, но слабый сигнал всё равно хрипит Обычно тише и чище до цифрового порога
Скрыть речь от случайного слушателя Простой скремблер, слабая защита Цифровая речь уже не слышна аналоговой рацией, но для конфиденциальности нужна отдельная совместимая защита
Работать без базовой станции Да Да, в Direct Mode
Позднее добавить ретранслятор Зависит от раций и частотного плана Для Tier II это штатный путь развития
Использовать Baofeng и TYT вместе Тоны обычно совместимы, скремблер под вопросом Базовые вызовы DMR обычно совместимы при одинаковом профиле, дополнительные функции надо испытывать

Если существующие аналоговые рации устраивают по дальности, начать с тонов и скремблера дешевле. Если парк всё равно пора менять, а хочется групповых вызовов, идентификаторов, более спокойного звука и возможности позднее поставить ретранслятор, DMR Direct выглядит разумнее.

Когда это решение подходит, а когда уже нет

CTCSS/DCS со скремблером — хороший недорогой способ привести в порядок существующую аналоговую связь небольшой организации. Он убирает из динамиков эфирный мусор и защищает разговоры от случайных слушателей. DMR Direct Mode — следующий разумный шаг, если парк всё равно предстоит обновлять: для старта ему тоже не нужна базовая станция.

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

Короткая формула такая:

Тон делает эфир тише. Скремблер делает речь менее понятной посторонним. Свободнее и устойчивее радиоканал от этого не становится.

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

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

#radio #ctcss #dcs #scrambler #dmr #baofeng #tyt

Когда начинал, казалось, что Docker — это стандарт: compose, образы, всё из коробки. Но для домашнего сервера, где крутится 10+ сервисов, LXC на Proxmox оказался удобнее. Рассказываю, почему.

LXC — это почти VM, но легче

LXC — это изоляция на уровне ядра: у каждого контейнера свои процессы, своя сеть, свой корень. Но при этом он делит ядро и память хоста. По сути — «лёгкая VM без эмуляции железа».

В моей лабе каждый сервис — отдельный LXC: Caddy, Ollama, ComfyUI, Frigate, Kuma, Beszel, Immich. У каждого свой IP, свой systemd, свои порты. Никакого docker-compose — просто контейнер с сервисом.

Почему LXC удобнее Docker для дома

  • Обновления — pct upgrade, как обычная система. Не надо пересобирать образы
  • Бэкап — снапшот целиком через pct snapshot. Один снапшот = весь сервис со всеми данными
  • Ресурсы — лимиты CPU/RAM/диска выставляются на лету, без рестарта
  • Сеть — у каждого свой IP. Нет проброса портов и docker networks
  • Железо — GPU, USB, /dev пробрасываются напрямую в контейнер
  • Нагрузка — LXC практически не ест ресурсов: это просто процесс на хосте

Почему LXC лучше VM

VM эмулирует железо целиком — своя ОС, своё ядро, свои драйверы. Это дорого:

  • RAM — каждая VM резервирует память под свою ОС. 5 VM по 2 ГБ = 10 ГБ только на системы
  • Диск — каждая VM тащит свой образ ОС (гигабайты). LXC шарит корень хоста
  • Скорость — LXC стартует за секунды, VM — минуты
  • Нагрузка — на одном железе можно держать 20+ LXC, а VM — 3–5

LXC даёт почти ту же изоляцию, что и VM, но без эмуляции. Для дома — золотая середина.

Когда Docker всё-таки нужен

Честно: у меня Docker тоже есть — там, где готовый образ с кучей зависимостей проще поднять через compose (Frigate, Kuma). Но как только сервис начинает «жить» — переезжает в LXC.

Вывод: для домашнего хостинга LXC — это изоляция VM, скорость процесса и простота обычного Linux. Docker — для готовых образов, VM — когда нужна своя ОС целиком. Всё остальное — LXC.

#selfhosting

Обложка

Когда пришлось слезать с VMware на что-то реестровое, у всех всплыл один и тот же вопрос: «а на чём теперь крутить виртуалки?». Рынок мгновенно расцвёл — на карте уже больше трёх десятков логотипов. Но если открыть капот, почти всё сводится к двум гипервизорам: KVM и Xen. Разница — в обвязке.

Два столпа

KVM — гипервизор прямо в ядре Linux. Это не отдельная программа: ядро получает модуль kvm, и каждая виртуалка превращается в обычный процесс — qemu эмулирует ей железо (диски, сеть, PCI), а libvirt даёт единый API сверху. Плюс: виртуалка наследует весь зоопарк ядра — планировщик, memory management, cgroups. Минус: qemu сам по себе тяжёлый, и «поднять вручную» без libvirt быстро превращается в боль.

Xen — гипервизор отдельного типа: он стоит ниже операционных систем и запускает их как «домены». Есть привилегированный домен dom0 (управляющий) и рабочие domU. Классика Xen — паравиртуализация: гость знает, что он гость, и зовёт гипервизор напрямую, без полной эмуляции железа. Современный Xen умеет и HVM с аппаратной виртуализацией. Управляется через xapi/XAPI — тот же стек, что в XCP-ng.

Коротко: KVM — «виртуалка как процесс в Linux», Xen — «виртуалка как отдельный домен под гипервизором». Для админа разница чаще в обвязке, чем в производительности.

Кто на чём сидит

На oVirt (менеджмент поверх KVM) — целая пачка известных имён: РЕД Виртуализация, ROSA Virtualization, HOSTVM. Все трое — это KVM под капотом, а отличаются консолью, поддержкой и порталами для провайдеров.

На OpenStack (облачная платформа, тоже поверх KVM) — «Кибер Инфраструктура» и «Кибер Протект». Тут уже не просто виртуалки, а полноценный IaaS с тенантами и самообслуживанием.

На OpenNebula — «Альт Сервер Виртуализации» (basealt). Менее раскрученный, но тоже KVM-менеджмент.

Proxmox стоит отдельно: свой стек на KVM + LXC, без привязки к oVirt/OpenStack. Любимчик сисадминов за простоту.

«Собственная разработка» — самая интересная полка: БАЗИС.Dynamix, Брест, Астра, VMmanager, Space, ДаКом и остальные. Тут у каждого свой менеджмент-слой и свой гипервизор — но в ядре всё равно чаще всего KVM (реже Xen), просто написанный с нуля UI и кластерная логика.

Мораль

По данным исследования рынка на 2025 год, больше половины известных решений — это не уникальные технологии, а разные упаковки над одними и теми же открытыми гипервизорами. Поэтому выбирать стоит не по логотипу, а по трём вещам: кто поддержит, как переживается потеря узла и насколько честно работает живая миграция. «Под капотом» у большинства — одно и то же, а вот «что снаружи» — разное.

#selfhosting #network

Обложка

Цикл «Виды связности и SDN», часть 1.

Оси этой части: карта координат — уровень, underlay/overlay, управление, топология, шифрование.

Слово SDN успело побывать всем: технологией, архитектурой, пунктом в коммерческом предложении и наклейкой на обычном VPN с веб-интерфейсом. Из-за этого обсуждение часто начинается вопросом «что лучше — L3, mesh или WireGuard?» Примерно как «что лучше — грузовик, дизель или кольцевая дорога?»

Чтобы дальше не путаться, сначала разложим связность по отдельным осям. Через весь цикл используется одна лаборатория: офис за NAT, ЦОД A с белым IPv4, ЦОД B за CGNAT, облачная ВМ, ноутбук администратора и небольшой Kubernetes-кластер. Эту же инфраструктуру будем соединять разными способами.

Уровень сети

На L2 мы переносим Ethernet-кадры и имеем дело с MAC-адресами, ARP, broadcast и VLAN. Такой overlay может сделать вид, что две виртуальные машины в разных ЦОДах подключены к одному коммутатору.

На L3 мы переносим IP-пакеты и маршрутизируем отдельные сети. За каждым узлом или площадкой может находиться собственная подсеть, а остальная система должна знать путь до неё.

Сервисный overlay идёт ещё выше. Он может вообще не выдавать участнику адрес общей виртуальной сети, а предоставлять доступ только к конкретному приложению: например, к crm.internal:443. Так работает часть ZTNA-решений и OpenZiti.

Underlay и overlay

Underlay — сеть, которая уже умеет доставить внешний пакет от одного узла до другого. Это может быть Интернет, операторский L3VPN, собственная магистраль или IP-фабрика ЦОД.

Overlay — логическая сеть поверх неё. Исходный пакет помещается внутрь другого пакета и едет по underlay как груз в контейнере. VXLAN, Geneve, IPIP, GRE, WireGuard и IPsec делают это по-разному, но общая идея одна.

Overlay способен скрыть устройство нижележащей сети от конечных систем. Но он не чинит потери, перегруженные каналы, сломанный PMTUD и неправильную маршрутизацию под ним. Он только добавляет ещё одно место, где можно искать проблему.

Кто принимает решения

У сети может быть центральный контроллер. Он знает участников, выдаёт адреса, распространяет политики и сообщает узлам, как связаться друг с другом.

При этом пользовательский трафик не обязан идти через контроллер. В Tailscale, NetBird и похожих системах управление централизовано, а data plane по возможности строится напрямую между участниками.

Другой вариант — распределённый control plane. Например, маршрутизаторы обмениваются маршрутами по BGP, и каждый самостоятельно строит таблицу пересылки.

Есть смешанные схемы: центральная база хранит желаемое состояние, локальные агенты применяют политики, а маршруты распространяются распределённым протоколом.

Топология

Point-to-point — один туннель между двумя участниками.

Hub-and-spoke — все филиалы подключаются к центральному хабу. Просто управлять, но хаб становится транзитной точкой и потенциальным местом отказа.

Partial mesh — прямые связи создаются только там, где они нужны.

Full mesh — каждый участник может иметь прямую связь с каждым. Число потенциальных пар растёт квадратично; счёт и выбор топологии — в части 6.

Dynamic mesh не обязан держать все туннели постоянно. Контроллер может выдать двум узлам координаты друг друга только при появлении трафика.

Шифрование

VXLAN, Geneve, IPIP и GRE сами по себе не защищают содержимое. Они решают задачу переноса пакета, а не конфиденциальности.

MACsec шифрует связь на L2 между соседними устройствами. IPsec и WireGuard защищают IP-трафик между узлами. TLS и mTLS защищают конкретные прикладные соединения.

Иногда эти слои складываются: пакет приложения уже защищён TLS, затем попадает в VXLAN, а весь межузловой трафик дополнительно помещается в WireGuard. Без расчёта MTU такой сетевой матрёшке быстро становится тесно.

Где здесь SDN

Software-defined networking начинается там, где желаемая логика сети описывается программно и отделяется от конкретного устройства, пересылающего пакет.

Контроллеру говорят: «эта группа может обращаться к сервису, эти две сети изолированы, а маршрут площадки должен иметь два выхода». Он переводит это намерение в правила OVS, eBPF-программы, маршруты BGP, ACL или конфигурации туннелей.

Генератор десяти peer-конфигов WireGuard — это автоматизация, а не SDN. Между таким скриптом и OVN с распределёнными логическими маршрутизаторами лежит заметная архитектурная дистанция: во втором случае есть модель намерения, отдельный control plane и независимый data plane.

Пять вопросов перед выбором

Перед обсуждением продукта полезно ответить:

  1. Нам нужен Ethernet или маршрутизация IP?
  2. Какая сеть уже существует между узлами?
  3. Кто будет распространять адреса, маршруты, ключи и политики?
  4. Нужны прямые связи или допустим центральный транзит?
  5. Какое содержимое и между какими точками должно быть зашифровано?

После этого сравнение становится честнее. VXLAN конкурирует с Geneve как способ инкапсуляции. BGP и контроллер OVN решают задачу распространения состояния. WireGuard добавляет защищённый транспорт. Mesh описывает отношения между участниками.

Где это ломается

  • Overlay не чинит сломанный underlay: потери, асимметрия и фильтр ICMP остаются на месте.
  • «Пинг проходит» не означает исправный HTTPS: обычно виноват MTU, а не приложение.
  • Контроллер и data plane — разные отказы; зелёная панель не доказывает, что пакеты ходят напрямую.
  • Full mesh на схеме ещё не означает, что все пары реально подняты и нужны.
  • Сравнение «VXLAN vs контроллер vs WireGuard» почти всегда смешивает разные оси.

В следующей части разберём underlay и overlay подробнее: что именно вкладывается в туннель, откуда берётся потерянный MTU и почему «пинг проходит» ещё не означает исправную связность.

Предыдущая часть: —

Оглавление цикла: «SDN без магии: карта видов связности»

Следующая часть: «Underlay и overlay: сеть под сетью»

Схема

#network #selfhosting

Цикл «Не светим лишнего». Выпуск 3.

VPN обычно всплывает первым: «Надо пустить человека во внутреннюю сеть? Давайте VPN». И это не глупый ответ. Туннель даёт клиенту виртуальный адрес, шифрует трафик и позволяет работать с приватными IP так, будто пользователь находится рядом.

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

Что VPN действительно умеет хорошо

Пользователь может открыть обычный RDP-клиент, SSH, WinBox, 1С, базу данных, файловую шару — всё, что говорит по IP. Не нужно публиковать каждый внутренний сервис отдельным DNAT. На шлюзе можно назначать разные адресные пулы и политики группам пользователей. Индивидуальный сертификат или ключ позволяет отличить устройства лучше, чем внешний IP.

Если есть филиал, постоянный администратор или управляемый корпоративный ноутбук, это очень удобная модель.

Split tunnel означает, что в туннель идут только нужные сети, а обычный Интернет остаётся через локального провайдера. Full tunnel, наоборот, забирает через корпоративный шлюз почти весь трафик клиента.

Где начинаются неудобства

На рабочей машине уже может быть VPN заказчика, личный WireGuard, агент безопасности с собственным туннелем или второй корпоративный клиент. Два туннеля начинают делить маршруты, DNS и приоритеты интерфейсов. Если обе стороны используют популярную сеть вроде 10.0.0.0/8 или 192.168.1.0/24, часть адресов становится физически неотличимой.

Некоторые клиенты включают kill switch и режут локальные маршруты. Некоторые установки требуют административных прав. Мобильному подрядчику надо объяснить, какой профиль импортировать, что нажать и почему его антивирус ругается на новый сетевой адаптер.

Ещё одна неприятность — чрезмерная связность. Человеку нужен один сервер на 443-м порту, а ему выдали маршрут до всей /24, потому что так было быстрее настроить.

Плюсы VPN

  • шифрование между клиентом и шлюзом;
  • любые протоколы поверх IP;
  • не нужно публиковать внутренние адреса наружу;
  • индивидуальные ключи, сертификаты и пользовательские политики;
  • хорошая модель для постоянных сотрудников и управляемых устройств.

Минусы

  • профиль или отдельный клиент на устройстве;
  • конфликты маршрутов, DNS и других VPN;
  • пересечение внутренних адресных пространств;
  • дополнительная нагрузка на шлюз;
  • риск выдать доступ к сети вместо доступа к конкретному ресурсу;
  • отдельная эксплуатация PKI, ключей, RADIUS и отзыва пользователей.

Где можно больно ошибиться

Считать VPN признаком безопасного устройства. Если ноутбук заражён, туннель честно перенесёт его трафик внутрь. VPN подтверждает ключ или учётную запись, но сам по себе не проверяет состояние ОС.

Один общий ключ. Общий WireGuard-конфиг или PSK для всех подрядчиков невозможно нормально отозвать у одного человека и трудно расследовать.

Слишком широкие маршруты. Даже если firewall потом режет трафик, пользователю лучше не анонсировать лишние сети без причины.

Нет MFA или второго барьера. Для постоянного административного туннеля одного пароля мало. Сертификат устройства плюс пользовательская авторизация выглядит значительно спокойнее.

Забытые профили. Человек ушёл, договор закончился, а сертификат и RADIUS-учётка продолжают жить.

Когда выбирать VPN

VPN стоит брать, когда человеку действительно нужна L3-связность: много сервисов, толстые клиенты, приватный DNS, постоянная работа, управляемое устройство. Для одного сайта логичнее reverse proxy. Для разового RDP — web-bastion. Для «открыть несколько портов на час с текущего адреса» временный allow-list может быть проще.

То есть мы VPN не отменяем. Просто перестаём использовать его как отвёртку, молоток и разводной ключ одновременно.

Ранее в цикле

Документация и источники

#network

Цикл «Не светим лишнего». Выпуск 2.

Firewall часто воспринимают как стену с кучей дырок-портов. На практике полезнее думать о нём как о списке решений: этот пакет относится к такой-то сессии, пришёл отсюда, идёт туда, значит его пропускаем или выбрасываем.

Начальная позиция для защищаемого контура простая: если разрешающего правила нет, соединение не должно пройти. Это и есть default deny. Не «мы запретили несколько плохих адресов», а «мы разрешили только то, что понимаем».

Сначала не перепутаем input и forward

На MikroTik и большинстве других маршрутизаторов есть принципиальная разница.

Input — трафик к самому маршрутизатору. WinBox, SSH RouterOS, API, DNS на роутере, ICMP к его адресу. Если мы защищаем управление MikroTik, работаем здесь.

Forward — трафик, проходящий через маршрутизатор. Например, внешний клиент идёт через DNAT на RDP-сервер или внутреннюю веб-панель. Пакет адресован не самому MikroTik, он только проходит через него.

Типовая ошибка выглядит так: администратор добавляет красивое правило в input, проверяет, что WinBox закрыт, и считает, что опубликованный сервер тоже защищён. А DNAT спокойно продолжает работать через forward.

NAT не является разрешением сам по себе

DNAT отвечает на вопрос «куда переписать адрес назначения». Firewall отвечает на вопрос «пустить ли пакет дальше». Лучше держать эту логику раздельно.

Допустим, внешний 203.0.113.10:10443 переводится на внутренний 10.20.30.15:443. Это ещё не значит, что доступ должен быть разрешён всем. В forward можно потребовать одновременно:

  • вход с WAN;
  • состояние нового соединения;
  • нужный внутренний адрес и порт после DNAT;
  • наличие источника в группе access-monitoring;
  • логирование начала соединения.

Тогда NAT остаётся постоянным, но без членства в разрешённой группе ресурс выглядит закрытым.

Группы лучше отдельных исключений

Если ресурсов больше двух, не стоит строить правила вокруг фамилий и разовых адресов. Удобнее завести сущности по смыслу:

  • назначения protected-monitoring, protected-dev, protected-cctv;
  • источники access-admin, access-developer, access-contractor;
  • отдельные цепочки или правила для HTTP, SSH, RDP и управления.

Тогда пользователь или портал добавляет адрес в готовую группу. Он не получает возможность придумать себе произвольный destination. Это сильно снижает шанс, что ошибка административной панели превратится в «открыли человеку всю серверную сеть».

Плюсы обычного firewall

  • работает с любыми IP-протоколами и не зависит от приложения;
  • почти везде уже есть;
  • поведение можно увидеть счётчиками и логами;
  • хорошо масштабируется через группы адресов;
  • не требует установки чего-либо на клиент.

Минусы

Главный минус — firewall обычно не знает человека. Он знает IP-адрес, иногда интерфейс, VLAN, сертификат туннеля или метку соединения. Если два пользователя выходят через один NAT, для обычного L3/L4-фильтра они выглядят одинаково.

Вторая проблема — правила статичны, пока кто-то или что-то их не изменит. Человеческие исключения имеют свойство оставаться навсегда.

Где можно больно ошибиться

Порядок правил. Firewall идёт сверху вниз. Широкий accept раньше точного drop делает точный drop декоративным.

Established, related. Состояние соединений удобно: не приходится заново проверять каждый ответный пакет. Но если правило accept established,related стоит выше проверки актуального access-list, уже открытый SSH или RDP может продолжить работу после удаления адреса из списка.

FastTrack. Он ускоряет обработку established-соединений, пропуская часть обычного пути firewall. Для трафика, который должен отключаться немедленно при отзыве разрешения, FastTrack нужно либо обходить, либо продумывать очистку connection tracking.

IPv6. Можно идеально закрыть IPv4 и оставить тот же сервер доступным по глобальному IPv6. Проверяем оба стека или сознательно отключаем неиспользуемый.

Управление самим маршрутизатором. REST API, WinBox и SSH не должны торчать в Интернет просто потому, что «там сложный пароль». Управление лучше вынести в отдельный адрес/VRF/VLAN и ограничить источники.

Слишком широкая группа назначения. Открывать /16, потому что нужный сервер находится где-то внутри, — плохая экономия строк конфигурации.

Когда этого достаточно

Обычный firewall отлично решает задачу, если источники стабильны и хорошо известны: офисы, площадки, внешние сервисы, собственный VPN-шлюз. Для людей с динамическими адресами ему нужен ещё один слой: временный список, портал, knocking или другая система, которая будет решать, кого и на сколько добавлять.

Ранее в цикле

Документация и источники

#network #mikrotik

Цикл «Не светим лишнего». Выпуск 2.

Firewall часто воспринимают как стену с кучей дырок-портов. На практике полезнее думать о нём как о списке решений: этот пакет относится к такой-то сессии, пришёл отсюда, идёт туда, значит его пропускаем или выбрасываем.

Начальная позиция для защищаемого контура простая: если разрешающего правила нет, соединение не должно пройти. Это и есть default deny. Не «мы запретили несколько плохих адресов», а «мы разрешили только то, что понимаем».

Сначала не перепутаем input и forward

На MikroTik и большинстве других маршрутизаторов есть принципиальная разница.

Input — трафик к самому маршрутизатору. WinBox, SSH RouterOS, API, DNS на роутере, ICMP к его адресу. Если мы защищаем управление MikroTik, работаем здесь.

Forward — трафик, проходящий через маршрутизатор. Например, внешний клиент идёт через DNAT на RDP-сервер или внутреннюю веб-панель. Пакет адресован не самому MikroTik, он только проходит через него.

Типовая ошибка выглядит так: администратор добавляет красивое правило в input, проверяет, что WinBox закрыт, и считает, что опубликованный сервер тоже защищён. А DNAT спокойно продолжает работать через forward.

NAT не является разрешением сам по себе

DNAT отвечает на вопрос «куда переписать адрес назначения». Firewall отвечает на вопрос «пустить ли пакет дальше». Лучше держать эту логику раздельно.

Допустим, внешний 203.0.113.10:10443 переводится на внутренний 10.20.30.15:443. Это ещё не значит, что доступ должен быть разрешён всем. В forward можно потребовать одновременно:

  • вход с WAN;
  • состояние нового соединения;
  • нужный внутренний адрес и порт после DNAT;
  • наличие источника в группе access-monitoring;
  • логирование начала соединения.

Тогда NAT остаётся постоянным, но без членства в разрешённой группе ресурс выглядит закрытым.

Группы лучше отдельных исключений

Если ресурсов больше двух, не стоит строить правила вокруг фамилий и разовых адресов. Удобнее завести сущности по смыслу:

  • назначения protected-monitoring, protected-dev, protected-cctv;
  • источники access-admin, access-developer, access-contractor;
  • отдельные цепочки или правила для HTTP, SSH, RDP и управления.

Тогда пользователь или портал добавляет адрес в готовую группу. Он не получает возможность придумать себе произвольный destination. Это сильно снижает шанс, что ошибка административной панели превратится в «открыли человеку всю серверную сеть».

Плюсы обычного firewall

  • работает с любыми IP-протоколами и не зависит от приложения;
  • почти везде уже есть;
  • поведение можно увидеть счётчиками и логами;
  • хорошо масштабируется через группы адресов;
  • не требует установки чего-либо на клиент.

Минусы

Главный минус — firewall обычно не знает человека. Он знает IP-адрес, иногда интерфейс, VLAN, сертификат туннеля или метку соединения. Если два пользователя выходят через один NAT, для обычного L3/L4-фильтра они выглядят одинаково.

Вторая проблема — правила статичны, пока кто-то или что-то их не изменит. Человеческие исключения имеют свойство оставаться навсегда.

Где можно больно ошибиться

Порядок правил. Firewall идёт сверху вниз. Широкий accept раньше точного drop делает точный drop декоративным.

Established, related. Состояние соединений удобно: не приходится заново проверять каждый ответный пакет. Но если правило accept established,related стоит выше проверки актуального access-list, уже открытый SSH или RDP может продолжить работу после удаления адреса из списка.

FastTrack. Он ускоряет обработку established-соединений, пропуская часть обычного пути firewall. Для трафика, который должен отключаться немедленно при отзыве разрешения, FastTrack нужно либо обходить, либо продумывать очистку connection tracking.

IPv6. Можно идеально закрыть IPv4 и оставить тот же сервер доступным по глобальному IPv6. Проверяем оба стека или сознательно отключаем неиспользуемый.

Управление самим маршрутизатором. REST API, WinBox и SSH не должны торчать в Интернет просто потому, что «там сложный пароль». Управление лучше вынести в отдельный адрес/VRF/VLAN и ограничить источники.

Слишком широкая группа назначения. Открывать /16, потому что нужный сервер находится где-то внутри, — плохая экономия строк конфигурации.

Когда этого достаточно

Обычный firewall отлично решает задачу, если источники стабильны и хорошо известны: офисы, площадки, внешние сервисы, собственный VPN-шлюз. Для людей с динамическими адресами ему нужен ещё один слой: временный список, портал, knocking или другая система, которая будет решать, кого и на сколько добавлять.

Ранее в цикле

Документация и источники

#network

Реальные SMS от GSM-розетки: пропадание и восстановление питания, контроль температуры

Вот, собственно, и весь интерфейс мониторинга: питание пропало, питание вернулось, температура вышла за диапазон.

Иногда от системы мониторинга требуется всего три вещи: сообщить, что пропало 220 В, показать температуру и по команде перезагрузить оборудование. Без сервера мониторинга, VPN, облака и маленького Kubernetes-кластера для наблюдения за шкафом с роутером.

Для таких задач мы много лет используем GSM-розетки «Телеметрика» T4. Несколько экземпляров, купленных около десяти лет назад, работают до сих пор.

GSM-розетка Телеметрика T4

Та самая T4: SIM-карта, SMS и никаких облаков.

Внутрь устанавливается обычная SIM-карта. При пропадании питания розетка отправляет классическое SMS «Нет 220 В», а после восстановления — сообщает, что напряжение вернулось. Встроенного накопителя энергии хватает, чтобы успеть отправить сообщение уже после отключения сети. По актуальной инструкции исчезновение питания определяется примерно за 5 секунд, а рассылка уведомлений занимает от 30 секунд до 3 минут.

Главное достоинство — устройству не нужен интернет. Неважно, умер ли роутер, завис ли модем, закончился ли сертификат или сломалось очередное приложение. Пока розетка регистрируется в GSM-сети и проходят SMS, она остаётся на связи.

В 2026 году это стало особенно заметно. Мобильную передачу данных всё чаще временно отключают или оставляют доступ только к сервисам из белого списка. Облачное приложение, бот, webhook или сервер мониторинга в такой момент могут оказаться недоступны, хотя базовые услуги сотовой сети ещё работают. SMS — отдельный и более простой канал. Гарантированным его тоже считать нельзя: в отдельных случаях ограничения затрагивают и сообщения. Но зависимостей у него заметно меньше.

Есть и более приземлённая проблема. Когда на удалённом объекте пропадает электричество, интернет иногда падает раньше, чем система успевает передать аварию. Например, провайдер сэкономил на резервном питании промежуточного шкафа — и вместе с электричеством исчез канал. Красивый мониторинг покажет лишь «узел недоступен», но уже не расскажет почему.

Чтобы сделать IP-мониторинг действительно автономным, нужно бесперебоить модем, роутер, коммутаторы и собственный сервер мониторинга, а затем надеяться, что провайдер резервирует питание на всей трассе. Это батареи, обслуживание, деньги и дополнительные точки отказа. GSM-розетка обходит локальный интернет целиком: заметила исчезновение 220 В, взяла последние секунды энергии из встроенного накопителя и отправила SMS через ближайшую работающую базовую станцию.

Бонусом в комплекте есть температурный датчик. Можно запросить текущую температуру или получать тревогу при выходе за заданный диапазон.

Телеметрика T4 и датчик температуры

Бонусный канал мониторинга — температура в шкафу или помещении. А ещё розетка умеет:

  • включать и отключать нагрузку по SMS или звонку;
  • делать жёсткую перезагрузку роутера, контроллера или другого оборудования;
  • работать по таймеру и расписанию;
  • сообщать о пропадании и восстановлении питания;
  • использовать белый список доверенных телефонных номеров.

Управление закрыто белым списком: у актуальной серии M в памяти сохраняется один главный и до четырёх дополнительных номеров. Остальные абоненты управлять розеткой не могут.

Если покупать такую штуку сейчас, стоит посмотреть и на более современную T40M. Принцип тот же — GSM и SMS без зависимости от мобильного интернета, — но одна ведущая T40M может управлять ещё четырьмя ведомыми розетками T20 по радиоканалу 433 МГц. Заявленная дальность — до 30 метров в прямой видимости. Удобно, когда в одном техническом помещении несколько устройств, а платить за отдельную SIM-карту в каждой розетке не хочется.

Мы использовали такие розетки на труднодоступных объектах: как дешёвый монитор наличия питания, датчик температуры и средство удалённой перезагрузки. Можно предусмотреть и дистанционное отключение оборудования, если его требуется срочно обесточить. Но это всё же дополнительный канал управления, а не гарантированная аварийная защита: SMS может задержаться, а сотовая сеть — исчезнуть именно в самый интересный момент.

Из практических мелочей: нужен устойчивый сигнал 2G/GSM, тариф с SMS, отключённый PIN-код и положительный баланс. А мощную, индуктивную или действительно ответственную нагрузку лучше коммутировать через подходящий контактор. Производитель заявляет до 16 А и 3,5 кВт, но позиционирует устройство для дома и офиса, а не для промышленной автоматики или систем жизнеобеспечения.

Не универсальный комбайн. Просто старая добрая коробочка, которая пишет: «свет пропал» — даже когда вместе со светом пропал весь ваш умный дом.

Подробнее: Телеметрика T4 · Телеметрика T40M

Контекст по ограничениям связи в 2026 году: позиция Минцифры о белых списках при ограничении мобильного интернета · пример ограничений, затронувших мобильный интернет и SMS