Брандмауер Proxmox заблокував доступ: відновіть SSH та Web UI з консолі без паніки

November 4, 2025 • February 3, 2026 • Читання: 7 хв • Views: 7

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

Ви змінили правило брандмауера в Proxmox. Тепер Web UI не відповідає, SSH не працює, і у вас у животі ніби котиться кулька. Ви не «повністю впали». Ви просто локально недоступні — мов експонат у музеї.

Це посібник з відновлення через консоль для випадків, коли політика брандмауера Proxmox блокує ваш доступ до управління. Він написаний для людей, які експлуатують продуктивні системи: вам потрібен найшвидший безпечний шлях назад до SSH і порту 8006, і ви хочете зрозуміти, що пішло не так, щоб цього не повторити.

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

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

Перше: визначте, чи це брандмауер, служба чи мережа

Чи маєте ви доступ до машини через консоль? Якщо так — рухайтеся далі. Якщо ні — проблема вище по ланцюгу (консоль гіпервізора, IPMI/iLO/DRAC, фізичний доступ).
Чи працює мережа на хості? Перевірте стан лінку, IP-адресу, маршрут за замовчуванням. Якщо мережа несправна, брандмауер не є основною проблемою.
Чи працює стек управління Proxmox? Перевірте pveproxy (Web UI) і sshd (SSH). Якщо служби впали — спочатку лагодьте їх.

Друге: підтвердіть, що брандмауер дійсно активний

Перевірте, чи ввімкнено брандмауер Proxmox на рівні датацентру/вузла.
Перевірте, чи запущено pve-firewall і чи встановив він правила в nftables/iptables.

Третє: застосуйте відновлення з найменшим ризиком

Тимчасово зупиніть сервіс брандмауера Proxmox (systemctl stop pve-firewall), щоб відновити доступ, або
Введіть вузьке правило дозволу для SSH та 8006 з вашої IP-адреси(ів) адміністратора, потім перезавантажте брандмауер.

Четверте: перевірте зовні, потім правильно виправте політику

Перевірте SSH і Web UI з відомої хост-машини адміністратора.
Перегляньте набір правил, який спричинив блокування (датацентр проти вузла проти VM, вхідні проти вихідних, область інтерфейсу).
Реалізуйте постійну стратегію «дозволів для управління», а не купу тимчасових винятків.

Чесно: якщо ви не впевнені, яке правило неправильне — перестаньте гадати. Вимкніть брандмауер, відновіть доступ, а потім виправляйте правила при світлі дня.

Як насправді працює брандмауер Proxmox (частини, які важливі під час простою)

Proxmox VE має функцію брандмауера, інтегровану в UI, яка накладається на рівні:

Датацентр правила: глобальні для всіх вузлів (політика в масштабі кластера).
Вузол правила: специфічні для хоста, часто для доступу до консолі управління.
VM/CT правила: застосовуються до гостей (корисно, але не для цієї аварії).

Під капотом Proxmox програмує файл-стен для брандмауера через сервіс pve-firewall. Залежно від дистрибутива/версії ядра, правила потрапляють у nftables або в сумісний шар iptables. Під час блокування вам важливі дві речі:

Політика за замовчуванням: політика input може фактично стати «drop, якщо не дозволено», щойно брандмауер увімкнено з дефолтним deny.
Порти управління: SSH (зазвичай 22) і Proxmox Web UI (8006/TCP через pveproxy).

Брандмауер Proxmox — не чаклунство, але так здається, коли він блокує вас, а ви дивитесь у консоль. Ваше відновлення ґрунтується на розумінні того, що:

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

Одна ідея надійності, перефразована від John Allspaw: Інциденти часто є наслідком нормальної роботи і локальних рішень, які в певний момент здавалися правильними. Ставтеся до свого блокування як до інциденту. Так ви виправите його швидше і навчитеся більше.

Цікаві факти та історичний контекст (щоб мозок перестав гадати)

Порт 8006 — це стандартний порт Web UI Proxmox; він не «особливий», але його легко заблокувати одним поганим правилом.
Proxmox VE базується на Debian, отже ваш інструментарій порятунку — класичний Linux: systemd, journalctl, iproute2 та nftables/iptables.
Фаєрволи в Linux розвивалися: iptables панував роками; nftables — сучасна заміна, але шари сумісності можуть плутати вивід під час аварій.
Станні (stateful) фаєрволи (conntrack) означають, що правила «allow established/related» можуть зберегти існуючі сесії, тоді як нові — блокуються; тому ваш поточний SSH може вижити, коли інші вже мертві.
Політика drop за замовчуванням безпечніша за allow, але тільки якщо ви попередньо дозволили управління. Безпека любить «deny by default». Операції люблять «не заблокувати хост». Можна мати обидва.
Пропагування конфігурації кластера — це посилювач: робить зміни консистентними і помилки теж консистентними.
Доступність Web UI залежить від pveproxy і TLS; блок брандмауера виглядає ідентично мертвому проксі зі сторони браузера.
Зовнішні консолі (IPMI/iLO/DRAC) існують тому, що мережі ламаються і люди неправильно їх налаштовують; «доступ до консолі» — не розкіш.
UI-абстракції брандмауера корисні, поки вони не приховують порядок правил і збіг інтерфейсів — тоді ви жорстко вчитеся, що «просто» має краї випадків.

Отримайте реальну консоль (ні, не ту напівробочу SSH вкладку)

Коли Proxmox блокує вас, потрібен локальний доступ. Варіанти, у порядку здорового глузду:

IPMI/iLO/DRAC/KVM консоль: найкраще для віддаленого відновлення. Використовуйте її.
Фізична консоль: crash cart, монітор, клавіатура. Старомодно, але працює.
Консоль провайдера: якщо у хостингу — використайте їхній «VNC/Serial console». Прийміть недосконалість.

Потрапивши в консоль, уникайте хаотичних правок. Не починайте випадково редагувати всі конфіги, які знайдете. Виділіть 90 секунд, щоб підтвердити: мережа, служби, брандмауер. Потім дійте.

Жарт №1: Брандмауер не «зламався». Він просто вирішив мати чіткі особисті кордони.

Завдання з консолі для відновлення (команди, виводи та рішення)

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

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

cr0x@server:~$ hostnamectl
 Static hostname: pve-01
       Icon name: computer-server
         Chassis: server
      Machine ID: 2f5c0c0d3f3a4d44a1f8b3a2f0d0c111
         Boot ID: 7c2b3a7d2c3a4bdabf9dd0f66e1b2222
Operating System: Debian GNU/Linux 12 (bookworm)
          Kernel: Linux 6.2.16-20-pve
    Architecture: x86-64

Що це означає: Ви на тому вузлі, який думали, і він запускає kernel Proxmox.

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

Завдання 2: Перевірте лінк і IP-адресацію (базова мережна перевірка)

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
enp3s0           UP             3c:ec:ef:12:34:56
vmbr0            UP             3c:ec:ef:12:34:56

cr0x@server:~$ ip -br addr show vmbr0
vmbr0            UP             10.20.30.11/24 fe80::3eec:efff:fe12:3456/64

Що це означає: Міст (bridge) увімкнений і має IP для управління.

Рішення: Якщо інтерфейс DOWN або IP відсутній — спочатку лагодьте мережу (невірний VLAN, кабель, bond, конфіг bridge). Зміни брандмауера не допоможуть, якщо хост не має IP.

Завдання 3: Підтвердіть маршрут за замовчуванням і доступ до шлюзу

cr0x@server:~$ ip route
default via 10.20.30.1 dev vmbr0 proto kernel onlink
10.20.30.0/24 dev vmbr0 proto kernel scope link src 10.20.30.11

cr0x@server:~$ ping -c 2 10.20.30.1
PING 10.20.30.1 (10.20.30.1) 56(84) bytes of data.
64 bytes from 10.20.30.1: icmp_seq=1 ttl=64 time=0.401 ms
64 bytes from 10.20.30.1: icmp_seq=2 ttl=64 time=0.388 ms

--- 10.20.30.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1021ms
rtt min/avg/max/mdev = 0.388/0.394/0.401/0.006 ms

Що це означає: Базова L2/L3 зв’язність є. Можна, ймовірно, відновити управління без запуску перезаливки мережі в голові.

Рішення: Якщо пінг до шлюзу не проходить — шукайте проблеми з trunk VLAN, портом bridge, статусом bond або конфігом upstream-комутатора. Знову: не звинувачуйте брандмауер одразу.

Завдання 4: Перевірте, чи служби SSH і Web UI працюють

cr0x@server:~$ systemctl status ssh --no-pager
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/lib/systemd/system/ssh.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 08:14:21 UTC; 1h 22min ago
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 1123 (sshd)
      Tasks: 1 (limit: 154000)
     Memory: 6.2M
        CPU: 210ms

cr0x@server:~$ systemctl status pveproxy --no-pager
● pveproxy.service - PVE API Proxy Server
     Loaded: loaded (/lib/systemd/system/pveproxy.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 08:13:58 UTC; 1h 23min ago
   Main PID: 1055 (pveproxy)
      Tasks: 4 (limit: 154000)
     Memory: 154.8M
        CPU: 1.934s

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

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

Завдання 5: Переконайтесь, що служби слухають очікувані порти локально

cr0x@server:~$ ss -lntp | egrep '(:22|:8006)\s'
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=1123,fd=3))
LISTEN 0      4096         0.0.0.0:8006      0.0.0.0:*    users:(("pveproxy",pid=1055,fd=6))

Що це означає: Хост приймає з’єднання на 22 і 8006. Якщо зовнішні клієнти не підключаються — пакети фільтруються або маршрутизуються неправильно.

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

Завдання 6: Доведіть, що брандмауер блокує, за допомогою локального curl

cr0x@server:~$ curl -kI https://127.0.0.1:8006/
HTTP/1.1 200 OK
server: pve-api-daemon/3.0
content-type: text/html; charset=UTF-8
cache-control: max-age=0

Що це означає: Web UI працює локально. Симптом «недоступний» — то шлях у мережі або брандмауер, а не сам pveproxy.

Рішення: Перейдіть до перевірки брандмауера та відкату.

Завдання 7: Перевірте увімкнення брандмауера Proxmox під час виконання (сервіс + стан)

cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 09:01:12 UTC; 36min ago
   Main PID: 2289 (pve-firewall)
      Tasks: 1 (limit: 154000)
     Memory: 19.7M
        CPU: 4.311s

Що це означає: Брандмауер Proxmox активний і керує правилами.

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

Завдання 8: Подивіться логи брандмауера на предмет drop-повідомлень (це економить здогади)

cr0x@server:~$ journalctl -u pve-firewall --since "30 min ago" --no-pager | tail -n 20
Dec 26 09:19:10 pve-01 pve-firewall[2289]: status update OK
Dec 26 09:19:10 pve-01 pve-firewall[2289]: compile new ruleset
Dec 26 09:19:11 pve-01 pve-firewall[2289]: firewall update successful

cr0x@server:~$ journalctl -k --since "30 min ago" --no-pager | egrep -i 'PVEFW|DROP|REJECT' | tail -n 10
Dec 26 09:28:03 pve-01 kernel: PVEFW-DROP-IN: IN=vmbr0 OUT= MAC=3c:ec:ef:12:34:56 SRC=10.20.30.50 DST=10.20.30.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22222 DF PROTO=TCP SPT=51234 DPT=8006 WINDOW=64240 SYN
Dec 26 09:28:08 pve-01 kernel: PVEFW-DROP-IN: IN=vmbr0 OUT= MAC=3c:ec:ef:12:34:56 SRC=10.20.30.50 DST=10.20.30.11 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=22223 DF PROTO=TCP SPT=51235 DPT=22 WINDOW=64240 SYN

Що це означає: Логи ядра показують, що ваш хост-адмін (10.20.30.50) відкидається на портах 8006 і 22. Це явна вказівка на проблему.

Рішення: Застосуйте аварійний allow (якщо можете бути точними) або зупиніть pve-firewall (швидше).

Завдання 9 (найшвидше): Зупиніть Proxmox брандмауер, щоб негайно відновити доступ

cr0x@server:~$ systemctl stop pve-firewall

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

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

Рішення: Спробуйте SSH/Web UI з вашої адміністративної машини зараз. Якщо доступ повернувся — ви підтвердили корінну причину. Далі: виправте правила правильно, а потім увімкніть брандмауер назад.

Завдання 10: Якщо доступ не повернувся — перевірте nftables/iptables напряму

Іноді інші інструменти, кастомні скрипти або залишкові набори правил залишаються. Перевірте, що реально завантажено.

cr0x@server:~$ nft list ruleset | head -n 40
table inet filter {
	chain input {
		type filter hook input priority filter; policy accept;
		ct state established,related accept
		iif "lo" accept
	}
}

Що це означає: Мінімальний набір nftables з політикою input accept. Якщо ви бачите це, то фільтрація ймовірно не відбувається на рівні nft.

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

cr0x@server:~$ iptables -S | head -n 30
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Що це означає: iptables дозволяє трафік. Якщо ви все ще заблоковані — підозрюйте маршрутизацію, rp_filter, upstream ACL або невірний IP.

Рішення: Продовжуйте перевірку з’єднання і перевірку upstream.

Завдання 11 (хірургічно): Тимчасово дозвольте SSH і 8006 з вашого IP через nftables

Якщо потрібно зберегти режим default-drop під час відновлення, додайте вузький дозвіл для вашої робочої станції або bastion. Припускається, що nftables активний на вузлі.

cr0x@server:~$ nft add table inet emergency
cr0x@server:~$ nft 'add chain inet emergency input { type filter hook input priority -50; policy accept; }'
cr0x@server:~$ nft add rule inet emergency input ip saddr 10.20.30.50 tcp dport {22,8006} accept
cr0x@server:~$ nft list table inet emergency
table inet emergency {
	chain input {
		type filter hook input priority -50; policy accept;
		ip saddr 10.20.30.50 tcp dport { 22, 8006 } accept
	}
}

Що це означає: Ви створили ланцюг «emergency» високого пріоритету, який приймає трафік управління з однієї IP-адреси до того, як інші ланцюги можуть відкинути його.

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

Завдання 12: Перевірте конфігураційні файли брандмауера Proxmox (знайдіть правило, що нашкодило)

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

cr0x@server:~$ sed -n '1,120p' /etc/pve/firewall/cluster.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN DROP -p tcp --dport 8006 -log nolog

Що це означає: Усього кластера політика input — DROP і є явний DROP для 8006. Ось як ви «ввічливо» заблокували UI у масштабі кластера.

Рішення: Видаліть поганий DROP, додайте allowlist для вашої адміністративної підмережі і збережіть policy_in DROP, якщо це ваша безпекова політика. Просто не забороняйте власну площину управління.

Завдання 13: Додайте правильне правило allow у брандмауері Proxmox (бажане постійне виправлення)

Приклад: дозволити управління з підмережі адміністраторів на вузол.

cr0x@server:~$ sed -n '1,120p' /etc/pve/firewall/pve-01.fw
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT

[RULES]
IN ACCEPT -source 10.20.30.0/24 -p tcp -dport 22 -log nolog
IN ACCEPT -source 10.20.30.0/24 -p tcp -dport 8006 -log nolog
IN ACCEPT -p icmp -log nolog

Що це означає: На вузлі є явні дозволи для SSH і Web UI з вашої адміністративної підмережі, водночас все інше вхідне за замовчуванням відкидається.

Рішення: Якщо ваша підмережа адміністратора не заслуговує довіри — замініть її на IP bastion або діапазон VPN. «0.0.0.0/0 може керувати моїм гіпервізором» — це не стратегія безпеки.

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

cr0x@server:~$ systemctl start pve-firewall
cr0x@server:~$ systemctl status pve-firewall --no-pager
● pve-firewall.service - Proxmox VE firewall
     Loaded: loaded (/lib/systemd/system/pve-firewall.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-26 10:02:13 UTC; 2s ago
   Main PID: 9912 (pve-firewall)

cr0x@server:~$ pve-firewall compile
status: ok

Що це означає: Сервіс активний; правила компілюються без помилок.

Рішення: Якщо compile падає — брандмауер може відкотитися або застосуватися частково. Виправте синтаксис перш ніж довіряти йому. «Напівзастосований» фаєрвол — це шлях до привидів інфраструктури.

Завдання 15: Перевірте на хості: чи пакети досі відкидаються?

Ви не можете ідеально симулювати віддалений доступ з локальної консолі, але можна перевірити, чи ядро все ще логуює drop-повідомлення для вашого джерела.

cr0x@server:~$ journalctl -k --since "5 min ago" --no-pager | egrep -i 'PVEFW-DROP-IN' | tail -n 5

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

Рішення: Якщо відкидання зберігаються — перевірте порядок правил і область (датацентр vs вузол). Також перевірте, чи ви не заходите з іншої IP-адреси, ніж думаєте (NAT, VPN, jump host).

Завдання 16: Підтвердіть віддалений шлях за допомогою tcpdump (коли потрібен доказ, а не відчуття)

cr0x@server:~$ tcpdump -ni vmbr0 tcp port 8006 or tcp port 22 -c 10
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vmbr0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:06:41.112233 IP 10.20.30.50.51234 > 10.20.30.11.8006: Flags [S], seq 1234567890, win 64240, options [mss 1460,sackOK,TS val 111 ecr 0,nop,wscale 7], length 0
10:06:41.112455 IP 10.20.30.11.8006 > 10.20.30.50.51234: Flags [S.], seq 987654321, ack 1234567891, win 65160, options [mss 1460,sackOK,TS val 222 ecr 111,nop,wscale 7], length 0

Що це означає: Ви бачите SYN і SYN-ACK. Це означає зв’язність. Якщо SYN доходить, але немає SYN-ACK — хост відкидає або не слухає.

Рішення: SYN тільки зазвичай означає drop фаєрволом. SYN+SYN-ACK означає — ви повернулись; інші проблеми — це ймовірно TLS/сертифікат/браузер або зворотний проксі попереду.

Завдання 17: Перевірте, чи випадково не заблокували себе по інтерфейсу (vmbr0 vs підінтерфейс VLAN)

cr0x@server:~$ ip -d link show vmbr0 | head -n 12
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 1 vlan_default_pvid 1 vlan_protocol 802.1Q

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

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

Завдання 18: Перевірте стан файлової системи кластера (бо /etc/pve — особливий)

cr0x@server:~$ pvecm status 2>/dev/null | head -n 15
Cluster information
-------------------
Name:             corp-cluster
Config Version:   42
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 10:08:12 2025
Quorum:           Yes

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

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

Жарт №2: Нічого так не вчить «контролю змін», як раптове знайомство з серверною кімнатою о 2-й ночі.

Три корпоративні міні-історії (біль, жаль і один тихий герой)

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

Середня компанія використовувала Proxmox для внутрішніх робочих навантажень: CI-runner’и, кілька баз даних і кластер «тимчасових» VM, що живуть роками. Новий керівник з безпеки попросив «deny inbound за замовчуванням» на гіпервізорах. Розумно. Команда погодилася — а потім зробила небезпечну річ: припустила, що їхня VPN-підмережа — єдине джерело управління.

Насправді команда операцій використовувала bastion host в іншій підмережі для обслуговування. Bastion з’явився під час редизайну мережі і тихо став основним шляхом адміністрування. Зміна брандмауера дозволила SSH і 8006 з VPN-діапазону і відкидала все інше.

Спочатку нічого не здавалося зламаним. Люди, які вже були в SSH-сесіях, продовжували працювати, бо stateful правила дозволяли established-з’єднання. Це зробило зміну безпечною на вигляд. Потім bastion перезавантажили для оновлення ядра. Коли він піднявся — не міг SSHнути на вузли. Web UI теж зник. Раптом «deny by default» виглядав як аварія.

Виправлення було простим: консоль на одному вузлі, зупинка pve-firewall, додавання allow для підмережі bastion, запуск pve-firewall, тестування з bastion і VPN. Урок не в тому, щоб не робити deny by default. Урок у тому, що припущення щодо шляхів управління — брехня, поки ви не задокументували їх.

Після інциденту вони написали односторінковий «контракт площини управління»: які підмережі можуть доступатися до гіпервізорів, які порти і як тестувати з кожного шляху перед увімкненням DROP. Це було нудно. Але працювало.

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

Інша організація «оптимізувала» правила брандмауера, щоб тримати їх чистими. Один інженер вирішив консолідувати правила в області датацентру, щоб всі вузли поводилися однаково. Аргумент: менше винятків по вузлам, менше «сніжинок», простіше відповідати. В принципі — добре.

Повернення вдарило через гетерогенність. Деякі вузли мали управління на vmbr0 з untagged VLAN; інші — з tagged VLAN на vmbr0.20. Консолідовані правила включали матчі по інтерфейсу, що були вірні для половини флоту і невірні для іншої. Потерпілі вузли не підходили під allow-правила, тож спрацьовував default DROP.

Вони втратили доступ до кількох вузлів одночасно — тип інциденту, що змушує керівництво питати «Чому ми не можемо просто залогінитися?». Команді довелося використовувати OOB консолі для відновлення, по одному хосту, поки решта компанії дивилася на статусну сторінку з дипломатичною формулюванням.

Що погіршило ситуацію: оскільки правила були кластерними, «швидке виправлення» означало нову кластерну зміну, яку команда вагалася застосувати, не розуміючи поведінки правил. Вони врешті зупинили pve-firewall на заблокованих вузлах, відновили доступ, а потім переробили правила на базі груп управління: allowlist за джерелами і портами без крихких перетворень по інтерфейсу.

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

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

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

Цей шлях був навмисно нудним: виділений jump host з фіксованим IP, дозволений для SSH і 8006 на всіх гіпервізорах, та під наглядом. Також в них було IPMI з документованим доступом у захищеному сховищі. Ніхто не любив цим займатись. Це не було гламурно.

Одного дня хтось випадково застосував правило на датацентрі, що відкидало весь вхідний TCP, окрім кількох портів додатків. Це була чесна помилка в UI: інженер думав, що редагує політику VM, а не датацентру. За секунди більшість управлінського доступу зникла.

Команда не панікувала. Вони використали jump host, який за дизайном ще мав доступ, залогінилися на вузли і скасували правило. Жодних консольних акробатик. Жодних гадань. Постмортем був коротким і нудним: покращити захист UI, додати підтвердження для змін на рівні датацентру і тримати jump host під наглядом.

Іноді найкраще інженерне рішення — бути спеціально нецікавим.

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

Цей розділ — там, де ви зіставляєте те, що бачите, з тим, що насправді відбувається. Швидке впізнавання шаблонів врятує час і нерви.

1) Браузер таймаутина на порті 8006, але curl з консолі працює

Симптом: Web UI недоступний ззовні, але curl -kI https://127.0.0.1:8006/ повертає 200.
Корінна причина: Брандмауер відкидає вхідний TCP/8006 або upstream ACL блокує.
Виправлення: Зупиніть pve-firewall, щоб відновити доступ, потім додайте явні allow-правила для джерел адміністраторів на TCP/8006 і перезавантажте.

2) SSH працював у однієї людини, потім перестав коли вона вийшла

Симптом: Існуюча SSH-сесія вижила; нові SSH-сесії не проходять.
Корінна причина: Stateful allow дозволяв established з’єднання, але новий вхідний TCP/22 відкидається.
Виправлення: Додайте явний allow для TCP/22 з джерел адміністраторів; не покладайтеся на вдачу conntrack.

3) Тільки один вузол заблоковано; інші в порядку

Симптом: Кластер здебільшого доступний; один вузол недоступний для SSH/UI.
Корінна причина: Брандмауер на рівні вузла увімкнений з строгішою політикою, невідповідність інтерфейсу або опечатка в правилах вузла.
Виправлення: Перевірте /etc/pve/firewall/pve-XX.fw на предмет enable та політик; порівняйте з робочим вузлом; перезапустіть pve-firewall після виправлення.

4) Усе заблоковано одразу після редагування брандмауера датацентру

Симптом: Кілька вузлів майже одночасно стають недоступними.
Корінна причина: Кластерне правило (датацентр) відкинуло порти управління або політика за замовчуванням змінена на DROP без allowlist.
Виправлення: Зайдіть в консоль одного вузла, зупиніть pve-firewall, відредагуйте /etc/pve/firewall/cluster.fw щоб дозволити управління, запустіть firewall, перевірте, повторіть за потреби.

5) Web UI працює в LAN, але не через VPN

Симптом: Локальна підмережа може дістатися до 8006; VPN-користувачі — ні.
Корінна причина: Allow-правила прив’язані до однієї підмережі; NAT VPN змінює джерельний IP; або MTU-проблеми маскуються під фаєрвол.
Виправлення: Підтвердіть IP VPN, який бачить Proxmox через логи фаєрвола або tcpdump; відкоригуйте allow-джерело відповідно; якщо SYN-ACK є, але UI все ще падає — перевірте MTU/TLS, а не брандмауер.

6) Зупинка pve-firewall не відновлює доступ

Симптом: systemctl stop pve-firewall, але SSH/UI все ще недоступні.
Корінна причина: Правила застосовуються nftables/iptables, які не належать pve-firewall; upstream firewall/ACL; неправильний маршрут або IP.
Виправлення: Перегляньте nft list ruleset і iptables -S, перевірте IP/маршрут, запустіть tcpdump щоб побачити чи доходить SYN, і перевірте upstream політики мережі.

7) Ви дозволили 8006, але все одно не можете зайти

Симптом: TCP підключається, але логін у UI не працює або сторінка завантажується частково.
Корінна причина: Не брандмауер: може бути проблема з pveproxy, зсув часу, проблема бекенду автентифікації або невідповідність сертифіката/імені хоста (особливо за проксі).
Виправлення: Перевірте systemctl status pveproxy, дивіться journalctl -u pveproxy, підтвердіть синхронізацію часу та спробуйте локальний логін.

8) Ви редагували /etc/pve/firewall файли, але нічого не змінюється

Симптом: Зміни не застосовуються, правила ніби не змінені.
Корінна причина: Файлова система кластера не здорова (проблеми з кворумом), або ви редагували невірну область файлу.
Виправлення: Перевірте pvecm status на наявність кворуму; переконайтесь, що редагували потрібний файл (cluster.fw vs вузловий *.fw); перезапустіть pve-firewall і перевірте статус компіляції.

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

Аварійний покроковий (відновити доступ за менше ніж 10 хвилин)

Отримайте консоль (IPMI/KVM/консоль провайдера).
Підтвердіть IP і маршрут:
- ip -br addr показує правильний management IP.
- ip route показує маршрут за замовчуванням.
Підтвердіть служби:
- systemctl status ssh і systemctl status pveproxy.
- ss -lntp | egrep '(:22|:8006)'.
Підтвердіть drop з боку фаєрвола (опційно, але швидко):
- journalctl -k | egrep -i 'PVEFW|DROP|REJECT'.
Виберіть режим відновлення:
- Найшвидше: systemctl stop pve-firewall.
- Контрольніше: додати вузький allow для вашого адміністративного IP (тимчасовий nft emergency chain) або відредагувати /etc/pve/firewall/*.fw.
Перевірте ззовні: протестуйте SSH і https://node:8006 з відомого адміністративного хоста.
Виправте фактичне правило: видаліть deny, додайте правильний allowlist, перезавантажте брандмауер (systemctl start pve-firewall і pve-firewall compile).
Видаліть тимчасові emergency nft правила, якщо ви їх створювали:
- nft delete table inet emergency

Чек-лист стабілізації (після відновлення доступу)

Визначте область: це було правило Датацентру, Вузла чи VM/CT?
Підтвердіть політики: policy_in і policy_out на кожному рівні.
Визначте джерела для управління: VPN-підмережа, IP bastion, ноутбуки on-call, NAT офісу — запишіть список.
Реалізуйте allowlist для управління:
- Дозвольте TCP/22 і TCP/8006 з цього списку.
- Дозвольте ICMP з цього списку (опційно, але корисно для операцій).
Протестуйте з кожного шляху: VPN, jump host, офісна мережа і т.д. Не робіть припущень.
Увімкніть логування drop тільки там, де потрібно; забагато логів ховає реальні падіння.
Документуйте break-glass: де консоль, як до неї доступатись і хто має доступ.

Запобігання: зробіть брак доступу нудним

Після відновлення доступу зробіть відповідальну річ: запобігайте повторенню. Не надією. На дизайном.

1) Відокремте «площину управління» від «всього іншого»

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

Виділений management VLAN/підмережа з контрольованим входом.
Адмін VPN, який приземляє вас у цю підмережу (або NATить до відомого egress IP).
Bastion host зі стабільним IP і сильною автентифікацією. Дозвольте управління лише з нього, якщо можливо.

2) Тримайте ваш «allowlist для SSH і 8006» явним і локальним

Ви можете встановити policy_in DROP глобально, але не покладайтеся на одне крихке правило датацентру для вашого єдиного шляху доступу. Використовуйте правила вузла для allowlist управління, особливо якщо вузли відрізняються (інтерфейси, маркування VLAN, підмережі).

3) Використовуйте «правило двох осіб» для змін на рівні датацентру

Область датацентру — це радіус ураження кластеру. Ставте це на рівень змін схеми бази даних продуктивного середовища: рецензія, перевірка області і план відкату.

4) Тестуйте нове підключення, а не свою щасливу сесію

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

5) Надавайте перевагу вузьким тимчасовим змінам під час інцидентів

Коли інцидент, «тимчасово зупинити pve-firewall» прийнятно, бо це відкатний і швидкий крок. Але не тримайте фаєрвол вимкненим днями. Так тимчасове стає постійним, а постійне — політикою.

6) Побудуйте workflow «break-glass», який можна виконати напівсонним

Як мінімум:

Перевірений OOB доступ щоквартально.
Задокументована процедура логіну в консоль.
Відомий IP/діапазон адміністратора для дозволу.
Готовий фрагмент правил для вузла, який дозволяє TCP/22 і TCP/8006.

FAQ

1) Чи варто назавжди вимикати брандмауер Proxmox?

Ні. Тимчасово вимикайте його для відновлення, а потім виправляйте політику. Гіпервізори — привілейовані системи; тримати їх повністю відкритими — запрошення до суворого аудиту.

2) Яка найшвидша безпечна команда для відновлення доступу?

З консолі: systemctl stop pve-firewall. Якщо служби працюють і мережа в порядку, це зазвичай відновлює SSH і Web UI миттєво.

3) Чому Web UI використовує порт 8006 і чи можна його змінити?

8006 — це порт за замовчуванням для pveproxy. Ви можете змінити експозицію через зворотні проксі та мережні політики, але змінювати сам порт рідко варто через оперативні ускладнення під час інцидентів.

4) Я зупинив pve-firewall, але все ще заблокований. Що робити?

Доведіть, чи пакети доходять до хоста. Використайте tcpdump -ni vmbr0 tcp port 22 під час спроби підключення. Якщо SYN не доходить — проблема upstream (маршрут, VLAN, ACL). Якщо SYN доходить, але немає SYN-ACK — локальне фільтрування або служба/слухання.

5) Краще виправляти правила через UI чи редагувати /etc/pve/firewall/*.fw?

Під час інциденту редагуйте те, що швидше і менш схильне до помилок для вас. UI комфортніший, але може бути недоступним при блокуванні. Редагування з консолі прийнятне; просто перевіряйте pve-firewall compile і перезапускайте сервіс.

6) Яке правило має бути завжди, щоб запобігти блокуванню управління?

Явний allow для TCP/22 і TCP/8006 з контрольованого джерела управління (IP bastion або підмережа адміністратора), бажано на рівні вузла, якщо середовище гетерогенне.

7) Чи можуть правила VM/CT заблокувати доступ до хоста?

Непрямо. Правила VM/CT застосовуються до інтерфейсів гостьових ОС. Блокування хоста зазвичай походить з налаштувань датацентру/вузла або інших інструментів на рівні хоста.

8) Як дізнатися, чи Proxmox використовує nftables чи iptables?

Перевірте, що справді завантажено: nft list ruleset і iptables -S. На сучасних Debian-системах часто використовується nftables, іноді з сумісністю iptables. Під час аварій довіряйте реальному виводу, а не спогадам з минулого.

9) Що з IPv6 — чи може воно спричинити «напів-блокування»?

Так. Якщо клієнти віддають перевагу IPv6, а ваші правила дозволяють тільки IPv4 (або навпаки), ви отримаєте непослідовний доступ. Перевірте ip -br addr на предмет IPv6 і переконайтесь, що політика відповідає реальності.

10) Якщо я в кластері, чи можна виправити це з будь-якого вузла?

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

Висновок: наступні кроки, які варто зробити сьогодні

Блокування доступу брандмауером Proxmox — поширена ситуація, бо UI дає простий контроль над гострим інструментом. Відновлення просте: підтвердіть мережу, служби, логі про брандмауер, потім або зупиніть pve-firewall, або додайте вузький allow, щоб повернути доступ. Далі виправте правила правильно: явні allowlist для управління та правильна область застосування.

Наступні кроки, що приносять реальну користь:

Створіть на рівні вузла allowlist для управління TCP/22 і TCP/8006 з bastion або адміністративної підмережі.
Переконайтесь, що OOB-консоль працює до наступного інциденту, щоб уникнути несподіванок.
Додайте простий тест перед змінами: «Чи вдається нове SSH-підключення і нове підключення до 8006 з кожного адмін-шляху?»
Тримайте план відкату як команду, яку ви можете надрукувати з консолі не задумуючись: зупинити фаєрвол, відновити доступ, потім виправити політику.