Типичная задача домашней сети: телевизор и рабочий ноутбук должны ходить напрямую, а телефон и настольный компьютер — через туннель. Или наоборот. В большинстве прошивок это решается правкой таблицы маршрутизации, а в KeeneticOS для этого есть отдельный механизм — приоритеты подключений.
Он проще, чем маршруты, но устроен иначе, чем многие ожидают. Разберём, как именно.
Политика привязывается к устройству, а не к сайту
Это главное, что нужно понять до настройки.
Политика подключений отвечает на вопрос «кто», а не «куда». Вы выбираете устройство в домашней сети и говорите: его трафик идёт через этот интерфейс. Весь трафик, целиком, независимо от того, на какой сайт он направлен.
Статический маршрут отвечает на обратный вопрос — «куда»: пакеты в такую-то подсеть отправлять через такой-то интерфейс, от кого бы они ни пришли.
Для домашней сети почти всегда нужен первый вариант. «Пусть ноутбук ходит через туннель» настраивается за минуту, а «пусть все ходят через туннель только на один сайт» — задача принципиально другой сложности, и ниже видно почему.
Настройка политики
Компонент клиента WireGuard должен быть уже установлен, а подключение — создано и поднято. Дальше:
- Откройте «Сетевые правила» → «Приоритеты подключений».
- Создайте политику — назовите её осмысленно, например «Через туннель».
- В списке подключений включите в политику интерфейс WireGuard. Порядок в списке задаёт приоритет: верхнее подключение используется, пока работает.
- Перейдите на вкладку с устройствами и привяжите к политике нужные из списка зарегистрированных.
Устройство обязано быть зарегистрировано в роутере — то есть иметь постоянную запись в списке хостов. Незарегистрированные клиенты попадают в политику по умолчанию, и привязать их поимённо не выйдет.
С этого момента привязанные устройства выходят в интернет через туннель, остальные — как раньше.
Что происходит, когда туннель падает
Здесь скрыт неочевидный эффект, о который спотыкаются чаще всего.
Если в политику добавлено только WireGuard-подключение, то при обрыве туннеля привязанные устройства теряют интернет полностью. Роутер не станет отправлять их трафик напрямую — вы же сказали ходить именно этим путём.
По сути это встроенный kill switch, и для части сценариев поведение правильное: трафик не утечёт мимо туннеля незаметно. Но если задача была «через VPN, а если не получается — то как угодно», добавьте в ту же политику проводное подключение вторым приоритетом. Тогда при падении туннеля устройства переключатся на прямой канал.
Решать, какое поведение нужно, стоит осознанно — умолчание здесь строгое.
Почему маршрут «только на один сайт» работает плохо
Запрос понятный: пустить через туннель один конкретный сервис, а остальное оставить напрямую. В KeeneticOS для этого есть статические маршруты, и настраиваются они в «Маршрутизации».
Проблема в том, что маршрут задаётся адресом или подсетью, а не именем.
Поле для доменного имени в интерфейсе есть, но работает оно не так, как кажется: роутер разрешает имя в адрес в момент создания правила и дальше использует полученный адрес. Крупный сервис за CDN отвечает разными адресами в зависимости от географии, времени и балансировки — и завтра поедет мимо маршрута.
Надёжно это работает только с сервисами, у которых адреса постоянные и известны заранее. Таких немного.
Что делать вместо этого. Если через туннель нужен один сервис — часто проще поднять его на самом устройстве, а не на роутере. Приложение WireGuard на телефоне и компьютере умеет раздельное туннелирование по приложениям, и это точнее любых маршрутов на роутере.
Способ по именам всё-таки существует, но он не для всех
Штатной маршрутизации по доменам в KeeneticOS нет, и встроенными средствами эту задачу не решить. Рабочие схемы строятся вокруг DNS: на роутер ставится Entware, в нём — dnsmasq-full и ipset, запросы к нужным именам перехватываются на уровне разрешения имён, а полученные адреса складываются в набор, по которому уже работает маршрутизация.
Цена такого решения выше, чем кажется по описанию:
- нужен USB-накопитель под Entware и доступ по SSH;
- настройка живёт в скриптах, а не в веб-интерфейсе, и не переживает сброс к заводским;
- схема привязана к версии KeeneticOS и ломается при обновлениях;
- имена, которые приложение запрашивает мимо роутерного DNS — а так делают многие, — в набор не попадают вовсе.
Последний пункт важнее прочих: сама конструкция держится на том, что все запросы к именам проходят через роутер. Одно приложение со своим DNS внутри — и правило для него молча не работает.
Поэтому для большинства задач возвращаемся к разделению по устройствам: оно настраивается в интерфейсе, переживает обновления и не зависит от того, куда приложение отправляет запросы к именам.
Если туннелей на роутере не один, а два, к этому добавляется отдельный набор ограничений — разобран отдельно: маршруты в KeeneticOS глобальны и действуют поверх политик, поэтому развести по туннелям получается устройства, но не адреса.
Отдельный случай: маршруты для Telegram
Telegram спрашивают чаще остального, поэтому стоит сказать прямо.
Мессенджер использует собственные серверы с известными диапазонами адресов, и статический маршрут для них в принципе возможен. Но есть путь проще: MTProto-прокси подключается внутри самого приложения и не требует ни маршрутов, ни VPN на роутере вовсе. Одна ссылка, один тап — и трафик мессенджера идёт через прокси, а остальная сеть не затронута.
Отдельная тонкость: медиафайлы Telegram загружает с узлов раздачи контента, адреса которых в маршрут не попадут. Через прокси, настроенный в приложении, идёт всё — и переписка, и вложения.
Проверка результата
После настройки политика проверяется не «на глаз», а сравнением с двух устройств одновременно.
На привязанном к политике устройстве и на любом другом откройте сайт проверки IP-адреса. Адреса должны различаться: у первого — адрес VPN-сервера, у второго — провайдерский.
Если совпадают, ищите причину в этом порядке:
- устройство не зарегистрировано в роутере и попало в политику по умолчанию;
- в карточке WireGuard-подключения не обновляется время последнего рукопожатия — туннель не работает, а не маршрутизация;
- на устройстве включён собственный VPN-клиент или DNS-over-HTTPS в браузере, который ходит мимо роутера.
Последний пункт стоит проверять первым: браузер со своим шифрованным DNS способен показывать картину, не имеющую отношения к настройкам роутера.
Коротко
Приоритеты подключений — правильный инструмент для «часть устройств через туннель». Настраивается за минуту, маршрутов писать не нужно, устройство должно быть зарегистрировано.
Маршрут «только на один сайт» на роутере надёжно не решается: имена превращаются в адреса один раз, а адреса у крупных сервисов меняются. Для точечных задач берите раздельное туннелирование на самом устройстве, а для Telegram — прокси внутри приложения.
И проверьте, что произойдёт при обрыве: политика с единственным туннельным подключением оставит устройства без интернета.