Типичная задача домашней сети: телевизор и рабочий ноутбук должны ходить напрямую, а телефон и настольный компьютер — через туннель. Или наоборот. В большинстве прошивок это решается правкой таблицы маршрутизации, а в KeeneticOS для этого есть отдельный механизм — приоритеты подключений.
Он проще, чем маршруты, но устроен иначе, чем многие ожидают. Разберём, как именно.
Политика привязывается к устройству, а не к сайту
Это главное, что нужно понять до настройки.
Политика подключений отвечает на вопрос «кто», а не «куда». Вы выбираете устройство в домашней сети и говорите: его трафик идёт через этот интерфейс. Весь трафик, целиком, независимо от того, на какой сайт он направлен.
Статический маршрут отвечает на обратный вопрос — «куда»: пакеты в такую-то подсеть отправлять через такой-то интерфейс, от кого бы они ни пришли.
Для домашней сети почти всегда нужен первый вариант. «Пусть ноутбук ходит через туннель» настраивается за минуту, а «пусть все ходят через туннель только на один сайт» — задача принципиально другой сложности, и ниже видно почему.
Настройка политики
Компонент клиента WireGuard должен быть уже установлен, а подключение — создано и поднято. Дальше:
- Откройте «Интернет» → «Приоритеты подключений».
- Создайте политику — назовите её осмысленно, например «Через туннель».
- В списке подключений включите в политику интерфейс WireGuard. Порядок в списке задаёт приоритет: верхнее подключение используется, пока работает.
- Перейдите на вкладку с устройствами и привяжите к политике нужные из списка зарегистрированных.
Устройство обязано быть зарегистрировано в роутере — то есть иметь постоянную запись в списке хостов. Незарегистрированные клиенты попадают в политику по умолчанию, и привязать их поимённо не выйдет.
С этого момента привязанные устройства выходят в интернет через туннель, остальные — как раньше.
Что происходит, когда туннель падает
Здесь скрыт неочевидный эффект, о который спотыкаются чаще всего.
Если в политику добавлено только WireGuard-подключение, то при обрыве туннеля привязанные устройства теряют интернет полностью. Роутер не станет отправлять их трафик напрямую — вы же сказали ходить именно этим путём.
По сути это встроенный kill switch, и для части сценариев поведение правильное: трафик не утечёт мимо туннеля незаметно. Но если задача была «через VPN, а если не получается — то как угодно», добавьте в ту же политику проводное подключение вторым приоритетом. Тогда при падении туннеля устройства переключатся на прямой канал.
Решать, какое поведение нужно, стоит осознанно — умолчание здесь строгое.
Маршрут «только на один сайт»: что изменилось в версии 5.0
Запрос понятный: пустить через туннель один конкретный сервис, а остальное оставить напрямую. Долгое время KeeneticOS отвечала на него плохо, и многие инструкции в сети написаны именно про то время.
Статический маршрут задаётся адресом или подсетью, а не именем. Адрес сайта приходится узнавать отдельно — а крупный сервис за CDN отвечает разными адресами в зависимости от географии, времени и балансировки, и завтра поедет мимо маршрута. Надёжно это работает только с сервисами, у которых адреса постоянные и известны заранее. Таких немного.
Маршруты DNS появились в KeeneticOS 5.0 и закрывают именно этот пробел: вы составляете список доменных имён и привязываете его к туннелю, а адреса роутер узнаёт сам — из ответов на запросы имён, которые проходят через него. Настраивается это в веб-интерфейсе, без сторонних пакетов.
У механизма два условия, о которые спотыкаются чаще всего. Он действует только на устройства в политике по умолчанию — то есть как раз на те, что не привязаны к собственной политике. И устройство должно спрашивать имена у роутера: браузер или телефон со своим шифрованным DNS для него невидимы. Как это настраивается и почему иногда молча не срабатывает — в отдельной статье про маршруты на Keenetic.
Если на роутере версия старше 5.0
У ряда прежних моделей основной канал обновлений остановился на ветке 4.3, и вкладки «Маршруты DNS» на них нет. Там по-прежнему в ходу схемы вокруг стороннего 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 способен показывать картину, не имеющую отношения к настройкам роутера.
Коротко
Приоритеты подключений — правильный инструмент для «часть устройств через туннель». Настраивается за минуту, маршрутов писать не нужно, устройство должно быть зарегистрировано.
Маршрут «только на один сайт» статическим маршрутом надёжно не решается: адреса у крупных сервисов меняются. С версии 5.0 для этого есть маршруты DNS — но только для устройств в политике по умолчанию и пока те спрашивают имена у роутера. Если сервис нужен одному устройству, берите раздельное туннелирование на нём самом, а для Telegram — прокси внутри приложения.
И проверьте, что произойдёт при обрыве: политика с единственным туннельным подключением оставит устройства без интернета.