Избирательная маршрутизация через свой сервер: нужное идёт в туннель, остальное напрямую

Статические маршруты — для сервисов со своими диапазонами адресов

В основной сети трафик в туннель надёжно уводит только запись в таблице маршрутизации. Для сервиса я выясняю его собственные диапазоны адресов по номеру автономной системы (AS). Автономная система — это сеть, закреплённая за компанией. Каждый диапазон добавляется отдельным маршрутом через туннель. Через туннель идут только адреса из этих маршрутов.

Общую облачную площадку маршрутами не закрыть

У того же правила есть обратная сторона. Если сервис работает через крупную сеть доставки контента (CDN), те же адреса делят с ним множество других сайтов. Если пустить такой блок в туннель целиком, туда уйдёт много постороннего трафика, и сеть замедлится — именно этого я и хотел избежать. Здесь подходят только узкие подсети под адреса, которые реально видны в работе, или отдельный сегмент сети, где туннель включён для всего. Это осознанный выбор.

DNS-привязки — по одному домену

Маршрут бесполезен, если имя домена превращается в адрес, которого нет в маршрутах. Поэтому для нужных доменов назначен отдельный DNS-сервер, доступный через туннель. Правила, на которые ушло больше всего отладки:

• привязка делается для каждого домена отдельно: при общей привязке любой сбой туннеля ломает DNS во всей сети
• корневые домены общих CDN и облачных API привязывать нельзя: через них работает много других сервисов
• привязка основного домена сервиса действует и на его поддомены, поэтому список не приходится вести вручную
• работу DNS проверяю только из того же сегмента: запросы между сегментами роутер режет, и проверка из соседнего даёт ложный результат

Мобильные приложения и игры подключаются по адресу напрямую

Отдельный источник сюрпризов: приложения часто подключаются к своим серверам по прямым адресам, нередко по UDP, и к DNS вообще не обращаются. DNS-привязка здесь не поможет, нужны маршруты. WireGuard передаёт UDP без проблем, так что вопрос только в том, насколько полон список диапазонов.

Настройка через HTTP API, потому что SSH ненадёжен

SSH на роутере регулярно недоступен: сессии зависают, порт перестаёт отвечать как раз тогда, когда что-то нужно срочно поправить. Поэтому всю настройку я перевёл на HTTP API роутера, а вспомогательный скрипт написал на стандартной библиотеке Python:

• вход по схеме «запрос — ответ» (challenge-response): роутер присылает случайную строку, скрипт считает из неё и пароля хеш, и сам пароль по сети не передаётся
• сессия живёт несколько минут, поэтому при ответе 401 скрипт сам входит заново и повторяет запрос
• массовые правки идут пачками по два-три десятка записей: API склеивает одинаковые команды удаления, и слишком большая пачка молча теряет часть изменений
• изменение сохранится после перезагрузки, только если отдельно вызвать сохранение настроек

Поиск утечек: адрес найден, а трафик идёт мимо туннеля

Самый полезный скрипт сравнивает два списка: адреса, которые роутер уже получил от DNS для отслеживаемых доменов, и адреса, покрытые статическими маршрутами. Всё, что есть в первом списке и отсутствует во втором, идёт мимо туннеля. Так нашёлся отдельный диапазон, откуда сервис отдавал картинки и вложения: сам сервис открывался, а они — нет.

Снимок настроек перед изменением и готовый откат

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

Режим выбирается подключением к сети

В сети три сегмента, то есть три отдельные подсети с разными правилами: полный туннель, только нужное через туннель и всё напрямую через провайдера. На самом устройстве ничего настраивать не нужно — его просто подключают к нужной сети. Это же даёт запасной путь. Если избирательные маршруты чего-то не покрывают, устройство временно переводят в сегмент с полным туннелем и спокойно разбираются.

Сбой, из-за которого я переписал своё же правило

После очередной перезагрузки пропал весь интернет: не находился ни один адрес, время не синхронизировалось, работал только туннель. Причина оказалась внешней: DNS-сервер провайдера перестал отвечать правильно. Исправление шло против моего же правила «никогда не отправлять весь DNS через туннель». Пришлось отключить DNS-серверы, которые провайдер выдаёт автоматически (по DHCP), и направить запросы к публичному DNS-серверу через работающий туннель. Правило в своих заметках я переписал и добавил условие, при котором оно не действует. Пожалуй, это полезнее самого исправления.

Смена сервера означает перенос всех правил

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

Сторожевой процесс доучили на реальном сбое

Однажды после перезагрузки VPS туннель не поднялся: в настройках остался пустой блок, и служба падала при каждом запуске. Сторожевой процесс этого не заметил. Он реагировал только на пропажу интерфейса и на то, что туннель давно не обменивался ключами (handshake). Теперь он ещё и чистит настройки перед перезапуском и срабатывает, когда служба переходит в состояние сбоя. Такие сбои система исправляет сама.