Набор nftables, питаемый DNS, и WireGuard: как работает передача

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

Рассматривайте схему как цепочку, а не как конфигурацию. Вопрос на каждом шаге: какой компонент владеет решением и что происходит, когда его вход отсутствует.

Что может и чего не может ответ DNS

dnsmasq может копировать адреса из ответов в набор nftables, и это наполнение, а не решение о маршрутизации. Этот параметр, описанный в руководстве dnsmasq, задаёт семейство, таблицу и набор, а его ведущий 4# выбирает только записи A, поэтому адресатам v6 нужна своя организация. Набор должен уже существовать, потому что разрешитель добавляет элементы в то, что создал владелец экрана. Ничто на этом шаге не выбирает интерфейс, таблицу или партнёра.

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

Набор — это вход, а не маршрут

Элемент в наборе — это условие совпадения. Что-то должно посмотреть на него, решить, что этот пакет начинает новый поток, и применить политику, отправляющую поток через туннель. В Linux это обычно означает выходной путь с поддержкой маршрутизации, умеющий ставить метку, правило, отправляющее помеченные пакеты в отдельную таблицу, и маршрут в этой таблице на устройство WireGuard. Одно лишь членство ничего из этого не устанавливает.

nft add set inet vpn_select office_v4 { type ipv4_addr\; }
ip rule add fwmark 0x40 table 200
ip route add default dev wg0 table 200
wg show wg0 allowed-ips

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

Метки, таблицы и покрытие партнёра

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

Собственные внешние пакеты туннеля должны уходить от классификатора. Инструменты WireGuard дают метку сокета именно для этого, и её использование не позволяет инкапсуляции маршрутизироваться обратно в интерфейс, который она строит.

Проверяйте каждое время жизни отдельно

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

dig +short office.example
nft list set inet vpn_select office_v4
conntrack -L -d 10.60.8.15
ip rule show

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

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