Мне надоело постоянно переключать интернет и VPN. В итоге я написал NetRuleRouter
Хотел сделать небольшую программу, которая сама выбирает нужное сетевое подключение для сайтов и приложений. Спустя семь месяцев получился open-source-проект с поддержкой Windows и Linux. Рассказываю, зачем он нужен, что уже работает и почему это пока альфа.
Однажды, когда я отдыхал во Вьетнаме, один из российских сайтов настойчиво предлагал мне отключить VPN. Забавнее всего было то, что никакого VPN у меня в тот момент вообще не было. Сайту, видимо, просто не понравился иностранный IP-адрес.
С подобными ситуациями я периодически сталкивался и дома. Одни сайты и сервисы нормально работают через обычное интернет-подключение, другим нужен другой сетевой маршрут. При этом некоторые банки, маркетплейсы и отечественные приложения могут отказываться работать с определённых адресов или требовать отключить VPN.
Получается довольно странная ситуация: интернет есть, все необходимые подключения тоже есть, но для работы с разными сервисами приходится постоянно что-то переключать.
А если одновременно открыты браузер с десятками вкладок, среда разработки, мессенджеры, корпоративные приложения и идёт загрузка большого файла?
В какой-то момент мне надоело этим заниматься.
Я подумал: почему бы не сделать программу, которая позволит один раз указать, каким сайтам и приложениям какое подключение использовать, а дальше вообще об этом не вспоминать?
Так 1 апреля 2026 года началась разработка NetRuleRouter.
Сначала казалось, что всё будет просто
Идея выглядела незамысловато.
Есть компьютер с двумя сетевыми подключениями. Например, обычный интернет через Ethernet и дополнительное подключение через VPN. Или два разных провайдера.
Нужно, чтобы одни сайты работали через первое подключение, другие — через второе. Причём одновременно, без ручного переключения.
В идеале пользователь должен открыть программу, выбрать два подключения, добавить необходимые правила и забыть о существовании сетевых маршрутов.
Разумеется, я не первый человек, который задумался о подобной задаче.
В операционных системах давно существуют таблицы маршрутизации. Во многих VPN-клиентах реализован split tunneling, позволяющий направлять через туннель только часть трафика. Есть Proxifier, sing-box, mihomo и другие инструменты для управления соединениями.
Но у каждого подхода свои особенности.
Где-то правила привязаны к определённому VPN-клиенту. Где-то нужно разбираться в конфигурационных файлах, прокси-серверах и сетевых протоколах. Где-то можно разделить приложения, но неудобно управлять отдельными сайтами внутри одного браузера.
А мне хотелось другого: не заменять существующие подключения и VPN-программы, а научиться удобно управлять тем, что уже установлено на компьютере.
Причём так, чтобы этим мог пользоваться не только системный администратор.
Я сам работаю с IT-инфраструктурой, и разобраться в маршрутах вручную для меня не проблема. Но совершенно не хотелось превращать обычную повседневную работу за компьютером в постоянное администрирование собственной сети.
Что в итоге делает NetRuleRouter
NetRuleRouter — это локальная программа для управления сетевыми маршрутами на компьютере.
У неё есть два основных понятия:
Primary — основное подключение. Например, домашний интернет через Ethernet или Wi-Fi.
Secondary — дополнительное подключение. Им может быть VPN, другой провайдер, мобильный интернет или отдельный сетевой адаптер.
Дальше пользователь указывает правила, по которым программа определяет, каким подключением пользоваться.
Представим обычный рабочий день.
Я открыл браузер, работаю с облачными сервисами и инструментами разработки. Параллельно нужно зайти в интернет-банк, проверить покупки на маркетплейсе, пообщаться по видеосвязи и скачать большой файл.
Без раздельной маршрутизации часть этих задач может конфликтовать с выбранным сетевым режимом.
С NetRuleRouter можно настроить так, чтобы банки, маркетплейсы, видеосвязь и большие загрузки использовали основной интернет, а выбранные облачные сервисы — дополнительное подключение.
И всё это одновременно.
Причём правила работают не только для отдельных приложений. Можно указать конкретный сайт, целую доменную зону, IP-адрес, подсеть или диапазон адресов.
Например, два сайта, открытых в одном браузере, могут использовать разные подключения. Для этого не нужно устанавливать два браузера или постоянно менять их настройки.
Это, пожалуй, самое главное отличие от того, как я изначально пытался решить проблему: маршрутизация должна определяться правилами пользователя, а не тем, какой сетевой режим сейчас включён для всего компьютера.
При этом NetRuleRouter не является VPN-сервисом. Он не предоставляет серверы, не создаёт собственный VPN-туннель и не заменяет установленное сетевое программное обеспечение.
Программа работает с подключениями, которые уже существуют.
Почему маленькая программа превратилась в большой проект
Первые версии появились достаточно быстро. Но практически сразу обнаружилось, что одной таблицы с адресами недостаточно.
Допустим, пользователь указал, что определённый сайт должен открываться через дополнительное подключение. Всё работает прекрасно — пока это подключение не исчезает.
Что дальше?
Можно автоматически отправить трафик через основной интернет. Но что, если пользователь как раз не хочет, чтобы конкретный сервис работал через другой IP-адрес?
Появилась задача защиты от непредусмотренного переключения маршрута.
Дальше выяснилось, что современные сайты часто используют десятки разных доменов и серверов. Сама страница открывается с одного адреса, авторизация происходит через второй, изображения загружаются с третьего, а API работает на четвёртом.
Добавить только домен сайта иногда недостаточно.
Пришлось разрабатывать инструменты, которые помогают увидеть реальные соединения, найти связанные адреса и предложить пользователю дополнить правила.
Потом появились пересечения.
Например, одно правило направляет всю доменную зону через основной интернет, другое — конкретный сайт через дополнительное подключение, а третье касается программы, которая этот сайт открывает.
Какой маршрут выбрать?
Для этого понадобилась система приоритетов и отдельный инструмент, показывающий пересечения правил.
А ещё некоторые VPN-клиенты создают несколько виртуальных сетевых адаптеров и при следующем подключении могут использовать уже другой интерфейс. Простая привязка к первому найденному адаптеру в таком случае перестаёт работать.
Пришлось добавлять распознавание подключений и механизм обновления привязки при смене активного интерфейса.
И это далеко не все нюансы.
В результате первоначальная идея «выбрать два подключения и добавить несколько сайтов» постепенно обросла довольно серьёзной внутренней логикой.
А как этим пользоваться?
Я стараюсь придерживаться принципа: если программа предназначена для обычного пользователя, она не должна требовать изучения сетевых технологий перед первым запуском.
Поэтому у NetRuleRouter есть графический интерфейс и мастер первоначальной настройки.
После установки программа предлагает запустить фоновую службу, выбрать стартовый набор правил, а затем назначить основное и дополнительное подключения.
Есть готовые наборы правил для разных стран, но можно начать с чистого листа или импортировать свои списки.
Далее пользователь добавляет правила и применяет настройки.
При необходимости их можно сохранить, перенести на другой компьютер, временно отключить или изменить.
Разумеется, здесь ещё есть над чем работать с точки зрения удобства интерфейса. Это первая альфа, и далеко не все сценарии одинаково хорошо проработаны.
Но основной принцип остаётся неизменным: пользователь должен понимать, куда направляется трафик, и иметь возможность самостоятельно управлять этим поведением.
А если что-то работает неправильно?
Это ещё один вопрос, который я довольно быстро начал себе задавать.
Предположим, пользователь добавил правило, но сайт не открывается. Почему?
Сетевой адрес изменился? Сайт использует дополнительные домены? Не работает выбранное подключение? Сработало более приоритетное правило? Или соединение блокирует сама операционная система?
Если программа просто показывает ошибку, разобраться будет трудно.
Поэтому появились диагностика и трассировка соединений.
Они позволяют посмотреть, какие программы устанавливают соединения, к каким адресам обращаются, какой маршрут используется и какие соединения были заблокированы.
Постепенно программа превратилась не только в инструмент маршрутизации, но и в средство, помогающее разобраться с сетевым поведением приложений.
Несколько месяцев реальной работы вместо одних тестов
Мне было важно не просто написать программу и выложить её исходники.
Первыми рабочими версиями NetRuleRouter я начал пользоваться ещё летом. Постепенно исправлял ошибки, добавлял новые возможности и наблюдал за тем, как программа ведёт себя в повседневной работе.
В августе я опубликовал предварительные исходники на GitHub для самостоятельной сборки.
Позже появилась статистика трафика. Она позволила оценить, как реально распределяются данные между двумя подключениями.
У меня сохранилась CSV-выгрузка за период с 1 августа по 30 октября 2026 года — 91 календарный день.
За это время программа учла около 1,66 ТБ трафика:
- 1,42 ТБ — основное подключение;
- 240 ГБ — дополнительное.
При расчёте я исключил счётчики виртуальных адаптеров, которые могли повторно учитывать одни и те же данные.
Особенно интересно распределение трафика.
Через основное подключение проходит значительно больше данных. Это вполне ожидаемо: большие загрузки, обновления, медиафайлы и многое другое я предпочитаю отправлять напрямую.
Дополнительное подключение используется для выбранных ресурсов, которым нужен именно этот маршрут.
Конечно, подобная статистика не доказывает отсутствие ошибок в программе. Это не тест производительности и не независимая проверка корректности каждого соединения.
Но для меня эти цифры важны по другой причине.
NetRuleRouter уже несколько месяцев используется не как демонстрационный проект, который запускают один раз ради красивого скриншота, а как рабочий инструмент на моём компьютере.
Именно повседневное использование позволило найти множество проблем, которые было бы сложно предусмотреть при первоначальном проектировании.
Почему сразу Windows и Linux?
Первоначально основной целью была Windows. Именно на ней я чаще всего сталкивался с необходимостью разделять трафик между разными подключениями.
Но довольно быстро стало понятно, что сама задача не ограничивается одной операционной системой.
На Linux существуют собственные механизмы маршрутизации и фильтрации трафика, поэтому захотелось сделать общую логику правил с отдельными платформенными реализациями.
В качестве основы я выбрал Rust. На нём построены движок правил и значительная часть внутренних компонентов.
Графический интерфейс сделан с использованием Qt 6, QML и C++.
Для Windows программа использует системные механизмы маршрутизации и Windows Filtering Platform. Для Linux — маршруты, nftables и systemd.
Кроме графического интерфейса появились два отдельных инструмента: консольный nrr-cli и терминальный nrr-tui.
Это позволяет управлять программой в том числе на Linux-системах, где графического окружения вообще нет.
Но здесь важно различать наличие сборок и реальную проверку на разных компьютерах.
Сейчас наиболее полно протестирована версия для Windows 10/11 x64. Также проверялась работа на Ubuntu 26.04, Astra Linux и РЕД ОС, хотя не везде доступен графический интерфейс. Например, на некоторых дистрибутивах установленная версия Qt слишком старая для GUI.
Сборки под Windows ARM64 тоже существуют, но пока не проверены на реальном устройстве.
macOS в текущей версии нет.
Первая публичная альфа — это ещё не готовый продукт
31 октября 2026 года я выпустил NetRuleRouter v0.1.0-alpha.1.
К этому моменту программа уже умела работать с правилами для сайтов, адресов, сетей и приложений, имела графический интерфейс, диагностику, статистику, инструменты защиты от утечек и поддержку Windows и Linux.
На первый взгляд можно было бы назвать её готовой.
Но я не хочу создавать у пользователей ложное ощущение, что инструмент проверен в любых условиях.
У программ, вмешивающихся в сетевую маршрутизацию, цена ошибки заметно выше, чем у многих обычных утилит.
Если что-то пойдёт не так, можно временно остаться без доступа к интернету или получить совсем не тот маршрут, который ожидался.
Кроме того, существуют десятки VPN-клиентов, сетевых адаптеров, драйверов и корпоративных конфигураций, которые невозможно проверить на одном-двух компьютерах.
Поэтому я отдельно документирую известные ограничения. В частности, в некоторых режимах защиты остаются особенности применения правил сразу после запуска Windows, а работа с общими IP-адресами и DNS зависит от платформы и конфигурации.
До стабильного релиза предстоит дополнительно проверить IPv6, устранить оставшиеся временные промежутки в работе защиты, расширить тестирование Linux и улучшить совместимость с разными сетевыми конфигурациями.
Хочется сделать программу, которую действительно можно установить, один раз настроить и больше не трогать.
Пока до этого ещё есть определённый путь.
А что дальше?
Планов накопилось гораздо больше, чем свободного времени.
В ближайшей перспективе — исправление ошибок, совершенствование интерфейса, расширение диагностики, тестирование разных сетевых конфигураций и подготовка стабильного выпуска.
Есть и идеи, выходящие за рамки первоначального замысла.
Например, управление приоритетами и скоростью отдельных приложений или адресов. Возможность более гибко работать с несколькими корпоративными подключениями. Дополнительные способы направления трафика через локальные прокси. Расширенная статистика, которая позволит видеть не только текущее распределение, но и историю использования соединений.
Часть этих идей уже появилась благодаря обсуждениям с другими людьми.
После публикации первой статьи на Хабре мне начали рассказывать о собственных сценариях использования нескольких подключений. Оказалось, что у кого-то похожая задача возникла на macOS, кому-то нужно одновременно работать с несколькими локальными прокси, а кто-то давно решает подобные задачи сложными конфигурациями сетевых инструментов.
Это одна из причин, почему я решил опубликовать проект с открытым исходным кодом.
Мне интересно не только развивать собственное решение, но и увидеть, какие проблемы с маршрутизацией существуют у других пользователей.
NetRuleRouter распространяется под лицензией MPL-2.0. Исходный код и первая публичная альфа доступны на GitHub.
Релизы для Windows и Linux: https://github.com/kroxiksut/net-rule-router/releases
Сообщество для вопросов, ошибок и предложений: https://t.me/netrulerouter
Вместо заключения
Когда я начинал разработку 1 апреля, мне казалось, что потребуется небольшая утилита для нескольких правил маршрутизации.
Семь месяцев спустя у проекта появились собственный движок на Rust, графический интерфейс, инструменты диагностики, статистика трафика, терминальное управление и поддержка двух операционных систем.
И всё это выросло из желания перестать вручную переключать сетевые подключения ради разных сайтов.
Самое интересное, что по мере разработки обнаружилось гораздо больше сценариев, чем я представлял в самом начале.
Поэтому мне действительно интересно узнать, как вы решаете подобные задачи.
Используете два интернет-подключения на одном компьютере? Приходится совмещать личные и корпоративные сети? Настраиваете маршрутизацию вручную или пользуетесь готовыми инструментами?
Возможно, какие-то из ваших сценариев и станут следующими возможностями NetRuleRouter.