FifthAce/routerforge
1
0
Fork 0
Code Issues Pull requests Projects Releases 58 Packages Wiki Activity Actions 3
58 releases 58 tags
  • routerforge-v0.13.0 29b7b849d2

    RouterForge 0.13.0 Stable

    FifthAce released this 2026-10-16 21:16:51 +03:00 | 69 commits to main since this release

    RouterForge 0.13.0 Stable

    Есть одна удивительная особенность разработки программного обеспечения. Сначала разработчик составляет план. Продумывает архитектуру. Распределяет задачи. Определяет сроки. Представляет, каким прекрасным получится следующий релиз. А потом приходит пользователь и говорит: «Очень замечательно было бы туда добавить…»

    И всё. План можно выкидывать нахуй.

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

    Человеку нужна кнопка. Желательно работающая. И желательно сегодня.

    Добро пожаловать в RouterForge 0.13.0.

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

    Ранее в этом дурдоме

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

    Мы даже написали большой патчноут. С шутками. С объяснениями. С рассказами о том, насколько всё стало лучше.

    А потом выпустили 0.12.1. Потому что пользователи, эти бессердечные ублюдки, начали пользоваться программой.

    Они нажимали кнопки. Пробовали обновлять компоненты. Проверяли настройки. И почему-то ожидали, что написанное в патчноуте соответствует действительности. Невероятная наглость.

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

    В приличной компании всё это назвали бы: «Результатами расширенного пользовательского тестирования».

    Мы предпочли более короткое определение: «Пользователи опять нашли, где мы насрали».

    В конце патчноута 0.12.1 мы написали:

    «Если после релиза вам кажется, что всё работает идеально — не переживайте. Пользователи скоро проверят».

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

    А мы совершили стратегическую ошибку. Начали их слушать.

    Как один пользователь незаметно разработал нам половину релиза

    В какой-то момент в обсуждении RouterForge появилось довольно скромное пожелание. Примерно следующее:

    «Очень замечательно было бы туда добавить:

    1. Port knocking — веб-морду для настройки портов и доступ к таблице прошедших авторизацию.
    2. CrowdSec — настройку и статистику.

    Надеюсь на понимание».

    Надеется он на понимание. Какой вежливый человек. Даже как-то неловко.

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

    Ни Port Access Manager, ни CrowdSec Manager изначально не были центральными задачами нашего следующего релиза.

    Особенно CrowdSec. Нам он, по большому счёту, не требовался. Мы не сидели вечерами с мыслью: «Господи, как же не хватает ещё одного компонента безопасности на роутере».

    У нас и без того хватало работы. NFQWS2. Списки. Диагностика. Автоподбор. Конфигурации. Резервные копии. Управление службами.

    Но пользователь попросил. И предложение оказалось разумным. Поэтому мы решили: «Ладно, добавим».

    В этот момент где-то в глубине репозитория тихо заплакал наш план разработки.

    Port Access Manager. Просили один замок, получили три.

    Начнём с Port Knocking. Пользователь попросил довольно конкретную вещь. Удобный веб-интерфейс для настройки портов. И возможность видеть IP-адреса, которым разрешён доступ.

    Вполне нормальная задача. Можно было взять один механизм. Сделать настройки. Добавить таблицу. Проверить. Выпустить. Пойти заниматься остальными задачами.

    Но мы же разработчики. У нас особенное заболевание. Оно называется: «А что, если сделать ещё вот это?»

    Поэтому вместо одного способа защиты портов мы решили предусмотреть сразу три.

    • knockd — классический Port Knocking.
    • fwknopd / SPA — авторизация специальным зашифрованным сообщением.
    • iptables recent / odin — защита проброшенных портов средствами ядра Linux.

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

    Спасибо за предложение. Мы слегка увлеклись.

    Port Knocking. Тук-тук, кто там?

    Идея Port Knocking проста. Чтобы получить доступ к защищённому сервису, клиент сначала подключается к определённым TCP-портам в правильной последовательности.

    Например: 7777 → 8888 → 6666

    Если последовательность правильная и выполнена вовремя, система может временно разрешить доступ. Если неправильная — нет.

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

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

    В RouterForge появились средства настройки последовательности, временных окон, защищаемых сервисов и управления установленным knockd. Предусмотрены предварительный просмотр, сохранение настроек и проверки безопасности.

    Таблица прошедших авторизацию

    Да, про вторую часть пожелания мы тоже не забыли. Для управляемого режима knockd предусмотрен просмотр авторизованных IP-адресов, полученных из реальных записей механизма xt_recent ядра Linux.

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

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

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

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

    SPA. Потому что трёх стуков нам показалось мало.

    После классического Port Knocking мы решили добавить поддержку fwknopd. Этот подход использует Single Packet Authorization.

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

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

    Потому что защищать сервис секретным ключом, а затем показывать этот ключ каждому посетителю страницы состояния — несколько спорное инженерное решение.

    Хотя некоторые крупные компании наверняка назвали бы это: «Повышением прозрачности механизмов информационной безопасности».

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

    Это примерно как нарисовать на стене сейф. Выглядит убедительно. Но деньги лучше туда не класть.

    Odin. Потому что иногда отдельный демон — это уже перебор.

    Третьим механизмом стала защита через iptables recent, основанная на решении odin из сообщества Keenetic.

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

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

    RouterForge получил средства настройки odin, интеграцию с правилами Keenetic NDM и управление собственными цепочками firewall.

    Добавлены:

    • защита нескольких TCP-портов;
    • доверенные IPv4-адреса и подсети;
    • настройка последовательности knocking;
    • временные ограничения доступа;
    • проверки существующих правил;
    • механизмы отката неподтверждённых изменений;
    • watchdog.

    Последний пункт заслуживает отдельного разговора.

    Watchdog. На случай, если администратор оказался талантливее системы защиты.

    Есть один гарантированный способ проверить квалификацию сетевого администратора. Предложить ему удалённо изменить firewall. На роутере. На котором он сейчас работает. Через единственное SSH-подключение.

    Некоторые люди в этот момент начинают думать. Некоторые создают резервный канал. Некоторые делают резервную копию. А некоторые сразу нажимают «Применить».

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

    Для odin предусмотрен независимый watchdog. Смысл простой: включение защиты должно происходить с возможностью автоматического отката, если пользователь не подтвердил успешность изменений.

    Для соответствующего режима используется защитное окно в 90 секунд.

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

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

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

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

    Безопасность есть. Только не там, где находится интернет.

    Итого: пользователь попросил Port Knocking. Мы сделали целый Port Access Manager. С тремя подходами, диагностикой, таблицей авторизованных IP, управлением сервисами, предварительными проверками и аварийным откатом.

    Если в следующем обсуждении кто-нибудь попросит кнопку включения Wi-Fi, мы уже немного боимся представить, чем это закончится.

    Скорее всего, собственным контроллером радиочастотной инфраструктуры.

    CrowdSec Manager. Модуль, которого мы не планировали.

    С CrowdSec история ещё прекраснее. Потому что если Port Knocking хотя бы можно было объяснить развитием сетевых инструментов RouterForge, то CrowdSec вообще не входил в наши первоначальные планы.

    Нам нужно было доделать NFQWS Manager. Разобраться с управлением конфигурациями. Улучшить стабильность. Подготовить следующий релиз.

    И тут появляется пользователь. «А добавьте CrowdSec. Настройку и статистику».

    Вежливо. Спокойно. Без угроз.

    Вот что самое опасное. Когда пользователь ругается, разработчику хотя бы есть за что зацепиться. Можно начать спорить. Объяснять архитектуру. Рассказывать про ограничения платформы.

    А когда человек спокойно просит полезную функцию, все эти защитные механизмы становятся бесполезными. Остаётся только сказать: «Ладно, сделаем».

    И вот у нас CrowdSec Manager.

    Спасибо, дорогие пользователи. Мы вас очень ценим. Но когда-нибудь вы всё-таки доведёте нас до психиатра.

    Интернет полон мудаков. Теперь хотя бы есть статистика.

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

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

    CrowdSec предназначен для анализа подозрительной активности и формирования решений о блокировке. В RouterForge появился интерфейс управления CrowdSec Firewall Bouncer на Keenetic.

    В поддерживаемой схеме сам CrowdSec LAPI может работать отдельно, например на Windows, а роутер применяет блокировки через Firewall Bouncer.

    Мы не стали делать собственный CrowdSec. Собственный анализатор угроз. Собственную базу подозрительных адресов. Собственный протокол. Собственную систему международного обмена сведениями о киберпреступниках.

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

    Прогресс.

    Зелёная галочка больше не считается доказательством.

    Есть замечательная особенность системного мониторинга. Если процесс существует, интерфейс обычно считает, что всё работает.

    Процесс запущен? Да. Значит система защищена.

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

    CrowdSec Manager проверяет не только состояние процесса. Он анализирует наличие конфигурации, ipset, интеграцию с NDM и действующие цепочки firewall.

    Проверяется связка:

    FORWARD → CROWDSEC_CHAIN → ipset DROP

    Потому что работающий Bouncer без работающей блокировки — довольно странное достижение.

    Человек платит за охрану. Охранник приходит. Сидит. Пьёт кофе. Воры выносят оборудование.

    Охранник сообщает: «Я свою работу выполнил. Я же был запущен».

    Теперь RouterForge старается проверять не только присутствие охранника, но и состояние двери.

    Установка, настройки и статистика

    Для поддерживаемой платформы добавлена управляемая установка Firewall Bouncer. Используется конкретный официальный выпуск с проверкой SHA256.

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

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

    Предусмотрена работа с собственным NDM hook, чтобы учитывать перестройку правил firewall самим Keenetic.

    Статистика берётся из фактических доступных источников. Если определённая сборка Bouncer не показывает корректное количество адресов в отдельной метрике, RouterForge старается проверить реальные записи ipset.

    Потому что ноль в отчёте не всегда означает отсутствие проблемы. Иногда это означает отсутствие мозгов у системы отчётности.

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

    И важный нюанс: CrowdSec Manager не превращается в полноценную замену всей серверной инфраструктуры CrowdSec. Он управляет той частью, которая отвечает за защиту роутера.

    Ровно то, о чём просили.

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

    NFQWS Manager. А вот этим мы действительно собирались заниматься.

    После истории с Port Access и CrowdSec может возникнуть закономерный вопрос: «А что вы вообще планировали сделать в этом релизе?»

    Прекрасный вопрос. Спасибо, что спросили.

    Мы планировали серьёзно доработать NFQWS Manager. И, несмотря на все побочные приключения, действительно это сделали.

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

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

    Почему сайт не открывается? Потому что компьютерные сети ненавидят людей.

    Есть особая категория технических проблем. Интернет работает. DNS отвечает. Другие сайты открываются. А конкретный сайт — нет.

    И начинается традиционный ритуал. Пользователь идёт на форум. Находит стратегию из двадцати параметров. Копирует. Вставляет. Не работает. Находит другую. Вставляет. Перестаёт работать половина интернета.

    Находит третью. Автор комментария утверждает:

    «У меня всё отлично».

    Комментарий написан в прошлом году. Провайдер другой. Роутер другой. Версия nfqws2 другая. Но надежда есть.

    В 0.13.0 NFQWS Manager получил расширенную диагностику сайтов. Теперь система старается не просто показать, что соединение не удалось, а собрать контекст: сетевые симптомы, соответствующие профили, существующие списки и возможные причины неправильной обработки трафика.

    Потому что универсальный совет «попробуй другую стратегию» — это не диагностика. Это гадание на сетевых пакетах.

    Автоподбор стал меньше верить в чудеса.

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

    Стратегии проверяются в изолированных NFQUEUE-тестах. Результаты предыдущих проверок помогают определить порядок, но не заменяют реальные испытания.

    Историческая запись «WORKING» не означает, что стратегия автоматически работает сейчас.

    Потому что: «В прошлом месяце открывалось». — это не технический аргумент. Это воспоминание.

    Примерно как: «Когда-то я мог выпить бутылку водки и утром пойти на работу».

    Попробуйте сейчас. Результаты могут отличаться.

    Один раз открылось — ещё не победа.

    Нестабильные сети обладают замечательной способностью иногда делать вид, что проблема исчезла.

    Сайт открылся. Один раз. На несколько секунд. После чего снова перестал работать.

    Многие программы считают это успехом. Рисуют зелёную галочку. Предлагают сохранить настройки. А дальше пользователь самостоятельно знакомится с последствиями.

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

    Также учитываются ограничения по памяти и числу параллельных рабочих процессов.

    Потому что идея запускать десятки тяжёлых тестов на роутере с ограниченной оперативной памятью — это не инженерия. Это реалити-шоу.

    «Последний выживший процесс». Главный приз — право не быть убитым OOM Killer.

    Стратегии сообщества по AS провайдера

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

    При желании RouterForge может определить ASN через RIPEstat или использовать номер, введённый пользователем. Затем получить до восьми подходящих кандидатов из базы сообщества и проверить их обычным механизмом NFQUEUE.

    Функция выключена по умолчанию. Внешние запросы выполняются только при её включении. Полученные данные фильтруются и проверяются. Ничего не применяется автоматически.

    Потому что GitHub — это замечательная площадка. Там есть выдающиеся проекты. И там же лежат программы, у которых в README написано: «BEST UNIVERSAL BYPASS 100% WORKING».

    Последний коммит — восемнадцать месяцев назад. Открытых issues — семьдесят три. Автор исчез. Но звёздочек много.

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

    Мы решили не строить работу RouterForge на астрологии.

    Уточнение стратегий и проверка результата

    Появились дополнительные механизмы исследования перспективных кандидатов. Если стратегия даёт частичный прогресс, система может провести ограниченные проверки вариантов параметров.

    Но отсутствие достоверного измерения не объявляется доказательством неработоспособности. Ошибка тестовой инфраструктуры тоже не должна становиться диагнозом стратегии.

    Если у врача сломался градусник, это не значит, что у пациента температура минус сорок.

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

    Smart Apply. Перезапустить службу недостаточно.

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

    Если служба запустилась — объявить успех. Если после этого интернет не работает — обвинить провайдера.

    В 0.13.0 применение стратегий стало существенно осторожнее. RouterForge проверяет ожидаемое состояние конфигурации и зависимых файлов. Создаёт резервные копии. Сверяет контрольные суммы. Выполняет предусмотренные проверки после применения.

    И там, где это поддерживается, проверяет доступность целевого ресурса через реальное HTTPS-соединение. Если результат не подтверждается, запускается механизм отката.

    Потому что успешный перезапуск nfqws2 не означает успешную работу сайта.

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

    Двигатель работает? Работает. Задача выполнена.

    Доехать нельзя. Но это уже другая заявка.

    Исправили один сайт — не ломаем остальные.

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

    Система может использовать свежие результаты прошлых измерений, но перед изменением повторно проверяет доступность контрольных сайтов. После применения сравнивает результат.

    Если подтверждённый контрольный ресурс перестал открываться, предусмотрен откат текущей операции.

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

    В корпоративном мире подобное иногда называется: «Успешное перераспределение технических рисков».

    Списки NFQWS. Потому что пользовательские файлы тоже хотят жить.

    Отдельно доработано управление списками. Эта часть разработки оказалась удивительно трудоёмкой.

    Казалось бы. Есть файл. Есть строки. Добавляешь строки. Удаляешь строки. Сохраняешь. Что может пойти не так?

    Ха. Ха-ха. ХА-ХА-ХА, БЛЯДЬ.

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

    Кто-то изменил конфигурацию. Кто-то переименовал список. Кто-то удалил файл, на который ссылались ещё три профиля. Кто-то нажал «Сохранить» в старой вкладке и затёр свежие изменения.

    Обычный рабочий день.

    Теперь RouterForge гораздо внимательнее относится к таким ситуациям.

    Защита от перезаписи

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

    Потому что принцип: «Кто последним нажал кнопку, тот и победил». — замечательно подходит для многопользовательских игр.

    Но не для системных конфигураций.

    Создание и удаление

    Новые списки создаются с защитой от случайной перезаписи уже существующего файла.

    При удалении проверяются зависимости от активной и сохранённых конфигураций. Если список используется — операция блокируется.

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

    Особенно если в интерфейсе по-прежнему написано: «Все службы работают нормально».

    Переименование с обновлением ссылок

    Добавлены предварительный просмотр и управляемое переименование списков.

    RouterForge проверяет существующие зависимости, создаёт резервные копии, обновляет допустимые ссылки и контролирует состояние файлов.

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

    Это довольно важная деталь. Потому что при неудачном переименовании есть два варианта.

    Первый: «Операция завершилась ошибкой, часть файлов сохранили для восстановления».

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

    Второй вариант значительно эффектнее. Но мы всё-таки выбрали первый.

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

    Мы можем усложнить ошибке жизнь. Но не можем отменить законы физики.

    К огромному сожалению маркетологов.

    Конфигурация NFQWS2. Меньше гадания, больше проверки.

    Улучшена работа с родной конфигурацией nfqws2. Добавлены дополнительные проверки параметров, синтаксиса и зависимостей.

    Доработаны предварительный просмотр, взаимодействие с профилями, списками и Центром резервных копий.

    RouterForge продолжает управлять существующим nfqws2, а не заменяет его собственным альтернативным движком.

    Это важно. Потому что в какой-то момент разработки у нас возникло неприятное подозрение: если продолжать писать вспомогательные механизмы с такой скоростью, можно случайно создать ещё один nfqws2.

    Потом сделать интерфейс для него. Потом написать менеджер интерфейса. Потом обнаружить, что всё это хуже оригинала.

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

    Редкая победа здравого смысла.

    Управление журналами. Теперь можно выбирать, куда складывать доказательства.

    Логи — удивительная вещь. Пока система работает, они никому не нужны. Когда система перестаёт работать, оказывается, что именно они содержат единственное объяснение происходящего.

    И разумеется, в этот момент журнал либо уже удалён, либо записан в неизвестное место, либо занял всё доступное пространство.

    В 0.13.0 появилось управление хранением журналов RouterForge.

    Теперь можно выбирать:

    • оперативную память роутера;
    • накопитель Entware;
    • пользовательский допустимый путь.

    Добавлены настройки размера журнала и числа сохраняемых копий.

    Система проверяет расположение файлов и ограничивает потенциально опасные пути.

    Потому что записывать логи на внутреннюю flash-память до полного заполнения — это прекрасный способ диагностировать неисправность.

    Правда, к этому моменту неисправностью может стать уже сам роутер.

    Отдельно отметим: RouterForge управляет журналами собственных компонентов, а не начинает распоряжаться логами всего установленного стороннего программного обеспечения.

    Мы стараемся не путать управление своей программой с правом командовать всей файловой системой.

    Хотя соблазн, конечно, есть.

    Особенно когда у программы есть root.

    Интерфейс. Дизайнеры, пожалуйста, отойдите от скроллбаров.

    Современные веб-интерфейсы заслуживают отдельного разговора. Когда-то программы создавались для того, чтобы пользователь мог выполнять действия.

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

    Огромные карточки. Гигантские отступы. Пустое пространство. Семь вкладок. Три внутренние полосы прокрутки. Кнопка «Сохранить», расположенная где-то в районе соседнего административного округа.

    И обязательное утверждение: «Мы значительно улучшили пользовательский опыт».

    Чей, сука, опыт?

    Пользователь хотел поменять три параметра. Теперь он должен пройти полноценное исследование интерфейса.

    В 0.13.0 доработали оформление ряда модулей, компоновку элементов, отображение ошибок, статусов и служебной информации.

    Особое внимание уделили компактности и приведению новых модулей к общей теме RouterForge.

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

    Иногда огромная работа действительно выглядит как та же самая кнопка.

    Просто теперь после её нажатия происходит меньше хуйни.

    Это тоже результат. Хотя на красивый скриншот его положить труднее.

    Интеграции и Центр приложений

    Port Access Manager и CrowdSec Manager добавлены в экосистему RouterForge как отдельные официальные инструменты.

    Они используют общую модель интерфейса и управления модулями.

    Для поддерживаемой конфигурации CrowdSec предусмотрен сценарий установки Firewall Bouncer, если он отсутствует.

    Продолжается развитие возможностей уже существующего Центра приложений.

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

    Потому что именно так начинаются большие корпоративные системы.

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

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

    Мы очень стараемся не повторять этот путь.

    Иногда даже успешно.

    Безопасность. Теперь слово PASS должно означать что-нибудь конкретное.

    Разработка 0.13.0 сопровождалась большим количеством тестов. Автоматических. Изолированных. Проверок файлов. Проверок конфликтов. Проверок операций. Проверок отката. Проверок на настоящем ARM64-роутере.

    И всё это прекрасно.

    Но есть одна маленькая проблема.

    Автоматический тест не является доказательством того, что всё работает на любой возможной конфигурации Keenetic.

    У настоящего роутера есть маршруты. Есть правила NDM. Есть сторонние сервисы. Есть другие модули. Есть свои особенности ядра.

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

    Поэтому мы стараемся различать:

    Код прошёл тесты.

    Функция проверена на конкретном оборудовании.

    Функция гарантированно работает на любом устройстве.

    Последнего обещать не будем. Даже если маркетинговый отдел очень попросит.

    Особенно если попросит.

    NFQWS2 Manager прошёл отдельную проверку на рабочем тестовом оборудовании.

    Часть новых механизмов Port Access имеет дополнительные ограничения по аппаратной приёмке, и наличие интерфейса knockd или fwknopd не следует путать с гарантированной работоспособностью любой схемы защиты.

    Работу CrowdSec тоже нужно оценивать по фактическим правилам и статистике, а не по наличию красивой карточки.

    Это несколько портит рекламную картину.

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

    Благодарности. И немного о том, кто вообще делает этот проект.

    Самое время вернуться к нашим пользователям. Потому что именно они заметно повлияли на содержание 0.13.0.

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

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

    Не маркетинговая рассылка. Не голосование за цвет кнопок. Не фокус-группа из людей, которые никогда не пользовались программой.

    А обычный разговор: «Слушайте, а вот это было бы удобно».

    И действительно. Было бы.

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

    И очередной повод задуматься о правильности жизненного выбора.

    Но именно из таких разговоров получаются полезные программы.

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

    Только не путайте нашу благодарность с обещанием реализовать абсолютно всё.

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

    Вежливо.

    С объяснением технических ограничений.

    А если серьёзно — благодарим авторов и сообщества проектов, на опыт которых опирается RouterForge: nfqws2, nfqws2-keenetic, nfqws2-ui, nfqws-menu, z2k, nfqws2-keenetic-strategy-selector, nfqws2-strategies, DPI Detector, CrowdSec, keenetic-crowdsec-bouncer и решения odin для Keenetic.

    RouterForge не заменяет эти проекты и не присваивает себе их работу.

    Мы лишь стараемся сделать использование соответствующих инструментов удобнее.

    И иногда добавляем больше функций, чем у нас просили.

    Чисто по медицинским причинам.

    Перед обновлением

    0.13.0 — крупный функциональный выпуск.

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

    Не стоит впервые экспериментировать с Port Knocking на единственном SSH-порту, если восстановить доступ можно только поездкой на объект.

    Для CrowdSec требуется корректно настроенная инфраструктура LAPI и совместимый Firewall Bouncer.

    NFQWS Manager продолжает работать с существующей установкой nfqws2.

    При использовании новых средств защиты учитывайте особенности firewall конкретного Keenetic и существующие разрешающие правила.

    Сохраняйте резервные копии важных конфигураций.

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

    Это оптимистическое предположение, записанное на накопитель.

    И вообще, если в работе с сетевой инфраструктурой есть одно правило, которое стоит запомнить, то оно звучит так:

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

    Это не так эффектно, как обещание безопасности нового поколения.

    Зато иногда позволяет не ехать ночью к роутеру.

    Что в итоге

    0.12.0 был релизом большого Центра приложений.

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

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

    Просили Port Knocking. Получили Port Access Manager с тремя механизмами защиты.

    Просили CrowdSec с настройками и статистикой. Получили отдельный CrowdSec Manager с установкой Bouncer, диагностикой, состоянием firewall и метриками.

    И параллельно мы всё-таки сумели выполнить собственный план по NFQWS Manager.

    Переработали автоподбор стратегий. Расширили диагностику. Усилили контроль применения изменений. Добавили проверку регрессий. Улучшили работу со списками и конфигурациями. Добавили управление журналами. Доработали интерфейсы. Усилили безопасность файловых операций.

    И потратили огромное количество времени на вещи, которые пользователи никогда не заметят.

    Проверки SHA256. Конфликты изменений. Резервные копии. Откат. Проверку реальных цепочек. Сохранение чужих файлов. Ограничение опасных операций.

    Скука смертная.

    На презентации всё это выглядело бы ужасно.

    Гораздо лучше было бы написать: ROUTERFORGE AI SECURITY NEXT GENERATION ULTRA PRO MAX.

    Добавить анимированный щит. Нарисовать график безопасности, который постоянно растёт. Поставить большую кнопку: «ОПТИМИЗИРОВАТЬ ВСЁ».

    Нажимаешь. Кнопка мигает. Появляется сообщение:

    «Ваша сеть стала безопаснее на 347%».

    Интернет перестаёт работать. Но ведь это логично.

    Чем меньше подключений, тем меньше угроз.

    Абсолютно защищённый роутер — это роутер, отключённый от сети. Абсолютно защищённый компьютер — выключенный компьютер. Абсолютно защищённая инфраструктура — инфраструктура, которой никто не пользуется.

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

    Ноль атак. Ноль инцидентов. Ноль пользователей.

    СТОПРОЦЕНТНАЯ ЭФФЕКТИВНОСТЬ.

    К счастью, мы пока выбрали другой путь.

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

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

    Хотя, судя по предыдущим релизам, последнее пока получается не всегда.

    RouterForge 0.13.0 Stable

    Больше возможностей. Больше проверок. Меньше веры в чудеса.

    В 0.12.1 мы поблагодарили пользователей за найденные ошибки. В 0.13.0 благодарим ещё и за новые идеи.

    А разработчикам других проектов хотим дать один очень полезный совет.

    Если пользователь пишет:

    «Очень замечательно было бы добавить…»

    — никогда не отвечайте сразу.

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

    А потом всё равно скажите: «Да хуй с ним, сделаем».

    Потому что именно так и развивается программное обеспечение.

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

    А потом пользователь снова пишет: «Очень замечательно было бы туда добавить…»

    И всё начинается сначала.

    RouterForge 0.13.0.

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

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

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

    P.S. Дорогие пользователи, спасибо за ваши предложения.

    Следующий раз, когда будете писать «можно добавить небольшую функцию», пожалуйста, помните: у разработчиков слово «небольшую» имеет совершенно другое значение.

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

    Downloads