Клиенты LAN не используют VPN роутера, пока не включена маршрутизация по политикам

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

Правило фильтра не может выбрать интерфейс

Поток пакетов на Linux-роутере сначала выполняет решение о маршруте, а затем хук forward. К моменту, когда правило совпадает с исходящим туннельным устройством, ядро уже решило, что туннель — это выход. Если главная таблица по-прежнему предпочитает маршрут по умолчанию через WAN, пакет идёт к провайдеру, и только что написанное правило разрешения его никогда не увидит. Этот единственный факт о порядке объясняет, почему страница новых правил межсетевого экрана ничего не меняет.

В примере ниже используются LAN 192.168.8.0/24 на br-lan, туннельное устройство tun0 и одна приставка по адресу 192.168.8.23, которая должна идти через туннель.

Прочитайте поиск, прежде чем править правила

Попросите ядро разрешить маршрут от имени этого клиента. Ответ содержит исходящее устройство и адрес источника, который был бы выбран, и это всё, что нужно для подтверждения диагноза. Если в ответе указано устройство WAN, у пакета не было шанса дойти до вашего правила.

ip -4 route get 198.51.100.7 from 192.168.8.23

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

Привяжите таблицу к клиентам, которые хотите охватить

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

ip -4 route add default dev tun0 table 200
ip -4 rule add iif br-lan lookup 200 priority 200

Интерфейсы прошивки обычно показывают те же объекты, что и страница маршрутизации по политикам или политики VPN. Список устройств там проще поддерживать, чем написанные вручную правила, и он обычно переживает обновления, меняющие синтаксис правил.

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

Держите локальные назначения вне туннеля

Новая таблица знает только те маршруты, которые вы в неё положили. Префикса LAN нет, поэтому трафик принтера и NAS пошёл бы по маршруту по умолчанию в туннель и исчез. Маршрут throw завершает поиск в этой таблице и возвращает решение главной таблице.

ip -4 route add throw 192.168.8.0/24 table 200

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

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