Правило слушателя firewalld и политика пересылки: что делает каждое

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

Две политики, один туннель

Внешняя политика отвечает на простой вопрос: может ли пакет из этого источника достичь UDP 1194 на этом хосте? Внутренняя политика отвечает на другой: может ли аутентифицированный клиент за этим туннелем достичь этого назначения, по этому протоколу, на этом порту? Первая — про сокет, вторая — про путь, и firewalld моделирует их разными объектами, потому что они решаются в разных точках. Одна — свойство сокета на этом хосте, другая — свойство пути через него.

Практическое следствие: работающий туннель ничего не говорит о второй политике, а правильная вторая политика не делает первую ненужной.

Пропустите реальный внешний слушатель

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

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

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

Авторизуйте расшифрованное назначение отдельно

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

Явно определите разрешённые источники, а всё остальное пусть падает в отказ. Разрешение для внешней службы — не эта политика, как бы ни выглядела раскладка зон.

Почему доверие к интерфейсу — неправильный короткий путь

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

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

Проверьте три вещи, включая один отказ

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

Запишите зону, порт, транспорт и объект политики в заметки сервера. Иначе следующее изменение на этом хосте начнётся с того же предположения.