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 прибирає симптом і знищує доказ тією самою командою, тому це має бути останній експеримент, а не перший.