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