Группы пиров WireGuard на концентраторе: владение источником и политика

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

Две задачи, разделённые

Туннельный уровень отвечает на узкий вопрос: авторизовал ли ключ этого пира этот внутренний адрес источника. Уровень пересылки отвечает на более широкий: может ли этот пакет выйти в сторону того назначения. Ни один не отвечает на вопрос другого, и ни один сам по себе не является полной политикой доступа.

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

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

Дайте каждому пиру только его собственный адрес

Пиры с несколькими хостами соблазняют выдать на стороне сервера весь диапазон группы. Это разрешение — заявка на адрес источника, поэтому скомпрометированный или неверно настроенный клиент может предъявить любой адрес из диапазона, и туннель его примет. Назначайте /32 на каждого пира для его собственного внутреннего адреса. Задавайте диапазоны групп только на клиентах, где они описывают какие назначения этот клиент может достигать, а не какие источники он может использовать.

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

Напишите политику пересылки, разделяющую группы

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

iifname "wg0" oifname "wg0" ip saddr 10.66.10.0/24 ip daddr 10.66.10.0/24 accept
iifname "wg0" oifname "wg0" ip saddr 10.66.20.0/24 ip daddr 10.66.20.0/24 accept
iifname "wg0" oifname "wg0" drop

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

Порядок решает, применяется ли политика

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

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

Проверяйте матрицу, а не число файлов

Постройте небольшую матрицу ожидаемых результатов и проверьте каждую ячейку. Из группы A в группу A должно работать, из группы B в группу B должно работать, а из A в B — нет, в обе стороны и для обоих семейств адресов, если вы их поддерживаете.

nft list ruleset
wg show wg0 allowed-ips
ping -c 2 10.66.10.5
conntrack -L -s 10.66.20.7 2>/dev/null | head

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

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