TrustTunnelOpenWrt: мой пакет для OpenWrt с интерфейсом LuCI

У OpenWrt есть приятная особенность: роутер можно настроить под свои задачи. Но вместе с этой свободой приходит ответственность за конфигурацию. Запустить сетевой клиент — только начало. Дальше нужно организовать автозапуск, согласовать DNS с маршрутизацией, сохранить настройки при обновлении и понять, где искать причину сбоя.

Мой проект TrustTunnelOpenWrt собирает эти задачи в пакет luci-app-trusttunnel. Он интегрирует клиент TrustTunnel с OpenWrt и добавляет управление через LuCI — штатный веб-интерфейс роутера. Можно настроить подключение к удалённому серверу, задать правила для выбранных доменов и проверить результат в браузере.

Что я собрал в интерфейсе

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

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

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

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

Как связаны DNS и маршрутизация

Пакет поддерживает выборочную маршрутизацию и режим для интернет-трафика всей LAN с учётом исключений. В первом случае через удалённый сервер направляются соединения, соответствующие выбранным спискам; остальные идут напрямую. Трафик самого роутера подключается отдельной настройкой. Режимы описаны в руководстве проекта.

В выборочном режиме цепочка выглядит так: DNS роутера получает адреса домена, добавляет их в набор nftables, а правила маркируют соответствующие пакеты. По метке выбирается отдельная таблица маршрутизации.

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

У такого подхода есть ограничения. В выборочном режиме важны DNS-запросы через роутер: собственный DoH или DoT на устройстве может нарушить сопоставление доменов. Кроме того, несколько сайтов могут использовать общий IP. Поэтому список доменов нельзя воспринимать как абсолютно точную границу между всеми соединениями. Эти особенности перечислены в README.

Диагностика должна объяснять результат

Работающий процесс ещё не означает, что вся сетевая цепочка настроена правильно. Клиент может запуститься, а нужное правило или DNS-конфигурация — не примениться.

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

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

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

Что происходит при запуске и обновлении

Служба интегрирована с procd. При запуске предусмотрено ограниченное ожидание готовности сети и проверка системного времени: некорректные часы могут помешать проверке сертификата. Настройки из UCI преобразуются в конфигурацию клиента, а созданный файл с параметрами подключения получает права 600. Это можно проверить в init-скрипте.

Отдельная задача — обновление без потери конфигурации. Файл /etc/config/trusttunnel явно объявлен в conffiles, чтобы пакетный менеджер сохранял пользовательские настройки.

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

Что нужно для установки

Проект рассчитан на OpenWrt 25.12 и новее с LuCI и пакетным менеджером apk. Нужен отдельно настроенный сервер TrustTunnel и параметры подключения к нему. Совместимость роутера зависит от наличия сборки клиента под его архитектуру.

Установщик проверяет окружение, ставит зависимости, пакет LuCI и клиент. Для выборочной маршрутизации требуется поддержка nftset в dnsmasq. Если её нет, скрипт предлагает установить dnsmasq-full; такая замена перезапускает DNS на роутере. При первой установке служба остаётся выключенной до настройки. При обновлении скрипт запоминает, работала ли она, и возвращает её в прежнее состояние. Последовательность описана непосредственно в install.sh.

Исходники и инструкции доступны в репозитории TrustTunnelOpenWrt. Если проверишь пакет на своём роутере, полезно оставить issue с моделью устройства, версией OpenWrt и результатами диагностики. Такие отчёты помогают увидеть особенности оборудования, которые трудно воспроизвести на одном стенде.