Гостевой Wi-Fi продолжает использовать основной маршрут: дайте ему собственный выход

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

Симптом: гости всё равно выходят через WAN

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

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

Шаг 1: настоящий сегмент, а не только имя

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

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

Не объединяйте гостей с основной LAN мостом, чтобы упростить настройку VPN. Это меняет нужную вам изоляцию на короткий путь маршрутизации, и это обычная причина, по которой гостевая сеть в итоге получает доступ к принтеру и NAS.

Шаг 2: выберите туннель по источнику

Таблицы маршрутизации выбираются по назначению, поэтому правило «отправь 0.0.0.0/0 в туннель» действует для всех. Политическая маршрутизация добавляет второе измерение: выберите таблицу по адресу источника. На маршрутизаторе под Linux это дополнительное правило плюс отдельная таблица, и порядок важен, потому что побеждает первое совпавшее правило:

ip rule add from 192.168.60.0/24 lookup 100 priority 1000
ip route add default dev wg0 table 100
ip route get 1.1.1.1 from 192.168.60.10

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

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

Шаг 3: обратный путь и трансляция

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

nft add rule ip nat POSTROUTING ip saddr 192.168.60.0/24 oifname "wg0" masquerade

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

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

Проверяйте изоляцию, а не только просмотр

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

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

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

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