Правила фаєрвола Proxmox не застосовуються: пояснення конфліктів iptables та nftables

Що ви насправді налагоджуєте (мережеве Netfilter-«проводження», а не GUI)

Правила фаєрвола Proxmox в кінці кінців потрапляють у фільтр пакетів ядра Linux (Netfilter). Сервіс Proxmox (pve-firewall) генерує правила і застосовує їх, використовуючи інструменти, доступні на хості. Якщо хост використовує nftables, а ваші навички налагодження — це iptables (або навпаки), ви можете годину дивитися на порожні ланцюги, поки трафік вільно тече.

Ось ключова річ: «iptables» — це одночасно (а) інтерфейс командного рядка та (б) застарілий формат правил. У сучасному Debian/Proxmox команда iptables може бути сумісним фронтендом, що записує правила в nftables («iptables-nft»). Тому коли ви кажете «покажи мені правила iptables», ви можете дивитися на інший вигляд, ніж той, що насправді активний.

Висновок для виробництва: коли правила фаєрвола «не застосовуються», зазвичай йдеться про одне з наступного:

• Правила встановлюються в nftables, а ви дивитеся iptables-legacy (або навпаки).
• Правила встановлені, але застосовані в хук/ланцюг, який ви не очікували (міст проти маршрутизованого шляху; пріоритети raw/mangle/filter).
• Conntrack дозволяє існуючим потокам продовжуватися, через що ваше нове правило здається марним.
• Інший менеджер фаєрвола (ufw, firewalld, docker, kube-proxy, «корисний» скрипт) переписує таблиці після застосування Proxmox.
• Різниця в конфігурації кластера: GUI редагує один вузол, інший вузол застосовує локальні налаштування.

Фаєрвол — як нарада: половина драми залежить від того, хто перший заговорив. (Жарт 1/2.)

Цікаві факти та історичний контекст (щоб дивність стала зрозумілішою)

1. Netfilter працює в ядрі; iptables і nftables — це простори керування в користувацькому просторі. Обидва в кінцевому підсумку програмують ті самі хук-и ядра, але з різним представленням правил та семантикою.
2. nftables створювали як заміну iptables щоб зменшити дублювання між таблицями IPv4/IPv6/ARP, додати множини, відображення і чистішу синтаксис.
3. Debian переключив стандартну реалізацію iptables на «iptables-nft». Це означає, що iptables може керувати правилами nftables, якщо ви явно не обрали iptables-legacy.
4. iptables-legacy і nftables можуть працювати одночасно без очевидних помилок. Це не перевага; це податок на налагодження.
5. Фільтрація мостів — особливий випадок. Пакети, що проходять через Linux-місти, можна фільтрувати через br_netfilter і sysctl-налаштування на кшталт net.bridge.bridge-nf-call-iptables, що змінює практичне значення «INPUT» і «FORWARD».
6. Поведінка conntrack за замовчуванням дивує людей. Нові блокування не обов’язково розривають встановлені з’єднання, якщо ви явно не блокуєте або не скидаєте їх; часто потрібно очистити conntrack для чистого тесту.
7. Docker історично сильно використовував iptables і може вставляти правила NAT/FORWARD, що суперечать локальним очікуванням — особливо у змішаних конфігураціях з фронтендами nftables.
8. Порядок правил і пріоритет ланцюгів важливіший у nftables, бо кілька базових ланцюгів можуть підключатися на ту саму стадію з явними пріоритетами.
9. Фаєрвол Proxmox орієнтований на хост, але також керує правилами на рівні ВМ; вони можуть реалізовуватись через iptables/nftables на хості, а не всередині гостьової ОС, що дивує людей, звичних до «фаєрвол працює там, де працює програма».

Є надійна операційна сентенція — «надія — не стратегія» — цю ідею часто перефразовують у операціях. Розглядайте стан фаєрвола як те, що ви вимірюєте, а не відчуваєте.

Швидкий план діагностики

Коли правила фаєрвола Proxmox не застосовуються, вам потрібен найкоротший шлях до першої реальної підказки. Ось порядок дій, що рятує під час інцидентів.

1) Підтвердіть, який бекенд ви фактично використовуєте (nft чи legacy)

• Якщо хост використовує nftables (nft list ruleset показує активні ланцюги), припиніть дивитися iptables -S з неправильного бекенду.
• Якщо обидва присутні, вирішіть, який авторитетний, і усуньте неоднозначність.

2) Перевірте стан сервісу Proxmox firewall і останнє застосування

• Чи працює pve-firewall і чи застосовує правила без помилок?
• Чи редагуєте ви правильну область (Datacenter vs node vs VM)?

3) Переконайтеся, що пакети проходять шлях, який ви очікуєте

• Містовий шлях проти маршрутизованого змінює ланцюги та хуки.
• Перевірте sysctl-налаштування br_netfilter і чи фільтрується потрібний інтерфейс.

4) Перевірте на предмет змін правил іншими акторами

• ufw/firewalld, docker, kube-proxy, кастомні скрипти.
• Шукайте мітки часу у логах і дельти правил.

5) Зробіть ваш тест валідним

• Очиcтіть conntrack (обачно) або тестуйте новими з’єднаннями.
• Використовуйте лічильники/логування, щоб довести, що правило застосовується.

Як працює фаєрвол Proxmox «під капотом»

Фаєрвол Proxmox — не магічний щит пакетів. Це генератор правил і менеджер їхнього життєвого циклу. Ви задаєте намір у GUI або в /etc/pve/ конфігурації, і pve-firewall перетворює це на правила ядра.

Правила зазвичай застосовуються на хості і впливають на:

• Трафік хоста (plane управління): SSH, GUI, трафік кластера, зберігання.
• Трафік ВМ і контейнерів: залежно від мосту/маршрутизації і налаштувань фаєрвола, хост фільтрує трафік, що перетинає мости або tap-інтерфейси.

Proxmox також має кілька областей застосування:

• Datacenter firewall: глобальні базові правила; хороші для шаблонів «deny by default».
• Node firewall: правила, специфічні для вузла (наприклад, доступ IPMI, локальні мережі адміністрування).
• VM/CT firewall: правила на рівні гостя; корисні, коли команди ділять один L2-домен і потрібна сегментація без зміни мережі.

Якщо правила «не застосовуються», одна з частих причин — фаєрвол увімкнено в одній області, але не в інших, або увімкнено на невірному інтерфейсі, який фактично використовує трафік (класика з кількома мостами).

iptables проти nftables: патерни конфлікту, що ламають правила Proxmox

Патерн конфлікту 1: «iptables нічого не показує, отже правил немає»

Якщо iptables — це фронтенд для nft, він покаже вам сумісний з iptables вигляд правил, збережених у nftables. Але якщо ви запускаєте iptables-legacy (або ваші скрипти його використовують), ви можете опинитися в двох реальностях:

• Proxmox застосовує правила через nftables (безпосередньо або через iptables-nft)
• Ваша команда налагодження читає legacy-таблиці
• Ви робите висновок «немає правил» і починаєте «виправляти» не ту проблему

Патерн конфлікту 2: одночасна активність nftables і legacy iptables

Це найвитратніший режим відмови, бо система може працювати напівправильно. Частина трафіку фільтрується; інша — ні. NAT поводиться непослідовно. Перезавантаження змінює поведінку залежно від того, який сервіс стартує першим.

Якщо ви хочете стабільну систему, оберіть один. У сучасному Proxmox на Debian це зазвичай означає nftables як механізм ядра з сумісністю через iptables-nft за потреби. Але не дозволяйте iptables-legacy правилам залишатися як старі запити на зміни, за які ніхто не відповідає.

Патерн конфлікту 3: містовий трафік не потрапляє в очікувані ланцюги

У Proxmox трафік ВМ часто проходить через Linux-мости (vmbr0) і tap-пристрої (tapX) або veth-інтерфейси (контейнери). Чи потрапляє містовий трафік під оцінку iptables/nftables, залежить від br_netfilter і sysctl-налаштувань.

Якщо ці sysctl вимкнені, ваше правило «FORWARD drop» може не бачити пакети, що йдуть мостом. Ви будете клясти фаєрвол; Linux ввічливо продовжить працювати як L2-стромач, як ви його попросили.

Патерн конфлікту 4: conntrack змушує думати, що нове правило не спрацювало

Ви блокуєте порт 443, але існуюча сесія curl продовжує працювати. Це conntrack. Багато правил рано допускають ct state established,related — це правильно для продуктивності і щоб не ламати довгоживучі сесії, але вводить в оману при тестуванні.

Патерн конфлікту 5: інший компонент переписує правила після Proxmox

Звичні підозрювані: docker, kube-proxy, ufw, firewalld, кастомні скрипти в cron або systemd таймерах та деякі агенти мережевої автоматизації. Вони не звертають увагу на ваш GUI. Вони дбають про свій бажаний стан.

Якщо правила «застосовуються», а потім зникають — це перший підозрюваний. Інструменти фаєрвола схожі на малюків: якщо двоє ділять одні й ті самі іграшки, хтось неодмінно засмутиться. (Жарт 2/2.)

Практичні завдання: команди, вивід і рішення (12+)

Це перевірки, які я виконую, коли хтось каже «Правила фаєрвола Proxmox не застосовуються». Кожна включає реалістичний вивід і яке рішення з нього випливає.

Завдання 1: Перевірте, чи взагалі увімкнено фаєрвол Proxmox у всіх областях

cr0x@server:~$ pve-firewall status
Status: enabled
Running: yes
Log level: info

Що це означає: Сервіс запущено, фаєрвол увімкнено. Якщо ви бачите Status: disabled, зупиніться тут — увімкніть його в GUI або в конфігурації, перш ніж ганятися за привидами iptables.

Рішення: Якщо вимкнено — увімкніть та повторіть тест. Якщо увімкнено — переходьте до перевірки бекенду правил.

Завдання 2: Підтвердіть здоров’я сервісу pve-firewall і останні помилки

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - PVE Firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled)
     Active: active (running) since Thu 2025-12-26 10:12:33 UTC; 2h 8min ago
   Main PID: 1321 (pve-firewall)
      Tasks: 1 (limit: 154850)
     Memory: 21.4M
        CPU: 4.102s

Що це означає: Якщо тут «failed» або відбувається швидкий рестарт, ваші правила можуть не застосовуватись або застосовуватись частково.

Рішення: Якщо сервіс падає, перегляньте логи та усуньте помилки виконання до того, як переходити до nftables.

Завдання 3: Прочитайте логи pve-firewall на наявність помилок при застосуванні правил

cr0x@server:~$ journalctl -u pve-firewall -n 60 --no-pager
Dec 26 10:12:33 server pve-firewall[1321]: starting PVE firewall
Dec 26 10:12:34 server pve-firewall[1321]: status update OK
Dec 26 10:12:35 server pve-firewall[1321]: ruleset applied

Що це означає: «ruleset applied» — ваш базовий орієнтир. Помилки типу «iptables-restore failed» або «nft: syntax error» одразу звужують пошук до інструментів/бекендів.

Рішення: Якщо бачите помилки при відновленні/застосуванні — перевірте бекенд iptables/nftables і синтаксис правил далі.

Завдання 4: Визначте, чи iptables використовує бекенд nft або legacy

cr0x@server:~$ update-alternatives --display iptables
iptables - auto mode
  link best version is /usr/sbin/iptables-nft
  link currently points to /usr/sbin/iptables-nft
  link iptables is /usr/sbin/iptables
/usr/sbin/iptables-legacy - priority 10
/usr/sbin/iptables-nft - priority 20

Що це означає: На цьому хості команда iptables програмує nftables. Якщо ваші скрипти явно викликають iptables-legacy, може виникнути роздвоєння фаєрвола.

Рішення: Стандартизувати: обрати iptables-nft (звично для Debian/Proxmox), якщо немає вагомої причини інакше.

Завдання 5: Перегляньте ruleset nftables (реальне джерело істини на nft-хостах)

cr0x@server:~$ nft list ruleset | sed -n '1,80p'
table inet filter {
  chain input {
    type filter hook input priority 0; policy accept;
    ct state established,related accept
    iifname "lo" accept
  }
  chain forward {
    type filter hook forward priority 0; policy accept;
  }
}

Що це означає: У вас мінімальна таблиця inet filter з політикою accept. Якщо Proxmox фаєрвол «увімкнено», але ви не бачите Proxmox-генерованих ланцюгів/таблиць, або Proxmox не застосовує правила до nftables, або інший інструмент їх видалив.

Рішення: Якщо правила Proxmox відсутні — підтвердіть, чи Proxmox налаштовано використовувати nftables/iptables правильно і чи якийсь конкурент не замінює ruleset.

Завдання 6: Перевірте правила iptables (але впевніться, який бекенд ви бачите)

cr0x@server:~$ iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Що це означає: Це саме по собі мало що показує. На iptables-nft це сумісний вигляд. Якщо він пустий, а nft показує правила, ви, мабуть, змішуєте інструменти або дивитесь на неправильну сім’ю таблиць.

Рішення: Використовуйте nft для авторитетної інспекції, якщо ваш iptables під капотом — nft. Застосовуйте iptables-legacy лише якщо ви спеціально стандартизувалися на legacy (рідко й проблематично).

Завдання 7: Перевірте, чи iptables-legacy також заповнений (виявлення роздвоєння)

cr0x@server:~$ iptables-legacy -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT

Що це означає: Якщо legacy показує Proxmox-ланцюги, а nft не показує — або навпаки — у вас невідповідність бекендів. Трафік слідуватиме активним правилам ядра, а не вашій улюбленій історії.

Рішення: Узгодьте альтернативи і змусьте pve-firewall перевстановити правила. Видаліть правила іншого бекенду, щоб уникнути плутанини.

Завдання 8: Підтвердіть наявність модулів ядра і sysctl для фільтрації мостів

cr0x@server:~$ lsmod | grep br_netfilter || true
br_netfilter           32768  0
bridge                311296  1 br_netfilter

cr0x@server:~$ sysctl net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

Що це означає: Містовий трафік проходитиме через Netfilter-хуки, що дозволяє хостовому фаєрволу фільтрувати трафік ВМ на мостах.

Рішення: Якщо ці значення 0, містовий трафік може обходити очікувані хуки. Вирішіть, чи хочете ввімкнути фільтрацію мостів (зазвичай потрібно для фаєрволінгу ВМ) і встановіть це стійко.

Завдання 9: Підтвердіть, які інтерфейси і мости несуть трафік

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33
tap100i0         UP             fe:1a:2b:3c:4d:5e

Що це означає: Якщо ваше правило застосовано до vmbr1, а трафік іде через vmbr0, правило «нічого не робить», бо воно ніколи не бачить пакетів.

Рішення: Намалюйте шлях сервісу: клієнт → фізичний NIC → міст → tap/veth → гість. Фільтруйте на правильному кордоні.

Завдання 10: Використайте лічильники, щоб довести, що правило спрацьовує (nft)

cr0x@server:~$ nft -a list chain inet filter input
table inet filter {
  chain input { # handle 1
    type filter hook input priority 0; policy accept;
    ct state established,related accept # handle 2
    iifname "lo" accept # handle 3
  }
}

Що це означає: Якби існували Proxmox-генеровані правила, ви б бачили їх тут, бажано з лічильниками. Відсутність лічильників означає, що ви навіть не дивитесь у правильний ланцюг/таблицю або правила не встановлені.

Рішення: Якщо не можете знайти правило, припиніть тестувати трафік і почніть шукати, хто володіє ruleset-ом.

Завдання 11: Моніторинг змін правил у реальному часі (упіймайте винуватця)

cr0x@server:~$ watch -n 1 'nft list ruleset | sha256sum | cut -d" " -f1'
3b26b25bbf6b613c6b6be8e5d2f1c8d0f50e3b0c6c1b86e3e9c6a2d4b9c7e012

Що це означає: Якщо хеш змінюється кожні кілька секунд або відразу після застосування правил Proxmox, щось інше переписує ruleset.

Рішення: Ідентифікуйте і відключіть конкурентного менеджера або інтегруйте його правильно. «Два контролери» — не архітектурний патерн.

Завдання 12: Виявлення інших менеджерів фаєрвола та писачів правил

cr0x@server:~$ systemctl list-unit-files | egrep 'ufw|firewalld|nftables|docker|kube|netfilter' || true
docker.service                         enabled
nftables.service                       enabled
pve-firewall.service                   enabled

Що це означає: Якщо nftables.service увімкнено і завантажує власний /etc/nftables.conf, він може заміняти бажаний стан Proxmox залежно від порядку запуску та конфігурації.

Рішення: Або дозвольте Proxmox бути власником (звично на PVE-хостах), або зробіть nftables.service сумісним і переконайтеся, що він не очищує/не замінює таблиці, від яких залежить Proxmox.

Завдання 13: Перевірте, чи nftables.service очищає правила при перезавантаженні

cr0x@server:~$ sed -n '1,120p' /etc/nftables.conf
#!/usr/sbin/nft -f

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;
  }
}

Що це означає: flush ruleset — це повне витрошення. Якщо це виконується після pve-firewall, ваші Proxmox-правила «не застосовуються», бо їх видалили.

Рішення: Приберіть повне очищення, або відключіть nftables.service, або інтегруйте Proxmox-управляємі таблиці явно. Не запускайте два конкурентні «авторитарні» конфіги.

Завдання 14: Переконайтесь, що конфігурація кластерної файлової системи Proxmox відповідає очікуванням

cr0x@server:~$ grep -R "enable:" -n /etc/pve/firewall | head
/etc/pve/firewall/cluster.fw:2:enable: 1
/etc/pve/firewall/server.fw:2:enable: 1

Що це означає: Прапорці увімкнення фаєрвола зберігаються в конфігу кластера. Але локальні особливості вузла (альтернативи, сервіси, sysctl) все ще можуть відрізнятися і викликати непослідовне застосування.

Рішення: Якщо лише один вузол поводиться неправильно — порівняйте вибір бекенду та інші сервіси на цьому вузлі спочатку, а не GUI-конфіг.

Завдання 15: Перевірте conntrack для ситуацій «правило ніби ігнорується»

cr0x@server:~$ conntrack -L 2>/dev/null | head
tcp      6 431999 ESTABLISHED src=10.10.10.50 dst=10.10.10.21 sport=51522 dport=443 src=10.10.10.21 dst=10.10.10.50 sport=443 dport=51522 [ASSURED] mark=0 use=1

Що це означає: Встановлені потоки можуть продовжувати проходити, якщо ваші правила рано допускають established connections (це звично і правильно).

Рішення: Для тесту відкрийте абсолютно нове з’єднання з іншого джерела або очистіть конкретні записи conntrack (більш вибірково, ніж повне видалення всього).

Завдання 16: Очистіть конкретний conntrack-потік (судовий тест)

cr0x@server:~$ conntrack -D -p tcp --orig-src 10.10.10.50 --orig-dst 10.10.10.21 --dport 443
1 flow entries have been deleted.

Що це означає: Тепер новий SYN має пройти через ваші поточні правила. Якщо блок працює лише після цього, правила були правильними; ваш тест — ні.

Рішення: Скоригуйте метод валідації і подумайте, чи потрібно явно скидати/блокувати встановлені потоки під час інцидентів безпеки.

Завдання 17: Перевірте, чи політика маршрутизації/VRF не обходить очікуваний інтерфейс

cr0x@server:~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

Що це означає: Якщо тут є додаткові правила, трафік може обирати інший egress-шлях, ніж ви очікуєте, що змінює, які правила фаєрвола релевантні (особливо для OUTPUT і FORWARD).

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

Три міні-історії з корпоративного життя (анонімізовані, точні, трохи болючі)

Міні-історія 1: Інцидент через помилкове припущення

Середня компанія мала кластер Proxmox, що підтримував внутрішні інструменти: CI-ранери, сховище артефактів і кілька «тимчасових» ВМ, які були тимчасовими ще з минулого фінансового року. Під час аудиту безпеки виявили, що кілька ВМ були доступні на портах, де не мали б бути. Інфра команда відреагувала швидко: увімкнули фаєрвол Proxmox на рівні datacenter, застосували дефолтний deny для підмережі ВМ і пропустили лише SSH із jump box.

Вони тестували за допомогою iptables -S і бачили очікувані ланцюги. Чудово. Запустили порт-скан і все одно бачили відкриті порти. Не добре. З упевненістю оголосили, що фаєрвол Proxmox «не працює надійно» і відкотили зміни.

Помилкове припущення: вони читали iptables-legacy, а фактичне фільтрування житло в nftables. Хост був оновлений на місці. Деякі ранні скрипти зафіксували legacy-інструменти, і з часом вузол зайшов у роздвоєння: legacy-таблиці містили «правильні» правила, nftables був фактично дозволяючим, а живий трафік слідував за hooks nftables. Їхня «верифікація» перевірила мертву мову.

Після стандартизації альтернатив на iptables-nft, відключення legacy-скриптів і примусового перевстановлення pve-firewall, фаєрвол поводився ідеально — бо він і раніше працював. Інцидент був не в глюку Proxmox, а в тому, що вони дивились не на той control plane і довіряли своїй помилковій перевірці.

Стійке виправлення було нудне: перевірка bootstrap вузла, що не пропускає збірку, якщо альтернативи iptables відрізняються в кластері. Ця проста міра запобігла повторенню тієї ж драми під час наступного оновлення.

Міні-історія 2: Оптимізація, що відбилася боком

Інша організація тримала мульти-орендні dev-середовища на Proxmox. Вони хотіли «швидше застосування фаєрвола», бо девелопери скаржились, що створення ВМ триває довго. Хтось помітив, що pve-firewall часто перевстановлює багато правил, особливо при частих змінах конфігурації. «Оптимізація»: ввести базову nftables-конфіг з flush ruleset і мінімальним allowlist, а потім дозволити Proxmox додавати свої таблиці після.

В лабораторії це виглядало чисто. У продакшені це створило гонки: nftables.service перезавантажувався під час мережевих подій і витрушував ruleset. Proxmox врешті-решт знову застосовував правила, але «врешті-решт» — це не контроль безпеки. Між очисткою і повторним застосуванням ВМ тимчасово були відкриті. Не години, але достатньо, щоб логи стали неприємними і аудитори висловилися.

Проблема була не тільки в очищенні. Проблема — в наявності двох конкурентів за право істини над одним ядровим об’єктом. nftables.service вважав, що воно володіє істинною конфігурацією. Proxmox вважав те саме. Ядро виконувало ту правду, яка була останньою записаною.

Команда повернулась до моделі з одним власником: Proxmox генерує стан фаєрвола; nftables.service відключено; будь-яке базове жорстке налаштування хоста виражено як правила datacenter/node Proxmox. «Швидке застосування» досягли шляхом зменшення непотрібної частоти змін (менше per-VM мікро-правил, більше множин і груп) а не створення другого control plane.

Урок: якщо ваша оптимізація базується на очищенні живого ruleset, ви не оптимізували — ви додали азартну гру з непотрібними кроками.

Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію

Регульована компанія тримала три Proxmox-кластери з ідентичними ролями. Вони мали політику змін: перед увімкненням фаєрвола глобально вони переходили в режим «лише логування», перевіряли лічильники, а потім вже затверджували блокування. Люди бурчали, що це повільно і бюрократично. Але саме це запобігло нічному інциденту.

У стейджингу вони помітили тонку річ: трафік ВМ-до-ВМ на тому ж мосту не потрапляв у очікуваний фільтр на одному кластері. Лічильники не рухалися. Логів про блокування не було. Правила були — але не стосувалися трафіку.

Оскільки вони виміряли перш ніж примусити, виявили, що sysctl br_netfilter був вимкнений на тому кластері. Доброзичливий профіль налаштувань ядра вимкнув bridge netfilter роками тому, щоб «зменшити накладні витрати». Накладні витрати були реальні. Так само був обхід безпеки.

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

Поширені помилки: симптом → корінна причина → виправлення

• Симптом: GUI Proxmox показує фаєрвол увімкненим; трафік не блокується.
  Корінна причина: Правила застосовані в nftables, а ви інспектуєте iptables-legacy (або навпаки).
  Виправлення: Стандартизувати альтернативи (рекомендується iptables-nft), потім перезапустити pve-firewall і перевірити nft list ruleset.
• Симптом: Правила застосовуються, а потім зникають через кілька хвилин або після мережевого перезавантаження.
  Корінна причина: nftables.service завантажує /etc/nftables.conf з flush ruleset, або інший менеджер переписує таблиці.
  Виправлення: Вимкнути конкурента або видалити поведінку flush/replace; обрати єдиного власника ruleset.
• Симптом: Правила ВМ не впливають на трафік ВМ-до-ВМ на тому ж мосту.
  Корінна причина: Sysctl-налаштування bridge netfilter вимкнені (net.bridge.bridge-nf-call-iptables=0).
  Виправлення: Увімкнути br_netfilter і sysctl стійко; повторно протестувати з лічильниками/логами.
• Симптом: «Я заблокував порт X, але моя сесія все ще відкрита».
  Корінна причина: Conntrack дозволяє встановлені потоки; ваше правило впливає лише на нові з’єднання.
  Виправлення: Тестуйте новими з’єднаннями, або очистіть конкретні записи conntrack, або змініть порядок правил, якщо треба примусово розірвати існуючі з’єднання.
• Симптом: Лише один вузол у кластері застосовує правила; інші — ні.
  Корінна причина: Дрейф вузлів: різні альтернативи (legacy vs nft), різні sysctl, різні сервіси увімкнені.
  Виправлення: Порівняйте вузли: альтернативи, sysctl, завантажені модулі, увімкнені сервіси; стандартизувати через конфігураційний менеджмент.
• Симптом: NAT/порт-форварди поводяться по-різному після увімкнення фаєрвола.
  Корінна причина: Змішання таблиць NAT iptables/nft; docker або інші компоненти вставляють NAT-переспрямування; відрізнення в порядку застосування.
  Виправлення: Консолідуйте власність NAT; інспектуйте nft nat table і переконайтесь, що правила Proxmox не конфліктують з рантаймами контейнерів.
• Симптом: Доступ до управління хостом випадково блокується.
  Корінна причина: Застосували «deny inbound» на рівні datacenter без явних allow для SSH/GUI/кластерного/збережувального трафіку, або застосували на неправильний інтерфейс.
  Виправлення: Завжди стадіруйте в режимі лише логування; додайте явні дозволи для plane управління перш ніж примусово блокувати; перевірте прив’язки інтерфейсів.
• Симптом: Логи фаєрвола показують дропи, але трафік все одно проходить.
  Корінна причина: Ви логували один шлях (наприклад INPUT), а трафік пішов через FORWARD/містовий шлях, або IPv6 йде іншим шляхом.
  Виправлення: Визначте фактичний хук з інтерфейсом і напрямком; перевірте правила для inet family; переконайтеся, що IPv6 також під контролем, якщо він використовується.

Чек-листи / покроковий план

Чек-лист A: Стандартизувати вузол Proxmox на один бекенд фаєрвола

1. Оберіть бекенд: у сучасному Proxmox/Debian оберіть iptables-nft/nftables, якщо немає вимог від вендора до legacy.
2. Перевірте альтернативи для iptables/ip6tables/ebtables/arptables.
3. Видаліть або відключіть скрипти, що викликають лише iptables-legacy.
4. Вимкніть конкуруючі менеджери фаєрвола (ufw/firewalld), якщо їх не інтегровано свідомо.
5. Перезапустіть pve-firewall і перевірте активні правила через nft.

Чек-лист B: Підтвердіть, що трафік ВМ справді потрапляє в netfilter

1. Підтвердіть шлях через міст: трафік використовує vmbrX і очікувані tap/veth пристрої.
2. Переконайтеся, що модуль br_netfilter завантажено.
3. Увімкніть sysctl bridge для iptables/ip6tables, якщо покладаєтесь на фільтрацію на хості для містового трафіку.
4. Використовуйте лічильники/логування, щоб довести, що пакети збігаються з правилами.

Чек-лист C: Тестуйте зміни фаєрвола без самообману

1. Використовуйте нове TCP-з’єднання (новий джерельний порт) або іншого клієнта.
2. Перевірте лічильники для конкретного правила/ланцюга.
3. За потреби видаліть конкретні записи conntrack для чистого повторного тесту.
4. Перевіряйте поведінку і для IPv4, і для IPv6; «працює на v4» ≠ «безпечно».

Покроковий план відновлення (той, який я б виконав у продакшені)

1. Заморозити писачів правил: тимчасово зупиніть/відключіть не-Proxmox менеджери фаєрвола (nftables.service, ufw, firewalld), щоб запобігти зміні правил під час діагностики.
2. Підтвердити бекенд: перевірте update-alternatives --display iptables і узгодьте nft vs legacy на всіх вузлах.
3. Проінспектувати активний ruleset: використайте nft list ruleset і переконайтеся, що Proxmox-генеровані структури присутні і лічильники інкрементуються під час тесту.
4. Виправити видимість мостів: перевірте br_netfilter + sysctl і узгодьте їх із вашою моделлю фільтрації.
5. Заново вмикати лише необхідне: дозвольте Proxmox керувати станом фаєрвола; повторно вводьте інші інструменти лише якщо це строго необхідно і без перекриття.
6. Зафіксувати консистентність: закріпіть альтернативи/sysctl/увімкнення сервісів у конфігураційному менеджменті; додайте перевірку дрейфу у health-check вузла.

Питання та відповіді (FAQ)

1) Чому правила фаєрвола Proxmox «не застосовуються», хоч GUI показує увімкнено?

Тому що GUI — це інтерфейс конфігурації, а не ядро. Найпоширеніша причина — невідповідність бекенду: правила застосовані в nftables, а ви дивитесь legacy iptables, або інший сервіс очищає/перезаписує правила після Proxmox.

2) Чи кращий nftables за iptables для Proxmox?

Нині: так, операційно, бо це сучасний дефолт на Debian-подібних системах і він зменшує дрейф legacy-інструментів. Неправильна відповідь — «обидва», якщо вам подобається налагоджувати роздвоєні стекі правил.

3) Чи можуть iptables і nftables працювати одночасно?

На жаль, так. Можна мати iptables-legacy правила і nftables правила одночасно. Саме так виникає «бачу правило, але воно не працює». Оберіть один бекенд і стандартизуйтеся.

4) Як дізнатись, чи iptables використовує nftables під капотом?

Використайте update-alternatives --display iptables. Якщо воно вказує на /usr/sbin/iptables-nft, ваші команди iptables програмують правила сумісні з nftables.

5) Мій трафік ВМ-до-ВМ не фільтрується. Чи зламався Proxmox фаєрвол?

Зазвичай ні. Трафік ВМ-до-ВМ на тому ж мосту — це L2-перемикання. Якщо sysctl мостового netfilter вимкнено, netfilter не бачитиме ці пакети. Увімкніть br_netfilter і відповідні sysctl, якщо ваша модель безпеки покладається на фільтрацію на хості.

6) Чому блокування порту не розірвало існуючі сесії?

Conntrack. Багато правил допускають established,related ранньо для продуктивності і стабільності. Новий блок впливає на нові з’єднання. Тестуйте новим з’єднанням або видаляйте конкретні записи conntrack для чистої валідації.

7) Чи варто запускати nftables.service на хості Proxmox?

Якщо Proxmox фаєрвол — ваш авторитетний менеджер, зазвичай — ні. Запуск nftables.service з конфігом, який очищає або замінює правила, буде конфліктувати. Якщо його потрібно запустити, переконайтеся, що він не витрушує або не перезаписує Proxmox-таблиці і що порядок старту детермінований.

8) Чому на одному вузлі працює, а на іншому в тому ж кластері — ні?

Конфігурація кластера може бути ідентичною, але локальний стан вузла відрізняється: вибір альтернатив, увімкнені сервіси, sysctl, модулі ядра або сторонні агенти. Порівнюйте локальні налаштування вузла; не припускайте, що кластер робить усе однорідно.

9) Чи потрібно турбуватися про IPv6, якщо наша мережа «тільки IPv4»?

Якщо IPv6 увімкнено на інтерфейсах, сервіси можуть прив’язуватись до IPv6 і ставати доступними. Керуйте правилами IPv6 явно (рекомендовано) або вимкніть IPv6 навмисно і послідовно. «Ми не використовуємо IPv6» часто означає «ми не моніторимо IPv6».

Висновок: наступні кроки, що дійсно працюють

Коли правила фаєрвола Proxmox не застосовуються, ставтесь до цього як до будь-якої іншої виробничої проблеми: встановіть фактичний control plane, підтвердьте власність і доведіть шлях пакета лічильниками — не інтуїцією.

Практичні наступні кроки:

1. Вирішіть бекенд фаєрвола (nftables/iptables-nft — розумчий дефолт) і стандартизуйтесь з update-alternatives на всіх вузлах.
2. Зробіть Proxmox єдиним джерелом правди для фільтрації хоста/ВМ, якщо у вас немає ретельно спроєктованої причини ділити власність.
3. Аудит і видалення джерел змін правил: відключіть nftables.service/ufw/firewalld на PVE-хостах, якщо їх не інтегровано; слідкуйте за вставками правил від docker/kube.
4. Перевірте поведінку мостів через sysctl br_netfilter і реальні лічильники, особливо для трафіку ВМ-до-ВМ.
5. Покращіть тестування: нові з’єднання, обізнаність про conntrack і явна валідація IPv4/IPv6.

Зробіть це один раз, запишіть, і ваше майбутнє «я» не муситиме знову «відкривати» різницю між існуванням правила і його фактичним застосуванням.