ufw allow 443 ничего не дал службе за VPN

Ping проходит от клиента VPN, служба TCP уходит в тайм-аут, а ufw allow 443/tcp не меняет ровным счётом ничего. Когда приложение работает на хосте за шлюзом, а не на самом шлюзе, это разрешение было написано для неверного пути трафика. Пакет не адресован межсетевому экрану и не передаётся локальному процессу, поэтому правила входа его никогда не видят. Исправление — правило маршрута, нацеленное на перенаправляемый поток, и доказательство для него уже есть в журнале.

Решите, является ли назначение локальным или перенаправляемым

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

Строка журнала с одним и тем же интерфейсом в полях IN и OUT всё ещё может описывать маршрутизированный пакет, потому что туннель, который проводит клиентов внутрь и наружу через одно устройство, выглядит именно так. Адрес назначения решает вопрос быстрее, чем имена интерфейсов. Двукратное видение одного и того же имени не доказывает локальную доставку, а выдумывание туннельного интерфейса, которого развёртывание никогда не создавало, тоже не помогает.

Прочитайте блок, прежде чем добавлять любое правило

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

Напишите самое узкое подходящее правило маршрута

В этом примере клиенты приходят на tun0 из 172.20.8.0/24, служба слушает на 10.30.0.15 на порту 8443, а шлюз выходит через ens5. Эти значения выбраны так, чтобы вовсе не походить на значение облачного VPC по умолчанию 10.0.0.0/16 или на домашнюю сеть 192.168.0.0/16, а 8443 держит пример вдали от собственного слушателя 443 на шлюзе.

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

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

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

Проверьте, что UFW не может обеспечить за вас

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

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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