Как дать одной тестовой сети LAN собственный выход через WireGuard

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

Решите, где живёт выход

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

Пространство имён или ВМ стоит памяти и даёт чистый радиус поражения. Маршрутизация по политике стоит два правила и оставляет вам одну коробку для отладки.

Выберите выход, который разрешает ваш источник

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

Подтвердите три вещи у оператора: партнёр разрешает адрес вашего туннеля, он пересылает IPv4, а не завершается на себе, и применяет NAT на выходе. Без первого ваши пакеты приходят и исчезают. Без третьего они уходят с частным источником и гибнут на следующем шаге. Затем проверьте, что wg-quick не устанавливает свой собственный маршрут по умолчанию, чему препятствует Table = off; эта настройка подавляет создание маршрутов, а не проверки AllowedIPs у партнёра и не его работу с DNS.

Два объекта политики выполняют направление

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

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

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

ip rule add from 192.168.50.0/24 iif lan0 lookup 51861 pref 1000
ip rule add from 192.168.50.0/24 iif lan0 unreachable pref 1001
ip route add table 51861 default dev wg0

Закройте щель отката, прежде чем её открыть

Сначала установите стража, а поиск потом. Обратный порядок оставляет окно длиной в секунды, в котором трафик тестового клиента может достичь канала наверх.

Фильтр завершает картину. В хуке forward принимайте направление из LAN в туннель для тестового префикса и установившееся обратное направление, а затем отбрасывайте всё остальное; NAT для этого префикса на интерфейс туннеля идёт в postrouting. Именно оставленный policy drop на цепочке пересылки превращает отсутствующий маршрут в тишину, а не в утечку. Фильтрация обратного пути требует свободного режима на интерфейсе туннеля, потому что публичный источник, приходящий после декапсуляции, имеет лучший обратный маршрут на стороне WAN. Linux берёт большее из значений all и для интерфейса, поэтому настройка интерфейса туннеля — это не то же самое, что ослабление проверки везде.

Докажите это отказом

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

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