Ограничить шлюз OpenVPN одной локальной сетью правилами UFW

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

Сначала запишите топологию и разрешение

В примере используется сервер Community OpenVPN с устройством TUN в пространстве пользователя по имени tun0, пул клиентов 10.77.0.0/24, и одна подключённая подсеть 192.168.60.0/24 на интерфейсе lan0. Пересылка IPv4 уже работает, и в локальной сети уже есть обратный маршрут к пулу, так что здесь ничего не зависит от преобразования между ними.

Брандмауэром на этом хосте владеет UFW, и ни набор правил контейнера, ни отдельная таблица nftables не могут установить более ранний путь разрешения. Быстрый путь разгрузки потока, обходящий фильтр, сделал бы цепочки охраны просто украшением, поэтому убедитесь, что ни один не активен. Оставьте собственную пересылку client-to-client OpenVPN выключенной, потому что трафик между равноправными узлами, который никогда не проходит через фильтр операционной системы, ею ограничить нельзя. Внешний слушатель и административные правила остаются как есть, поскольку это изменение управляет расшифрованным трафиком туннеля, а не заменяет брандмауэр.

Поставьте охрану перед ранними разрешениями UFW

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

В разделе *filter файла /etc/ufw/before.rules объявите две цепочки рядом с существующими объявлениями и перед любой строкой правила.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Сразу после объявлений и перед разрешениями для входа и пересылки перейдите в них и определите, что они пропускают.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

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

Прочитайте, что каждая охрана пропускает и отклоняет

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

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

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

Разрешите подсеть и закройте боковые двери

Сначала просмотрите разрешение маршрута, затем снимите флаг предварительного просмотра, чтобы применить его: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. После этого проверьте порядок пользовательских правил, потому что более ранний отказ всё равно побеждает более позднее разрешение. Разрешение на всю подсеть — тоже неверная форма, когда должен быть доступен только порт HTTPS одного хоста.

Обратите внимание, что делает отбрасывание входа: клиенты туннеля не могут достичь ни одного сервиса на самом шлюзе, включая слушателя DNS, привязанного к его адресу в локальной сети. Размещение DNS там требует намеренного исключения перед отбрасыванием и пересмотренного договора разрешения. Если UFW управляет IPv6, добавьте соответствующие отбрасывания и для tun0 в файле before6.rules, потому что список назначений IPv4 ничего не говорит о пакетах IPv6.

Проверяйте загруженную политику, а не предварительный просмотр

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

sudo ufw --dry-run reload
sudo ufw show raw

Убедитесь, что охрана туннеля появляется перед разрешениями по умолчанию для состояния и ICMP. Простой ufw status не показывает правила before, отредактированные вручную, поэтому операторы делают вывод, что правило отсутствует, хотя на самом деле оно загружено. Читайте необработанный список сверху вниз, а не ищите фрагмент. Если охрана появляется после разрешения состояния, граница делает не то, на что намекает файл.

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

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