Обмежити шлюз 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, відредагованих вручну, тому оператори роблять висновок, що правило відсутнє, хоча насправді воно завантажене. Читайте необроблений список згори донизу, а не шукайте фрагмент. Якщо охорона з'являється після дозволу стану, межа робить не те, на що натякає файл.

Потім перевіряйте поведінку, а не текст. Відкрийте нове з'єднання до дозволеного хоста й поспостерігайте за відповіддю, спрямуйте нешкідливий запит до призначення поза підмережею й переконайтеся, що він помирає, спробуйте з'єднання між рівноправними вузлами, спробуйте службу, локальну для шлюзу, і спробуйте незапрошене з'єднання з локальної мережі до клієнта. Додайте один потік поза областю, який існував до зміни, і очистіть лише цей потік, а не спорожняйте всю таблицю відстеження машини.

Запишіть обмеження поруч із правилами: це обмежує транзит і ніщо інше. Воно не заважає клієнтові користуватися власним інтернет-з'єднанням, не заважає дозволеному хосту локальної мережі передавати трафік далі й не замінює автентифікацію всередині дозволених служб.