Клиенты VPN и локальная сеть: когда нужна отдельная зона

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

Имя зоны ничего не шифрует и не аутентифицирует пользователя. Оно лишь группирует интерфейсы для модели политик межсетевого экрана.

Что на самом деле управляет членство в зоне

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

Разрешение из зоны VPN в зону локальной сети не является автоматически обратным разрешением. Правила пересылки направленные, и правило, разрешающее трафик от клиента к серверу, не разрешает сеансы от сервера к клиенту. Клиент, который может открыть соединение к серверу, — не тот клиент, к которому сервер может открыть обратное соединение.

Именно это различие делает отдельную зону полезной: можно явно указать каждое направление и каждую роль. Записывайте направление рядом с каждым правилом.

Решение первое: вход, пересылка или оба

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

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

Решение второе: какие ресурсы нужны удалённым клиентам

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

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

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

Решение третье: как вы докажете границу

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

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

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