Короткий ответ

Если SSH на pve1 работает, гипервизор жив: не перезагружайте узел «чтобы GUI ожил» и не трогайте sshd. Проверьте цепочку pve-cluster → pvedaemon → pveproxy на TCP 8006, монтирование /etc/pve и сертификат pveproxy-ssl.pem. Без quorum pmxcfs часто read-only — GUI деградирует, это чинится кворумом, не перевыпуском сертификата вслепую.

Не отключайте pve-firewall и iptables навсегда. Сначала докажите, что пакет до 8006 не доходит или что процесс не слушает.

Симптомы и как отличить

Типичная картина:

  • https://pve1.contoso.example:8006 — timeout, refused или SSL alert;
  • curl -kI https://127.0.0.1:8006 с самого узла тоже падает;
  • веб показывает login, после пароля — пустой датацентр / «connection error»;
  • соседний узел в кластере открывается, pve1 — нет.

Отличия:

Что видноСкорее не «умер pveproxy»Куда смотреть
Нет SSH и нет pingхост не загрузилсяProxmox не загружается
8006 с localhost жив, снаружи нетfirewall, bind, DNATэтот материал + фильтр хоста
GUI есть, VM без сетиbridge/VLANСеть VM не работает
«node offline», конфиги не сохраняютсяquorum/corosyncКластер потерял quorum

Возможные причины

  1. pveproxy / pvedaemon не запущены после апдейта или заполненного /.
  2. pve-cluster не смонтировал /etc/pve — прокси не читает сертификат и список узлов.
  3. Истёк или сломан сертификат, имя узла не совпадает с CN/SAN после rename.
  4. Служба слушает только 127.0.0.1 или неверный интерфейс после правки pveproxy конфига.
  5. Нет кворума: API отвечает ошибками, сохранение невозможно.
  6. Фильтр: pve-firewall, nft, внешний ACL на 8006; реже — proxy/WAF перед панелью.

Диагностика

Плейсхолдеры: pve1, VM 101, мост vmbr0. SSH оставьте как есть.

1. Слушает ли 8006

pveversion
systemctl status pveproxy pvedaemon pve-cluster --no-pager
ss -lntp | grep -E '8006|pveproxy'
curl -kI --max-time 5 https://127.0.0.1:8006

systemctl failed + пустой ss — процесс мёртв. ss показывает 8006, curl снаружи нет — сеть/фильтр. Не перезапускайте все службы сразу, пока не сняли журнал.

journalctl -u pveproxy -u pvedaemon -u pve-cluster -b --no-pager | tail -n 80
df -h / /var

Заполненный корень останавливает pmxcfs так же надёжно, как kill.

2. Кластерная ФС и сертификат

ls -l /etc/pve
ls -l /etc/pve/nodes/pve1/pve-ssl.pem /etc/pve/local/pveproxy-ssl.pem
pvecm status

Пустой /etc/pve при active SSH — pve-cluster не поднял fuse. Пока так, любой «перевыпуск сертификата» пишет не туда.

3. Снаружи

С рабочей станции администратора:

nc -vz pve1.contoso.example 8006
nc -vz pve1.contoso.example 22

22 жив, 8006 нет — не «сервер лёг». Смотрите pve-firewall datacenter/host, цепочку INPUT, не systemctl stop ssh.

Решение

Сценарий A. Службы упали, диск не полный

systemctl restart pve-cluster
systemctl restart pvedaemon pveproxy
systemctl is-active pve-cluster pvedaemon pveproxy

Порядок важен: сначала кластерная ФС. Если pve-cluster не становится active, не крутите только pveproxy.

Сценарий B. Сертификат

После смены имени/домена или битого PEM:

pvecm updatecerts --force
systemctl restart pveproxy

Проверьте дату и SAN. Самоподписанный сертификат PVE по умолчанию ругается в браузере — это не «недоступен», это warning TLS. Недоступность — handshake fail или refused.

Сценарий C. Нет кворума, GUI «полуживой»

Чините quorum и узел вне кластера. Не ставьте pvecm expected 1 только ради панели: на двух узлах это путь к split-brain.

Сценарий D. Фильтр режет 8006

Включите нужный порт точечно в правилах PVE Firewall (направление IN, порт 8006/tcp к management IP), не pve-firewall stop навсегда. Если правили /etc/network/interfaces и потеряли маршрут к GUI, но SSH по старому адресу жив — см. Linux Bridge, правьте с консоли, не ifdown vmbr0 по SSH.

Сценарий E. Заполнен диск

Освободите /var/log, старые vzdump на local, журналы. Не удаляйте /etc/pve и не чистите local-lvm тома VM 101 «для места».

Как проверить, что проблема устранена

С узла и с рабочей станции:

systemctl is-active pveproxy pvedaemon pve-cluster
curl -kI https://127.0.0.1:8006
pvesm status
qm status 101

В браузере: логин, список узлов, открывается консоль/конфиг 101. Сохранение пустякового описания VM должно пройти (проверка записи pmxcfs). SSH по-прежнему принимает ключ, которым вы зашли.

Если не помогло

  • pveproxy сразу падает: читайте полный unit, ищите синтаксис сертификата и права www-data на PEM.
  • Login 401/ticket: время узла vs клиент, не «сломанный пароль root@pam» в первую очередь; проверьте timedatectl.
  • GUI открывается по IP и не открывается по DNS: split DNS, не pveproxy.
  • Обратный прокси на 443: проверьте, что бэкенд именно 8006 и не режется WebSocket для консоли VNC/SPICE — это уже не «панель недоступна», а консоль.
  • После обновления пакет pve-manager не установился: apt-get -f install, не downgrade из случайного зеркала.

Профилактика

  • Мониторинг TCP 8006 и systemctl is-active pveproxy.
  • Отдельный management IP, SSH ключами, GUI не торчит в интернет без нужды.
  • Перед сменой hostname — процедура PVE, не hostnamectl «на живую».
  • Место на корне и отдельный датастор под ISO/backup.
  • Проверка узла перед работами.

FAQ

Почему SSH есть, а 8006 нет — это нормально?

Да. sshd и pveproxy независимы. Именно поэтому SSH — канал ремонта, его не перезапускают «за компанию».

Нужно ли systemctl restart pve-cluster на всём кластере?

Нет. Рестарт pmxcfs на всех узлах сразу даёт гонку. Чините pve1, смотрите pvecm status.

Браузер пишет NET::ERR_CERT_AUTHORITY_INVALID — панель сломана?

Нет, это недоверенный CA самоподписанного сертификата. Сломано, если handshake не завершается или сертификат не читается процессом.

Можно ли слушать GUI на 443?

Штатный порт — 8006. Перенос на 443 через внешний proxy допустим, но тогда диагностика 8006 на localhost обязательна, иначе вы чините не тот слой.

Стоит ли отключить firewall, чтобы проверить?

На секунды, с консоли, с планом включить обратно — как эксперимент. Оставлять выключенным «потому что GUI заработал» нельзя.