Виправлення pve-firewall.service у Proxmox без блокування доступу

November 14, 2025 • February 3, 2026 • Читання: 5 хв • Views: 12

Було корисно?

Ваш хост Proxmox завантажився, віртуальні машини працюють, кластер виглядає нормально — але GUI починає тайм-аутити, SSH стає «рваним», і systemd виводить те саме повідомлення: pve-firewall.service failed. Інстинкт підказує перезапустити сервіс поки не заспокоїться. Саме так ви ризикуєте опинитись у датацентрі або просити когось із фізичним доступом до консолі.

Ось безпечний підхід: збережіть управлінський «парашут», знайдіть точне правило/конфіг, що зламалося, і відновіть firewall, не перетворюючи вузол на самозаподіяний DoS.

Що насправді робить pve-firewall (і чому він падає)

Firewall Proxmox VE (PVE) — це не «просто iptables». Це генератор правил та оркестратор, який читає конфігурацію з кількох рівнів (датацентр, вузол, VM), компілює це в набори правил, а потім встановлює їх на хості і, опційно, на бриджах/тап-пристроях для гостьових систем. Коли все працює — нудно й приємно. Коли падає — бувають дві групи проблем:

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

systemd реагує чітко: якщо допоміжні скрипти повертають ненульовий код, pve-firewall.service маркується як failed. Такий ненульовий код зазвичай спричинений синтаксичною помилкою (некоректний рядок правила), відсутньою залежністю (модулі ядра / бекенди xtables) або конфліктом (ваш власний менеджер nftables/iptables наступає на правила PVE).

Є причина, чому досвідчені оператори напружуються перед рестартами firewall: firewall — один з небагатьох компонентів, який може порушити єдиний шлях виправлення самого себе. Це типовий інженерний анекдот.

Одна максимума надійності варта уваги — ідея вільно перефразована від Gene Kim (автор про DevOps): «Малі безпечні зміни кращі за героїчні виправлення під тиском». Саме такий підхід тут: ізолюйте, перевірте, а потім застосуйте так, щоб зберегти доступ.

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

Якщо ви посеред інциденту, не починайте з «підгонки правил». Спочатку знайдіть, що саме зламалось і чи є у вас ще «мотузка безпеки».

По-перше: підтвердіть канали доступу

Чи є у вас OOB-консоль (IPMI/iDRAC/iLO) або фізичний доступ?
Чи є у вас відкритий SSH-сеанс, який можна зберегти?
Чи можна відкрити другий сеанс з іншої мережі (VPN, bastion) як запасний варіант?

По-друге: читайте помилку, не гадуйте

systemctl status pve-firewall — за останньою рядком помилки.
journalctl -u pve-firewall -b — повний журнал.
Перевірте конфігурації в /etc/pve/firewall/ на синтаксис, якщо логи кажуть про парсинг.

По-третє: визначте бекенд та конфлікти

iptables --version та update-alternatives --display iptables
Чи працює nftables? Чи встановлений ufw? Чи встановлений firewalld?

По-четверте: ізолюйте, що змінилося

Нещодавні оновлення? Ядро? Версія PVE?
Нещодавні правки у вкладках Firewall для Datacenter/Node/VM?
Якась автоматизація чіпала /etc/network/interfaces або /etc/pve?

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

Безпека перш за все: не блокуй себе

Коли firewall зламаний, ваша мета — не «максимальна безпека». Мета — «відновити контрольований зв’язок», щоб завершити ремонт. Це означає:

Залиште принаймні один root-сеанс відкритим (SSH або консоль) під час тестів.
Віддавайте перевагу консолі, якщо вона доступна. Вона не залежить від ваших правил firewall.
Плануйте зміни покроково і використовуйте таймер для відкату, коли це можливо.
Не перезавантажуйте бриджі мережа необережно, якщо не розумієте, як вузол несе трафік управління.

Короткий жарт №1: рестарт firewall — це як міняти колесо на автошляху: робіть це, але не дивуйтеся, якщо буде хвилювання.

Дві прагматичні безпечні схеми:

Схема A: «Два сеанси і таймер»

Відкрийте два root-сеанси. У сеансі №2 заплануйте відкат (відключити firewall або відновити відомий добрий конфіг) через 2–5 хвилин. У сеансі №1 робіть виправлення. Якщо втратите доступ — дочекайтеся відкату.

Схема B: «Консоль перш за все для ризикових кроків»

Якщо у вас є IPMI/iLO тощо, виконуйте ризикові операції (рестарт сервісу, застосування нових правил, зміна бридж-фільтрації) через консоль. Так ваш транспорт не залежить від того, що ви змінюєте.

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

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

Завдання 1: Підтвердити стан сервісу та останню рядок помилки

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled)
     Active: failed (Result: exit-code) since Fri 2025-12-26 10:13:02 UTC; 3min ago
    Process: 1462 ExecStart=/usr/sbin/pve-firewall start (code=exited, status=255/EXCEPTION)
   Main PID: 1462 (code=exited, status=255/EXCEPTION)

Dec 26 10:13:02 server pve-firewall[1462]: error parsing cluster firewall configuration: /etc/pve/firewall/cluster.fw line 42
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Main process exited, code=exited, status=255/EXCEPTION
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Failed with result 'exit-code'.
Dec 26 10:13:02 server systemd[1]: Failed to start Proxmox VE firewall.

Що це означає: помилка парсингу; зазвичай це опечатка або некоректний рядок правила у файлі .fw.

Рішення: Не перезапускайте знову. Перейдіть до перевірки згаданого файлу і номера рядка.

Завдання 2: Витягніть повний журнал за поточний завантаження

cr0x@server:~$ journalctl -u pve-firewall -b --no-pager -n 200
Dec 26 10:13:02 server pve-firewall[1462]: starting firewall
Dec 26 10:13:02 server pve-firewall[1462]: reading configs...
Dec 26 10:13:02 server pve-firewall[1462]: error parsing cluster firewall configuration: /etc/pve/firewall/cluster.fw line 42
Dec 26 10:13:02 server pve-firewall[1462]: stopping firewall (cleanup)
Dec 26 10:13:02 server pve-firewall[1462]: cleanup done
Dec 26 10:13:02 server systemd[1]: pve-firewall.service: Main process exited, code=exited, status=255/EXCEPTION

Що це означає: сервіс стартував, прочитав конфіг, а потім коректно вийшов після помилки. Cleanup вказує, що він намагався видалити часткові правила.

Рішення: Виправте конфіг. Якщо cleanup не відбувся, можливо, доведеться потім скинути пошкоджені правила.

Завдання 3: Перевірте, чи firewall ввімкнено на всіх рівнях

cr0x@server:~$ pve-firewall status
Status: stopped
Enabled: 1
Nodes:
  server: enabled=1
VMs:
  101: enabled=0
  102: enabled=1

Що це означає: Firewall глобально ввімкнено і на вузлі; наразі він зупинений через помилку.

Рішення: Якщо потрібно тимчасово «повернути доступ», відключіть на рівні датацентру/вузла (маючи підготовлену консоль). Інакше — виправте і перезапустіть.

Завдання 4: Перевірте стан кластерного файлового сховища (конфіги там)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Fri Dec 26 10:16:40 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2a
Quorate:          Yes

Що це означає: Кластер має кворум; /etc/pve має бути доступним для запису і консистентним.

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

Завдання 5: Швидко знайдіть проблемний рядок

cr0x@server:~$ nl -ba /etc/pve/firewall/cluster.fw | sed -n '35,55p'
    35  [OPTIONS]
    36  enable: 1
    37
    38  [RULES]
    39  IN ACCEPT -p tcp --dport 8006 -source +mgmt
    40  IN ACCEPT -p tcp --dport 22 -source +mgmt
    41  IN DROP -p tcp --dport 3306 -source 0.0.0.0/0
    42  IN ACCEPT -p tcp --dport abc -source +mgmt

Що це означає: --dport abc некоректний. Парсер PVE відхиляє його.

Рішення: Замініть на числовий порт або дійсний сервіс/аліас, якщо підтримується вашим стилем правил. Потім протестуйте знову.

Завдання 6: Перевірте, чи не зламали ви посилання на алиас/групу

cr0x@server:~$ grep -R --line-number -E '^\s*(group|alias):' /etc/pve/firewall
/etc/pve/firewall/cluster.fw:12:group: mgmt 10.10.0.0/24
/etc/pve/firewall/cluster.fw:13:alias: dns1 10.10.0.53

Що це означає: Ваша група/аліас існує. Якщо правило посилається на +mgmt, воно повинно розв’язуватися.

Рішення: Якщо група/аліас відсутній або має помилку в імені — виправте його, а не саму логіку правила.

Завдання 7: Подумайте про dry-run: які порти не можна ламати

cr0x@server:~$ ss -lntp | egrep '(:22|:8006|:5900|:3128|:5405|:5404|:60000)'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1120,fd=3))
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1408,fd=6))
LISTEN 0      128        127.0.0.1:3128      0.0.0.0:*    users:(("pveproxy",pid=1408,fd=9))
LISTEN 0      4096         0.0.0.0:5900      0.0.0.0:*    users:(("vncshell",pid=1550,fd=5))

Що це означає: Сервіси управління слухають. Firewall має дозволяти доступ вашим мережам управління до 22/8006 принаймні.

Рішення: Якщо ви явно не дозволяєте вашу підмережу(і) джерела, не перезапускайте firewall ще. Додайте спочатку правило allow.

Завдання 8: Перевірте, на якому бекенді працюєте — nftables чи legacy iptables

cr0x@server:~$ iptables --version
iptables v1.8.9 (nf_tables)

Що це означає: iptables працює з бекендом nf_tables. Це нормально, але змінює поведінку конфліктів і вигляд правил.

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

Завдання 9: Шукайте конфліктуючих менеджерів firewall

cr0x@server:~$ systemctl is-active nftables ufw firewalld 2>/dev/null
inactive
inactive
inactive

Що це означає: Немає активного сервісу, що конкурує за правила.

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

Завдання 10: Підтвердьте налаштування фільтрації бриджа (загальний важіль блокування)

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

Що це означає: Трафік через бридж проходить через iptables/nft правила. З PVE firewall ввімкненим це очікуване для фільтрації VM.

Рішення: Якщо ви не мали на меті фільтрувати бридж-трафік, ви можете ненавмисно фільтрувати шлях управління (залежно від топології). Перевірте, як management досягає хоста (прямий NIC vs бридж).

Завдання 11: Перевірте, чи не відсутні модулі ядра

cr0x@server:~$ lsmod | egrep 'br_netfilter|nf_tables|ip_tables|x_tables'
br_netfilter           32768  0
nf_tables             286720  1429 nft_chain_nat,nft_counter,nft_ct,nft_compat
x_tables               53248  9 xt_conntrack,iptable_filter,iptable_nat,xt_MASQUERADE,nft_compat,xt_tcpudp,xt_addrtype,xt_nat,xt_comment
ip_tables              32768  2 iptable_filter,iptable_nat

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

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

Завдання 12: Безпечно заплануйте відкат перед рестартом

cr0x@server:~$ at now + 3 minutes <<'EOF'
systemctl stop pve-firewall
echo "Rollback executed: stopped pve-firewall at $(date)" >> /root/pve-firewall-rollback.log
EOF
warning: commands will be executed using /bin/sh
job 7 at Fri Dec 26 10:23:00 2025

Що це означає: Ви запланували «мертву ручку». Якщо заблокуєте доступ — хост зупинить PVE firewall незабаром.

Рішення: Продовжуйте з рестартом/тестуванням. Якщо все гаразд — видаліть завдання: atrm 7.

Завдання 13: Перезапустіть firewall і підтвердіть, що він залишився активним

cr0x@server:~$ systemctl restart pve-firewall
cr0x@server:~$ systemctl is-active pve-firewall
active

Що це означає: Сервіс успішно запущений.

Рішення: Негайно перевірте, чи можете ви все ще дістатися по SSH і GUI з вашої мережі управління. Потім скасуйте завдання відкату.

Завдання 14: Перевірте, що правила існують і політика за замовчуванням не ворожа

cr0x@server:~$ iptables -S | sed -n '1,60p'
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N PVEFW-INPUT
-A INPUT -j PVEFW-INPUT
-A PVEFW-INPUT -p tcp -m tcp --dport 22 -s 10.10.0.0/24 -j ACCEPT
-A PVEFW-INPUT -p tcp -m tcp --dport 8006 -s 10.10.0.0/24 -j ACCEPT
-A PVEFW-INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A PVEFW-INPUT -i lo -j ACCEPT

Що це означає: Політика INPUT за замовчуванням — DROP (нормально для PVE firewall). Є явні дозволи для портів управління.

Рішення: Якщо політика DROP, але ви не бачите правил allow для вашої мережі джерел — зупиніться і виправте правила, перш ніж закривати робочий сеанс.

Завдання 15: Підтвердьте, що проксі GUI доступний з вашої клієнтської мережі

cr0x@server:~$ curl -k -m 2 -I https://127.0.0.1:8006/ | head
HTTP/1.1 200 OK
server: pve-api-daemon
content-type: text/html; charset=utf-8

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

Рішення: Протестуйте з хоста управління в тій же підмережі; якщо блоковано віддалено — перевірте відповідність IP джерела і шлях бридж/NIC.

Завдання 16: Якщо потрібно тимчасово відключити PVE firewall — робіть це чисто

cr0x@server:~$ pve-firewall stop
stopping firewall...
firewall stopped

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

Рішення: Використовуйте це лише для короткого вікна технічного обслуговування, щоб відновити правильний конфіг. Потім знову ввімкніть. «Тимчасово» має звичку ставати постійним.

Корінні причини, через які падає pve-firewall.service

Більшість збоїв зводиться до кількох категорій. Знати категорію — означає не бовтатися безцільно.

1) Синтаксичні помилки у файлах конфігурації PVE firewall

Це найпоширеніші та найпростіші для виправлення. Повідомлення про помилку часто одразу вказує на файл і рядок. Типові причини:

Нечисловий порт у --dport або --sport
Погана нотація CIDR
Невпізнаний макрос або опція
Копіпаста iptables-правил, які парсер PVE не сприймає дослівно
Приховані символи від «розумних лапок», вставлених з тикет-системи

Підказка: логи кажуть «error parsing … line N». Виправляєте рядок — рестартуете і все гаразд.

2) Конфлікти з управлінням nftables/iptables

PVE firewall очікує володіти певними ланцюгами і вставляти hook-и певним способом. Якщо інший сервіс скидає таблиці, змінює політики за замовчуванням або використовує ті самі імена ланцюгів, ви можете отримати часткову установку або неочікувану фільтрацію.

Іноді systemd не бачить помилки; ви просто втрачаєте трафік. Ще гірше — сервіс «активний», а відмова стає вашою проблемою у витонченішій формі.

3) Невідповідність ядра/модулів після оновлень

Менш поширено для стабільних вузлів PVE, але трапляється коли:

Ви оновили пакети ядра, але не перезавантажились (і змінились бекенди фаєрволу/шари сумісності).
Ви завантажились в старе ядро, в якому немає очікуваних netfilter-компонентів.
Ви використовуєте кастомне ядро або мінімальний набір модулів, а інструменти Proxmox очікують дефолти.

4) Фільтрація бриджа та плутанина з шляхом управління

Багато хостів Proxmox ставлять management IP на Linux-бридж (vmbr0), щоб хост і VM ділили uplink. З увімкненим bridge netfilter, трафік управління хоста може підпадати під ті самі правила, що і трафік VM. Це нормально — якщо ви це спланували. Якщо ні — легкий спосіб заблокувати себе.

Короткий жарт №2: якщо ваш management IP живе на бриджі, ви поклали власний SSH на американські гірки і назвали це «мережева архітектура».

5) Проблеми з поширенням конфігів у кластері

Конфіг PVE firewall зберігається під /etc/pve, що підкріплене кластерним файловим шаром (pmxcfs). Якщо pmxcfs не в захваті (диск заповнений, проблеми FUSE, стрибки часу, втрата кворуму), ви можете редагувати конфіги, які не застосовуються коректно або по-різному на вузлах.

6) Сюрпризи з IPv6

Навіть якщо ви «не використовуєте IPv6», система може це робити. GUI може слухати на IPv6, або клієнти можуть віддавати перевагу AAAA-записам. Якщо ви дозволяєте лише IPv4, а клієнти приходять по IPv6 — виглядає як випадкова відмова. Насправді — детерміністична плутанина.

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

1) Симптом: `pve-firewall.service` падає одразу з номером рядка

Корінна причина: Синтаксична помилка у /etc/pve/firewall/*.fw (cluster, node або VM конфіг).

Виправлення: Використовуйте journalctl -u pve-firewall -b і nl -ba, щоб знайти рядок. Видаліть/виправте некоректний токен (порти, CIDR, опції). Перезапустіть і підтвердіть активність.

2) Симптом: сервіс активний, але GUI/SSH недоступні з частини мереж

Корінна причина: Ви дозволили неправильну підмережу джерела (часто NAT-ований bastion, pool VPN або новий WAN-діапазон). Або дозволили лише IPv4, а клієнти приходять по IPv6.

Виправлення: Підтвердіть джерельні IP зі сторони клієнта і з логів. Розширте правило allow до правильного management-групи. Додайте еквівалентні IPv6-правила при потребі. Перевірте з iptables -S/ip6tables -S і з клієнта.

3) Симптом: рестарт firewall періодично ріже зв’язки кластера

Корінна причина: Порти Corosync не дозволені (або ви фільтруєте на невірному інтерфейсі). Proxmox clustering розмовляє багато і чутливий до втрат пакетів.

Виправлення: Дозвольте трафік кластера/вузол-в-вузол на правильних інтерфейсах. Якщо у вас розділені мережі для кластера і управління — тримайте правила окремо й явними. Перевіряйте з pvecm status і зробіть packet capture, якщо потрібно.

4) Симптом: трафік VM пропадає після увімкнення firewall на хості

Корінна причина: Bridge netfilter плюс FORWARD policy DROP без коректних правил для бриджів/VM. Або ви увімкнули firewall на VM і не дозволили потрібний egress/ingress.

Виправлення: Вирішіть, чи потрібна вам firewall-фільтрація на рівні VM. Якщо так — створіть правила для форвардингу і tap-інтерфейсів; тестуйте на одній VM першою. Якщо ні — вимкніть фільтрацію бриджа або firewall для VM і тримайте host INPUT правила сфокусованими на сервісах хоста.

5) Симптом: старт firewall не вдається після оновлення; помилки про xtables/nft

Корінна причина: Невідповідність бекендів (legacy vs nf_tables) або конфліктні налаштування альтернатив.

Виправлення: Перевірте iptables --version і статус update-alternatives. Виберіть бекенд свідомо і забезпечте, щоб інструменти відповідали очікуванням. Перезавантажте, якщо ядро/юзерспейс розійшлися.

6) Симптом: зміни в GUI не «прилипають», або різні вузли поводяться по-різному

Корінна причина: pmxcfs / проблеми кворуму, або ви редагували не той рівень (датацентр vs вузол vs VM).

Виправлення: Переконайтесь у кворумі, перевірте pvecm status. Перевірте, що ви редагуєте потрібну область. Якщо кворум нестабільний — не намагайтеся робити «операції з firewall» під час кластерної аварії.

7) Симптом: GUI доступний локально, але не віддалено, хоча INPUT правила виглядають коректно

Корінна причина: Маршрутизація/VRF зміни, reverse path filtering, або трафік управління приходить на інший інтерфейс, ніж ви очікували (bond, VLAN sub-interface, порт бриджа).

Виправлення: Перегляньте маршрути і адресацію інтерфейсів, потім перевірте відповідність інтерфейсних умов у правилах. Використовуйте ip route, ip -br a і підтверджуйте з tcpdump на інтерфейсі, який ви вважаєте активним.

Три міні-історії з корпоративного життя

Міні-історія 1: Аутейдж через хибне припущення

У середній компанії команда віртуалізації «посилила» правила Proxmox, дозволивши GUI (8006) і SSH (22) лише з management VLAN. Це розумно — якщо адміністратори справді приходять з management VLAN.

Хибне припущення було тонким: більшість адміністраторів підключалися через VPN, і пул VPN не входив у management VLAN. Bastion дійсно сидів в mgmt, але нова політика також блокувала вихідні з’єднання з цього bastion до деяких внутрішніх сервісів, тож люди почали заходити безпосередньо з ноутбуків по VPN. Ці з’єднання тепер були мертвими.

Інцидент мав особливий поворот: існуючі SSH-сеанси залишалися живими (ESTABLISHED), тож виглядало як «деякі люди можуть підключитись, а деякі ні». Це підживлювало дискусії про DNS, кеші браузера та балансувальник. Насправді firewall робив саме те, що його попросили.

Виправлення не полягало в «відкритті всього». Воно полягало в тому, щоб трактувати VPN-пул як повноцінне джерело управління, додати його до групи mgmt і перевірити з реального клієнта. Вони також додали у чекліст пункт «Підтвердити діапазон IP-адрес адміністраторів». Скучно. Ефективно.

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

Інша організація вирішила, що рестарти Proxmox firewall «займають забагато часу». Хтось оптимізував процес, додавши автоматизацію, яка скидає і перезавантажує правила напряму через nft замість використання pve-firewall. Час перезавантаження зменшився. Контроль над платформою погіршився.

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

Наслідки були не лише технічні: ніхто не почував відповідальності за поведінку. Команди звинувачували одна одну. Тим часом кластер мав періодичні fencing-іві через втрату пакетів corosync під час reload-ів.

Вони відкотили «хитрощі». Дозволили Proxmox знову володіти своїми ланцюгами, а автоматизація перейшла до перевірки PVE конфігів і виклику pve-firewall restart у контрольованих вікнах, вузол за вузлом. Повільніше, але стабільніше. У production сюрпризи — найдорожча фіча.

Міні-історія 3: Скучно, але правильно — і це врятувало

Велике підприємство з edge compute на Proxmox мало стандартну практику: будь-яка зміна firewall повинна включати таймований rollback job на самому вузлі та перевірений доступ до консолі перед зміною. Інженери бурчали — виглядало як формальність.

Одного разу інженер додав правило на рівні датацентру, щоб відкидати inbound на діапазон портів старого додатку — благі наміри, слабке тестування. Правило випадково збігалося ширше, ніж треба. Результат: SSH заблоковано з мережі інженера, і GUI перестав завантажуватись.

Інженер не панікував. Він зачекав. Через три хвилини rollback зупинив firewall сервіс, відновивши доступ. Потім він підключився, виправив правило, перевірив з захопленням пакетів і повторно застосував зміни з тією ж страховкою. Ніяких поїздок до датацентру, ніякого ранкового Slack-опери.

Ось сенс нудної процесності: вона не запобігає помилкам. Вона робить їх переживаними.

Контрольні списки / покроковий план

Це послідовність дій, яку я би виконав на реальному вузлі, коли pve-firewall.service падає або коли рестарт може вічко ваш доступ. Це суб’єктивно, бо невизначеність — джерело відмов.

Покроковий план: ремонт без блокування

Отримайте доступ до консолі, якщо можливо (IPMI/iLO або фізично). Якщо ні — відкрийте два SSH-сеанси і не закривайте їх.
Знімок поточного стану: збережіть systemctl status, journalctl і вивід iptables -S/nft list ruleset у файл під root для подальшого порівняння.
Перевірте, чи сервіс не стартує чи «старить, але блокує вас». Шлях виправлення різниться.
Прочитайте точну помилку з journalctl -u pve-firewall -b. Якщо вказує файл+рядок — виправляйте його перш за все. Не імпровізуйте.
Підтвердіть вимоги до доступу управління: визначте реальні IP-діапазони джерел (VPN-pools, bastions, admin subnets). Оновіть групи/аліаси firewall відповідно.
Заплануйте відкат з at (або тримайте консоль готовою). Завжди. Це ваш парашут.
Перезапустіть pve-firewall один раз. Якщо знову падає — повертайтесь до логів; не спамте рестартами.
Перевірте критичні порти (22/8006) з принаймні однієї адмін-мережі. Тестуйте з клієнта, не лише локально.
Підтвердіть стан кластера після застосування: pvecm status і слідкуйте за коросайк-нестабільністю.
Скасуйте відкат лише після підтвердження: видаліть job через atrm, задокументуйте зміну і заплануйте очищення тимчасових дозволів.

Чекліст: безпека перед зміною firewall

Консоль доступна перевірена (або два SSH-сеанси відкриті).
Відкат заплановано (at now + 3 minutes).
Є знімок відомого доброго конфігу (копія /etc/pve/firewall і виводів правил).
Мережі управління і VPN-пули ідентифіковані і є як алиаси/групи.
Порти кластера та вимоги до storage відомі (особливо у multi-NIC схемах).
Застосування зміни — на одному вузлі першочергово.

Чекліст: валідація після зміни

systemctl is-active pve-firewall показує active.
Віддалений SSH і GUI протестовані з реальних адмін-мереж.
Підключення VM перевірені, якщо увімкнена фільтрація бриджа/VM.
Нема нових помилок corosync; кластер лишається quorate.
Завдання відкату скасовано.

Цікаві факти та контекст

Це не просто тривіальність. Вони пояснюють, чому Proxmox firewall поводиться так, як поводиться, і чому виправлення інколи здаються нелогічними.

Proxmox зберігає конфіг firewall у кластерному файловому шарі (/etc/pve через pmxcfs). Це зручно — але означає, що «проблема з конфігом» може бути проблемою з кластером.
Linux переходив від iptables до nftables, але багато інструментів все ще «говорять iptables». Шар сумісності працює, доки хтось не буде покладатися на стабільність формату виводу.
Політики DROP за замовчуванням — нормальні для Proxmox firewall. Очікується явні дозволи для management, cluster і сервісів. Якщо ви звикли до «ACCEPT за замовчуванням», це здається агресивним.
Bridge netfilter існує, бо люди хотіли фільтрувати бридж-трафік (VM на Linux-бриджах). Це також означає, що ви можете випадково фільтрувати трафік хоста, якщо management живе на тому ж бриджі.
Conntrack робить відмови схожими на непослідовні. Відкриті сесії працюють, а нові зʼєднання падають — тому команди женуться за примарами.
Corosync чутливий до втрат пакетів і латентності. Рестарт firewall, що коротко блокує multicast/unicast, може виглядати як нестабільність вузла.
Важливість «володіння» правилами. Якщо PVE володіє ланцюгами — дозвольте йому це робити. Змішування оркестраторів (PVE + ufw + кастомні скрипти) приводить до важко відтворюваних багів.
IPv6 часто «працює випадково» поки не перестане. Сучасні клієнти можуть надавати перевагу IPv6, і сервіси Proxmox можуть слухати на ньому. Якщо ви цього явно не врахували — отримаєте дивні відгуки про доступ.

FAQ

1) Чому `pve-firewall.service` впав одразу після редагування правила в GUI?

Тому що GUI записує у файл .fw під /etc/pve/firewall, і сервіс парсить цей файл. Один некоректний токен може перешкодити компіляції правил і сервіс вийде з ненульовим кодом. Перевірте journalctl -u pve-firewall -b для файлу+рядка.

2) Чи можу я просто відключити firewall і рухатися далі?

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

3) Я перезапустив firewall і SSH помер. Який найшвидший відновлення?

Використайте OOB-консоль і зупиніть сервіс: systemctl stop pve-firewall або pve-firewall stop. Потім виправте правила allow для ваших адмін-мереж перед повторним стартом. Якщо у вас є запланований rollback — дочекайтеся його спрацювання.

4) Який backend використовує Proxmox firewall — nftables чи iptables?

Він використовує netfilter стек системи і відповідні інструменти. На сучасних Debian-подібних системах часто бачите iptables (nf_tables). Практичний висновок: не припускайте поведінку/формат legacy iptables у скриптах.

5) Чому існуючі SSH-сеанси виживають, коли нові не проходять?

Через connection tracking. Багато політик дозволяють ESTABLISHED,RELATED трафік. Відкриті сесії підпадають під це, а нові — ні. Тому «в мене працює» не є доказом.

6) Як зрозуміти, який обсяг firewall мене ламає (Datacenter vs Node vs VM)?

Почніть з логів для парсинг-помилок (вони вказують на файл). Для поведінкових проблем тимчасово відключайте по черзі один обсяг (краще через консоль) і спостерігайте. Правила на рівні датацентру найширші; на рівні вузла впливають на хост; VM-правила зачіпають трафік гостя (інколи і форвардинг, залежно від налаштування).

7) Чи потрібно дозволяти порти corosync у firewall?

Якщо PVE firewall примушує INPUT/FORWARD, так — принаймні для інтерфейсів, що використовуються для комунікації кластера. Якщо ви ізолювали трафік кластера у виділену мережу — тримайте allow тільки для цієї мережі.

8) Що робити, якщо підозрюю проблеми pmxcfs/kvorum у дивній поведінці конфігів firewall?

Перевірте pvecm status на кворум і впевніться, що можна читати/писати під /etc/pve. Якщо кворум втрачен, відновлення кворуму має пріоритет. Редагування конфігів у деградованому кластері призводить до невідповідностей.

9) Чи безпечно вручну скидати правила iptables/nft?

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

10) Чи варто ставити management IP Proxmox на бридж?

Це поширено і може бути нормально. Але коли management живе на бриджі, bridge netfilter і політики форварду входять в історію доступу хоста. Якщо хочете простіших сценаріїв відмов — виділений management NIC/VLAN, не пов’язаний з форвардингом VM, буде спокійнішим.

Висновок: наступні кроки, що не зашкодять

Безпечне виправлення pve-firewall.service failed рідко означає «просто спробувати ще раз». Це: прочитати лог, виправити точну помилку конфігу, і перезапустити один раз — під охороною відкату — переконуючись, що ви дозволяєте мережі, якими насправді користуються люди.

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

Витягніть journalctl -u pve-firewall -b і вирішіть всі помилки парсингу файлу/рядка.
Визначте правильну групу управління (включно з VPN-пулами і bastion) і явно дозволіть 22/8006 з неї.
Впровадьте звичку «таймер відкату» для змін firewall. Це здається параноїчним, поки не врятує вам годину.
Якщо у вас кластер — тестуйте зміни на одному вузлі і перевіряйте кворум після застосування.