Home Assistant i Proxmox bezpiecznie. Dostęp, 2FA, firewall, UPS i plan awarii
Można mieć świetnie skonfigurowanego Home Assistanta, szybki SSD, poprawny Recorder i trzy kopie zapasowe, a mimo tego zbudować system, który przestanie działać po pierwszej poważniejszej awarii. Bezpieczeństwo Home Assistanta na Proxmoxie nie kończy się na silnym haśle. Trzeba zabezpieczyć również hypervisor, dostęp administracyjny, SSH, sieć, zasilanie i sposób odzyskania całej platformy.
W części 1 o dobrych praktykach Home Assistanta na Proxmoxie przygotowałem HAOS jako maszynę wirtualną i uporządkowałem CPU, RAM, dysk, VirtIO, QEMU Guest Agent, Zigbee i backup VM.
W części 2 o SQLite, MariaDB i Recorderze zajęliśmy się bazą danych, InfluxDB i kopiami zapasowymi. Teraz interesuje mnie warstwa znajdująca się jeszcze wyżej: bezpieczeństwo i odporność całego hosta.
Home Assistant i Proxmox to dwa zupełnie różne poziomy dostępu
Konto administratora Home Assistanta daje ogromne możliwości. Można sterować urządzeniami, zmieniać konfigurację, tworzyć użytkowników i automatyzacje. Jest więc oczywiście bardzo wrażliwe.
Dostęp administracyjny do Proxmoxa znajduje się jednak poziom wyżej.
Z panelu Proxmoxa mogę wyłączyć całą maszynę HAOS, wejść do jej konsoli, zmienić sprzęt wirtualny, podłączyć lub odłączyć dyski, odtworzyć backup, utworzyć kolejne VM albo całkowicie usunąć istniejące zasoby.
Jeżeli na tym samym hoście działają inne elementy infrastruktury, przejęcie Proxmoxa daje dostęp nie tylko do Home Assistanta. Hypervisor jest warstwą zarządzającą całym serwerem.
Traktuję go jak interfejs administracyjny infrastruktury. Dostęp do niego ograniczam mocniej niż dostęp do usług używanych na co dzień przez domowników.
Jeśli dopiero porządkujesz bezpieczeństwo samego Home Assistanta, w kursie mam osobną lekcję:
Bezpieczeństwo Home Assistant: co jest realnym zagrożeniem, a co straszeniem
.
Proxmox port 8006: jak bezpiecznie korzystać ze zdalnego dostępu?
Panel WWW Proxmoxa standardowo korzysta z portu 8006. SSH zwykle znajdziemy na porcie 22. Technicznie można przekierować oba porty na routerze i łączyć się z serwerem bezpośrednio z Internetu.
Nie jest to architektura, którą wybrałbym dla domowego serwera automatyki.
Jeśli jestem poza domem i naprawdę potrzebuję dostać się do Proxmoxa, najpierw zestawiam bezpieczne połączenie VPN do swojej sieci. Dopiero później otwieram panel hypervisora tak, jakbym znajdował się lokalnie.
W kursie pokazuję dwie praktyczne ścieżki:
WireGuard VPN
oraz
Tailscale przy CGNAT.
A Cloudflare Tunnel?
Cloudflare Tunnel jest sensownym rozwiązaniem dla usług WWW i może być używany również z Home Assistantem. Opisuję go osobno w lekcji
Cloudflare Tunnel w praktyce
.
Panel hypervisora wolę jednak pozostawić w warstwie administracyjnej i wchodzić do niej przez VPN. Home Assistant ma być wygodnie dostępny dla domowników. Proxmox jest narzędziem administratora używanym sporadycznie.
2FA na Proxmoxie: jedna z pierwszych rzeczy, które warto włączyć
Proxmox obsługuje uwierzytelnianie wieloskładnikowe. Przy koncie posiadającym pełne prawa administracyjne nie widzę dobrego powodu, żeby pozostawać tylko przy haśle.
Dostępne są między innymi TOTP, WebAuthn oraz mechanizmy odzyskiwania dostępu. W typowej domowej instalacji TOTP jest prostym i skutecznym początkiem. Jeśli korzystamy z odpowiednio skonfigurowanego WebAuthn i kluczy sprzętowych, można pójść krok dalej.
Dane potrzebne do odzyskania dostępu przechowuję poza hostem. Nie w VM działającej na tym samym Proxmoxie i nie w miejscu, do którego dostanę się wyłącznie wtedy, kiedy cały serwer działa.
Podobnie podchodzę do użytkowników Home Assistanta. Konta, role i 2FA opisuję dokładniej w lekcji
Konta użytkowników, role i 2FA
.
Czy codziennie logować się jako root@pam?
Przy pierwszej instalacji Proxmoxa naturalnie korzystamy z konta root. Wiele osób zostawia później taki sposób pracy na następne kilka lat.
Ja wolę rozdzielić codzienne zarządzanie od konta, które traktuję jako dostęp najwyższego poziomu. Proxmox pozwala tworzyć własnych użytkowników, przypisywać im role i definiować zakres uprawnień.
Mogę więc utworzyć osobne konto administracyjne chronione 2FA i używać go w panelu WWW, a dostęp root zachować na sytuacje, w których naprawdę jest potrzebny.
Nie jest to magiczne zabezpieczenie. Użytkownik z pełną rolą Administrator nadal może wykonać prawie każdą operację. Daje jednak czytelniejszy model dostępu i pozwala przestać używać roota do każdej drobnej czynności.
Integracja potrzebuje odczytu? Nie daję jej hasła roota
To jedna z tych praktyk, które warto wdrożyć od razu, bo nie kosztują prawie nic.
Załóżmy, że chcę pokazywać w Home Assistant albo innym systemie monitoringu temperaturę hosta, wykorzystanie CPU, stan VM i wykorzystanie storage. Najprostsza droga to podanie loginu administratora i jego hasła.
Nie robię tego.
Proxmox ma własny system użytkowników, ról i tokenów API. Do monitoringu mogę wykorzystać ograniczony token oraz uprawnienia tylko do odczytu, na przykład oparte o rolę PVEAuditor.
Jeśli system ma tylko odczytywać status Proxmoxa, nie powinien mieć prawa wyłączania VM, zmiany storage ani zarządzania użytkownikami.
Jeśli taki token kiedyś wycieknie, konsekwencje będą znacznie mniejsze niż po przejęciu pełnego konta administratora. To jest praktyczny przykład zasady least privilege, a nie akademicka teoria bezpieczeństwa.
SSH w Proxmoxie: klucze, root i bezpieczna konfiguracja
Do administracji przez SSH preferuję klucze zamiast wpisywania hasła roota przy każdym połączeniu.
Najpierw generuję klucz, dodaję klucz publiczny do serwera i otwieram nowe połączenie w osobnej sesji. Dopiero kiedy potwierdzę, że logowanie kluczem rzeczywiście działa, zaczynam ograniczać inne metody uwierzytelniania.
Proxmox wykorzystuje SSH również we własnych mechanizmach, szczególnie w środowisku klastrowym i przy operacjach pomiędzy węzłami. Czym innym jest całkowite zablokowanie roota przez SSH, a czym innym pozostawienie dostępu kluczem i wyłączenie logowania hasłem.
Na pojedynczym hoście można zaostrzyć konfigurację SSH znacznie bardziej niż w klastrze. Przed każdą taką zmianą sprawdzam jednak, z których funkcji Proxmoxa rzeczywiście korzystam i czy nie odbieram sobie potrzebnej drogi administracyjnej.
Jeśli zmieniam SSH, firewall albo sieć hosta, chcę mieć możliwość lokalnego wejścia do maszyny. W małym mini-PC zwykły monitor i klawiatura potrafią być lepszym systemem ratunkowym niż kolejna warstwa zdalnego zarządzania.
Zmiana portu SSH nie jest główną warstwą bezpieczeństwa
Często spotykam poradę, że pierwszą rzeczą po instalacji serwera powinna być zmiana portu SSH z 22 na losową wysoką wartość.
Można to zrobić. Jeśli SSH jest osiągalne z Internetu, zmniejszy to liczbę najprostszych automatycznych prób logowania widocznych w logach.
Nie traktuję tego jednak jako istotnej ochrony.
Znacznie ważniejsze są VPN, firewall, klucze SSH i przede wszystkim brak bezpośredniego publicznego dostępu do warstwy zarządzającej.
A Fail2Ban?
Fail2Ban jest dobrym narzędziem w odpowiednim scenariuszu, ale nie stawiam go na początku listy dla Proxmoxa dostępnego wyłącznie z LAN lub VPN.
Jeśli firewall nie wpuszcza przypadkowego ruchu z Internetu do SSH i panelu PVE, dużą część problemu rozwiązuję wcześniej, zanim Fail2Ban dostałby cokolwiek do analizowania.
2. Ograniczam dostęp do managementu.
3. Zdalnie korzystam z VPN.
4. Używam 2FA i kluczy SSH.
5. Dopiero później dokładam dodatkowe mechanizmy, jeśli są mi potrzebne.
Firewall Proxmoxa: co ograniczyć i jak nie odciąć własnego dostępu
Proxmox ma własny firewall działający na różnych poziomach infrastruktury. W większej instalacji jest to bardzo wartościowe narzędzie.
Nie włączam go jednak pierwszy raz podczas urlopu, 500 kilometrów od domu, po dodaniu kilkunastu niesprawdzonych reguł.
Najpierw ustalam, skąd ma być dostęp administracyjny. Jeśli mam wydzieloną sieć management, to właśnie ona może mieć dostęp do panelu i SSH. Jeśli nie mam VLAN-ów, ograniczenie zarządzania do zaufanego LAN nadal jest wartościowe.
Sprawdź regułę pozwalającą na dostęp administracyjny i miej lokalną drogę do hosta. Błąd w regule sieciowej nie powinien kończyć się sytuacją, w której nie potrafisz wejść do własnego serwera.
VLAN dla Home Assistanta i Proxmoxa: Management, LAN i IoT
Nie uważam VLAN-ów za obowiązkowy warunek korzystania z Home Assistanta. Dobrze skonfigurowana prosta sieć jest lepsza niż kilka VLAN-ów, których właściciel później nie potrafi zdiagnozować.
Gdy jednak w sieci pojawiają się kamery, wiele urządzeń IoT, serwer Proxmox, NAS i prywatne komputery, segmentacja zaczyna dawać realną wartość.
| Management | Proxmox, router, switch, kontroler sieci |
| Main / Trusted | komputery, telefony i prywatne urządzenia |
| IoT | kamery, urządzenia Wi-Fi smart home i sprzęt o mniejszym poziomie zaufania |
Home Assistant jest tutaj nietypowym elementem. Musi komunikować się z dużą częścią IoT, ponieważ jego zadaniem jest sterowanie tym sprzętem. Nie oznacza to jednak, że każde urządzenie IoT powinno móc inicjować połączenie do komputerów domowych albo panelu Proxmoxa.
Podstawy takiego podziału opisuję w lekcji
Jak oddzielić urządzenia smart od komputerów domowych
,
a praktyczną konfigurację VLAN rozwijam w
lekcji o konfiguracji sieci i VLAN
.
VLAN może zepsuć automatyczne wykrywanie urządzeń
Część urządzeń Home Assistanta jest wykrywana przy pomocy multicastu, mDNS albo SSDP. Po rozdzieleniu sieci takie pakiety nie przechodzą automatycznie pomiędzy segmentami.
Możemy więc mieć urządzenie, które odpowiada po swoim adresie IP, a mimo tego Home Assistant przestaje wykrywać je automatycznie.
Rozwiązaniem nie jest otwarcie całego ruchu pomiędzy VLAN-ami. W zależności od sprzętu sieciowego możemy wykorzystać odpowiednie mechanizmy przekazywania multicastu lub mDNS i dopuścić tylko potrzebną komunikację.
Segmentację projektuję na podstawie przepływów: kto naprawdę musi połączyć się z kim. Nie tworzę VLAN-ów tylko po to, żeby chwilę później otworzyć pomiędzy nimi cały ruch.
Proxmox powinien pozostać przede wszystkim hypervisorem
Proxmox jest oparty na Debianie. Technicznie mogę zalogować się przez SSH i instalować bezpośrednio na hoście wiele dodatkowych usług.
Bez konkretnego powodu tego nie robię.
Pi-hole, Node-RED, broker MQTT, serwer WWW czy inne aplikacje wolę uruchamiać w VM albo LXC. Jeżeli potrzebuję Dockerowych kontenerów aplikacyjnych, bardzo sensownym rozwiązaniem jest oddzielna VM przeznaczona właśnie do Dockera.
Dzięki temu host pozostaje przewidywalny. Aktualizacja Proxmoxa nie musi uwzględniać zestawu przypadkowych aplikacji zainstalowanych ręcznie kilka lat wcześniej, a odtworzenie hosta po awarii jest znacznie prostsze.
Proxmox Enterprise czy no-subscription?
W domowych instalacjach bardzo często spotykamy repozytorium no-subscription. Sam komunikat ostrzegający, że repozytorium nie jest przeznaczone do środowisk produkcyjnych, nie oznacza, że Proxmox jest źle zainstalowany.
Trzeba jednak rozumieć różnicę.
Repozytorium Enterprise jest rekomendowane przez Proxmoxa do zastosowań produkcyjnych. Trafiają do niego bardziej konserwatywnie zweryfikowane pakiety i wymaga aktywnej subskrypcji.
Repozytorium no-subscription jest dostępne bez płatnej subskrypcji i jest powszechnie wykorzystywane w homelabach. Pakiety pojawiają się tam wcześniej i nie przechodzą takiego samego poziomu walidacji jak w kanale Enterprise.
No-subscription jest rozsądnym wyborem w wielu domowych instalacjach, ale świadomie akceptuję mniej konserwatywny kanał pakietów. Jeżeli awaria hypervisora ma już realny wpływ na funkcjonowanie całego domu, subskrypcję Enterprise można potraktować jako jedną z opcji zwiększenia przewidywalności aktualizacji.
Nie przechodziłbym natomiast na repozytorium testowe tylko dlatego, że znajduje się tam nowszy kernel albo funkcja, której chwilowo potrzebuję. Produkcyjny serwer automatyki nie jest dla mnie miejscem do testowania świeżych pakietów.
Aktualizuję Proxmoxa regularnie, ale restart hosta planuję
Brak aktualizacji nie jest strategią bezpieczeństwa. Hypervisor ma kernel, usługi sieciowe, panel administracyjny i wiele komponentów mających bezpośredni wpływ na całą platformę.
Z drugiej strony nie chcę, żeby host restartował się bez kontroli w przypadkowym momencie tylko dlatego, że pojawił się nowy kernel.
W domu wolę proste okno serwisowe. Sprawdzam backupy VM, stan hosta i dostępne aktualizacje, wykonuję upgrade, a restart planuję wtedy, kiedy przez następne kilka minut mogę obserwować powrót infrastruktury.
Sprawdzam hosta, HAOS, sieć, Zigbee, podstawowe integracje i kilka najważniejszych automatyzacji. To, że VM ma status Running, nie znaczy jeszcze, że cały smart home działa poprawnie.
Aktualizacje samego Home Assistanta opisuję osobno w lekcji
Aktualizacje Home Assistant: kiedy klikać, kiedy poczekać i jak nie zepsuć systemu
.
Monitoring Proxmoxa: dlaczego Uptime Kuma na tym samym hoście nie wystarczy
Można monitorować Proxmoxa z Home Assistanta. Można uruchomić Uptime Kuma w VM albo LXC. Można wysyłać powiadomienie, kiedy jakaś usługa przestaje odpowiadać.
Wszystko to ma wartość.
Trzeba tylko pamiętać, że jeśli system monitorujący działa na tym samym fizycznym hoście, zniknie razem z nim podczas pełnej awarii Proxmoxa.
Monitoring wewnętrzny pokazuje mi stan usług. Niezależny obserwator może powiedzieć, że cała platforma właśnie zniknęła.
Nie oznacza to, że każdy dom potrzebuje drugiego serwera tylko do pingowania pierwszego. Rolę zewnętrznego obserwatora może pełnić inny system, NAS, urządzenie sieciowe albo usługa znajdująca się poza hostem.
Powiadomienia Proxmoxa konfiguruję zanim coś się zepsuje
Jedną z rzeczy łatwych do pominięcia po instalacji są powiadomienia hosta. Interesujące stają się dopiero wtedy, kiedy pierwszy backup kończy się błędem albo storage zaczyna zgłaszać problem.
Proxmox ma własny system powiadomień, który może przekazywać istotne zdarzenia do zewnętrznych odbiorców. Nie chcę alarmu o każdej drobnostce, ale o krytycznych zdarzeniach chcę wiedzieć zanim sam zauważę, że coś nie działa.
• problem ze storage,
• krytyczny błąd hosta,
• ostrzeżenia związane z dyskiem,
• zdarzenia wymagające rzeczywistej reakcji administratora.
SMART działa tylko wtedy, kiedy rzeczywiście go skonfigurujemy
Proxmox współpracuje ze standardowymi narzędziami SMART i pakietem smartmontools, dzięki którym można monitorować stan obsługiwanych lokalnych dysków.
Nie zakładam jednak, że sama obecność Proxmoxa oznacza automatycznie skonfigurowany monitoring każdego nośnika i gotowe alarmy. Sprawdzam, czy mój dysk udostępnia dane SMART, czy odpowiednie narzędzia są dostępne i w jaki sposób ostrzeżenie ma do mnie dotrzeć.
To szczególnie istotne w małym serwerze opartym na jednym SSD. Awaria tego nośnika może jednocześnie zatrzymać wiele usług.
Nie wystarcza mi wpisanie adresu e-mail albo webhooka w konfiguracji. Wysyłam test i sprawdzam, czy komunikat naprawdę dociera do miejsca, które regularnie obserwuję.
UPS dla Home Assistanta i Proxmoxa: czego naprawdę powinien pilnować?
W tej serii pokazuję rzeczywistą instalację, a nie wyidealizowany system przygotowany pod artykuł. Dlatego tutaj trzeba napisać wprost: w mojej obecnej platformie UPS jest jeszcze elementem do uzupełnienia.
Gdybym dzisiaj stawiał całość od początku, zaplanowałbym go wcześniej.
UPS nie jest dla mnie tylko sposobem na przetrwanie kilkusekundowego zaniku napięcia. Najważniejsza jest możliwość kontrolowanego zakończenia pracy hosta, zanim bateria zostanie całkowicie rozładowana.
| Proxmox / mini PC | tak |
| router / gateway | tak |
| główny switch | tak |
| access point | jeśli jest potrzebny dla ważnych urządzeń |
Podtrzymanie tylko mini-PC może dać pozornie działający Home Assistant, który jednocześnie stracił kontakt z większością domu, bo router albo switch już się wyłączył.
Planowanie zasilania całej infrastruktury rozwijam również w lekcji
Szafka techniczna, rozdzielnia i UPS
.
NUT i Proxmox: kontrolowany shutdown przy awarii zasilania
Najprostszy UPS działa tak: znika napięcie, urządzenia przechodzą na baterię, bateria się rozładowuje, a na końcu wszystko nagle gaśnie.
Chroni to przed krótkim zanikiem, ale nie rozwiązuje problemu długiej awarii.
Docelowo chcę komunikacji pomiędzy UPS-em a hostem. Jednym ze standardowych rozwiązań w świecie linuksowym jest Network UPS Tools, czyli NUT.
NUT może obserwować stan UPS-a i rozpocząć kontrolowany shutdown systemu, gdy warunki wskazują, że dalsza praca na baterii nie ma sensu.
↓
UPS przechodzi na baterię
↓
NUT obserwuje stan zasilania i baterii
↓
krótka awaria? pracujemy dalej
↓
długa awaria? rozpoczynamy shutdown
↓
VM i usługi kończą pracę
↓
Proxmox bezpiecznie wyłącza host
Home Assistant nie powinien być jedynym sterownikiem własnego shutdownu
Można podłączyć UPS do Home Assistanta, odczytać poziom baterii i zbudować automatyzację wyłączającą Proxmoxa przy określonym progu.
→ Home Assistant wykrywa stan
→ wysyła polecenie shutdown
Nie budowałbym na tym jedynej procedury ratunkowej.
Home Assistant jest jedną z usług, które próbuję ochronić. Jeśli problem dotyczy HAOS, sieci, Supervisor albo samego Home Assistanta, automatyzacja może nie wykonać się właśnie wtedy, kiedy jest najbardziej potrzebna.
Warstwa infrastruktury odpowiada za bezpieczny shutdown. Home Assistant może pokazywać stan UPS-a, zapisywać dane i wysyłać dodatkowe powiadomienia, ale nie jest jedynym elementem potrzebnym do uratowania hosta.
Po bezpiecznym shutdownie host musi jeszcze umieć ponownie wystartować
W części 1 pisałem o ustawieniu BIOS odpowiedzialnym za zachowanie komputera po powrocie zasilania. To bardzo ważna opcja w serwerze działającym bez operatora.
Istnieje jednak mniej oczywisty scenariusz.
Wyobraźmy sobie, że NUT poprawnie wyłączył Proxmoxa, gdy bateria była już niska. Host jest wyłączony, ale UPS nadal przez jakiś czas podaje napięcie na swoje wyjście.
Jeśli w tym momencie wróci zasilanie sieciowe, z punktu widzenia zasilacza mini-PC napięcie mogło nigdy nie zniknąć. BIOS nie zobaczy więc klasycznego zdarzenia powrotu AC i komputer może pozostać wyłączony.
Poprawna procedura NUT może obejmować również końcowe sterowanie obciążeniem UPS-a tak, aby po shutdownie odciąć zasilanie urządzeń i ponownie je podać po powrocie sieci. To jednak zależy od konkretnego modelu UPS-a, użytego sterownika i obsługiwanych przez urządzenie komend.
NUT definiuje między innymi operacje w rodzaju shutdown.return, czyli wyłączenie obciążenia i ponowne załączenie po powrocie zasilania. Nie oznacza to jednak, że każdy UPS z gniazdem USB obsługuje tę funkcję.
Dlatego przy zakupie sprawdzam nie tylko VA, waty i deklarowany czas podtrzymania. Interesuje mnie również kompatybilność z NUT, obsługiwany driver oraz komendy dostępne dla konkretnego urządzenia.
Proxmox potrafi zamknąć VM w odpowiedniej kolejności
Jeżeli na hoście mam tylko HAOS i kilka niezależnych usług, kolejność shutdownu nie jest szczególnie skomplikowana.
Sytuacja zmienia się, kiedy jedna maszyna zależy od drugiej. Jeśli na przykład Recorder korzysta z MariaDB działającej w osobnym LXC, baza powinna pozostać dostępna, kiedy Home Assistant kończy pracę.
Proxmox pozwala ustawić Start/Shutdown Order oraz opóźnienia. Przy wyłączaniu kolejność jest odwracana.
baza / infrastruktura → Home Assistant → usługi zależne
SHUTDOWN:
usługi zależne → Home Assistant → baza / infrastruktura
Jeśli MQTT, Zigbee2MQTT i baza działają jako Apps wewnątrz jednego HAOS, Proxmox nie musi znać tych wewnętrznych zależności. Supervisor zarządza nimi wewnątrz VM. Nie dokładam konfiguracji tylko dlatego, że istnieje taka możliwość.
Backup VM nie jest backupem konfiguracji hosta Proxmox
Mam backup Home Assistanta. Mam backup całej VM. Pada dysk systemowy hosta Proxmox.
Maszynę mogę odtworzyć, ale najpierw muszę przygotować hypervisor. Muszę wiedzieć, jak wyglądała sieć, storage, bridge, passthrough i pozostałe elementy hosta.
Bardzo duża część konfiguracji PVE znajduje się w rozproszonym systemie plików pmxcfs, widocznym pod /etc/pve.
W scenariuszu poważnej awarii hosta oficjalna dokumentacja Proxmoxa wskazuje również na bazę /var/lib/pve-cluster/config.db jako kluczowy element odzyskania konfiguracji pmxcfs.
Oprócz tego interesuje mnie konfiguracja sieci hosta, nazwy bridge, storage oraz informacje o urządzeniach przekazywanych do VM.
W strukturze Proxmoxa znajdują się między innymi dane uwierzytelniające, konfiguracja 2FA, sekrety tokenów API, klucze oraz hasła wybranych storage. Takiej kopii nie wrzucam bez zabezpieczenia do przypadkowego katalogu w chmurze.
Plan odbudowy jest ważniejszy niż efektowny skrypt backupu
Mogę napisać skrypt kopiujący pół systemu plików. Jeśli po awarii nie wiem, co z tymi plikami zrobić, niewiele zyskałem.
Wolę mieć prostą, przetestowaną kolejność:
↓
świeży Proxmox
↓
konfiguracja sieci
↓
podłączenie storage z backupami
↓
restore HAOS VM
↓
odtworzenie USB / passthrough
↓
uruchomienie HAOS
↓
test najważniejszych funkcji domu
Jeśli znam tę drogę, awaria dysku systemowego jest serią konkretnych czynności, a nie próbą przypomnienia sobie konfiguracji serwera sprzed kilku lat.
Plan awaryjny samego Home Assistanta rozpisuję osobno w lekcji
Plan awaryjny: co robisz, gdy Home Assistant nie wstaje
.
Drobny szczegół podczas restore: nazwy bridge i storage
Maszyna może mieć kartę sieciową przypisaną do bridge o konkretnej nazwie. Dysk VM może znajdować się na storage o konkretnym identyfikatorze.
Na świeżym hoście te nazwy nie muszą być identyczne.
Backup maszyny nadal jest poprawny, ale podczas restore będę musiał wskazać, gdzie ma trafić dysk i do jakiego bridge ma zostać podłączona karta sieciowa.
Nie tylko adres IP. Zachowuję również nazwy bridge i storage, podstawowe parametry VM, informacje o USB passthrough i inne dane potrzebne do odtworzenia systemu na świeżym hoście.
Jeden mini-PC nadal jest jednym fizycznym punktem awarii
Wirtualizacja daje ogromną wygodę. Backupy, testowa VM, łatwe zwiększanie zasobów i oddzielenie usług powodują, że niewielki komputer może obsługiwać sporą część infrastruktury domu.
Ale jeden host nadal pozostaje jednym hostem.
Jeśli padnie płyta główna, zasilanie albo podstawowa komunikacja sieciowa, wszystkie działające na nim maszyny mogą zniknąć jednocześnie.
Nie traktuję więc samego faktu używania Proxmoxa jako High Availability.
Nie tylko po to, żeby mieć „HA dla HA”. Klaster oznacza quorum, dodatkowe zależności sieciowe, kolejne hosty, migrację i często bardziej skomplikowany storage. Dla wielu domów dobry backup, przetestowany restore i możliwość użycia sprzętu zastępczego będą rozwiązaniem prostszym i bardziej racjonalnym.
Nie odcinam zasilania hosta przy pierwszym nieudanym pingu
Automatyzacja bardzo łatwo może tutaj zrobić więcej szkody niż pożytku.
Wyobraźmy sobie, że Home Assistant przez minutę nie odpowiada. Inny system monitoringu uznaje, że Proxmox się zawiesił i wysyła do inteligentnego gniazdka polecenie odcięcia 230 V.
Problem może jednak leżeć w DNS, switchu, firewallu, konkretnym interfejsie albo samym systemie monitoringu. Brutalne odcięcie zasilania działającego hypervisora jest wtedy najgorszą możliwą reakcją.
Najpierw potwierdzam, że problem rzeczywiście dotyczy hosta. Jeśli Proxmox odpowiada administracyjnie, korzystam z normalnego shutdownu albo restartu zamiast odcinać mu zasilanie.
Home Assistant powinien działać lokalnie również bez Internetu
Odporność na awarie nie kończy się na Proxmoxie i UPS-ie.
Jeśli operator ma awarię, chcę nadal zapalić światło, sterować roletami, korzystać z Zigbee i wykonywać większość lokalnych automatyzacji.
Zdalny dostęp może wtedy przestać działać. Integracje zależne od usług chmurowych również mogą stracić połączenie. To normalne.
Jeżeli jednak utrata WAN wyłącza większość podstawowych funkcji domu, problemem nie jest już sam Internet. Problemem jest architektura zbyt mocno zależna od zewnętrznych usług.
LAN, WAN, NAT, CGNAT i metody bezpiecznego dostępu zdalnego porządkuję w lekcji
Dostęp zdalny do Home Assistant
.
Moja docelowa warstwa bezpieczeństwa nie jest szczególnie egzotyczna
Po przeczytaniu kilku dyskusji o hardeningu łatwo dojść do wniosku, że domowy Proxmox wymaga bastion hosta, rozbudowanego IDS i kilkuset reguł firewalla.
Ja zaczynam od rzeczy, które rzeczywiście zmieniają powierzchnię ataku i odporność instalacji.
✓ zdalny management przez VPN,
✓ 2FA dla panelu,
✓ klucze SSH,
✓ ograniczone tokeny API dla monitoringu,
✓ firewall ograniczający dostęp do managementu,
✓ regularne aktualizacje,
✓ backup VM poza głównym storage,
✓ kopia kluczowej konfiguracji hosta,
✓ powiadomienia o błędach,
✓ monitoring dysku i wolnego miejsca,
✓ UPS z kontrolowanym shutdownem,
✓ udokumentowany plan restore.
Fail2Ban, niestandardowy port SSH, bardziej rozbudowane IDS czy osobny jump host mogą być wartościowymi dodatkami. Nie zastępują jednak żadnego z powyższych fundamentów.
Co sprawdzam okresowo zamiast tylko czekać na awarię?
| Element | Co sprawdzam | Dlaczego |
|---|---|---|
| Backup VM | ostatnie poprawne wykonanie | potrzebuję aktualnego punktu odtworzenia |
| Backup HA | lokalizacja i możliwość restore | sam plik nie daje jeszcze pewności odzyskania |
| SSD | SMART i błędy I/O | wczesne sygnały problemów storage |
| Storage | wolne miejsce | VM i backup potrzebują przestrzeni roboczej |
| Proxmox | aktualizacje i błędy | nie chcę wieloletniego długu technicznego |
| HAOS | System Health i Repairs | problem może istnieć wewnątrz gościa |
| UPS | bateria, komunikacja i test shutdownu | zabezpieczenie musi działać także w praktyce |
Najważniejszy test wykonuję wtedy, kiedy wszystko działa
Najgorszy moment na naukę recovery to dzień, w którym właśnie padł dysk.
Dlatego przynajmniej raz chcę odpowiedzieć sobie na kilka prostych pytań:
↓
wiem, gdzie fizycznie się znajduje?
↓
mam klucze, hasła i kody odzyskiwania?
↓
mam lokalny dostęp do hosta?
↓
wiem, jak odtworzyć sieć i storage?
↓
potrafię przywrócić HAOS?
↓
wiem, co zrobić z Zigbee i USB po zmianie hosta?
To ostatnie pytanie prowadzi nas już bezpośrednio do kolejnej części tej serii.
Czego nie robię tylko dlatego, że znalazłem poradnik o hardeningu
✕ publicznego SSH tylko dlatego, że zmieniłem jego port,
✕ wyłączania root SSH według poradnika dla zwykłego Debiana bez sprawdzenia konsekwencji dla PVE,
✕ przekazywania hasła root systemowi monitoringu,
✕ instalowania przypadkowych usług bezpośrednio na hoście,
✕ włączania skomplikowanego firewalla bez lokalnej drogi ratunkowej,
✕ tworzenia VLAN-ów bez rozpisania potrzebnych przepływów,
✕ automatycznego odcinania 230 V po jednym nieudanym pingu,
✕ traktowania dowolnego UPS-a z USB jako gwarancji pełnej obsługi NUT,
✕ budowania klastra Proxmox tylko po to, żeby mieć „HA dla HA”.
VPN, firewall, 2FA, backup, UPS i segmentacja rozwiązują różne problemy. Jeśli dokładam kolejną warstwę, chcę wiedzieć, przed czym mnie chroni i jak ją naprawić, kiedy sama przestanie działać.
Moja checklista dla produkcyjnego Proxmoxa z Home Assistant
✓ Proxmox nie jest bezpośrednio dostępny z WAN.
✓ Zdalny management działa przez VPN.
✓ Konto administracyjne ma 2FA.
✓ Dane odzyskiwania są przechowywane poza hostem.
✓ SSH wykorzystuje klucze.
✓ Monitoring korzysta z ograniczonych uprawnień i tokenów.
✓ Host pozostaje możliwie czystym hypervisorem.
✓ Proxmox jest regularnie aktualizowany.
✓ Backup VM znajduje się poza głównym storage.
✓ Mam kopię informacji potrzebnych do odtworzenia hosta.
✓ Powiadomienia rzeczywiście do mnie docierają.
✓ Monitoruję stan dysku i wolne miejsce.
✓ Docelowo infrastruktura ma UPS i kontrolowany shutdown.
✓ Wiem, jak odtworzyć system na świeżym hoście.
FAQ: bezpieczeństwo Home Assistanta na Proxmoxie
Czy można wystawić port 8006 Proxmoxa do Internetu?
Technicznie można, ale w domowej instalacji nie jest to rozwiązanie, które wybieram. Panel hypervisora trzymam w zaufanej sieci administracyjnej i wchodzę do niej zdalnie przez VPN.
Czy warto zmienić port SSH w Proxmoxie?
Można to zrobić, ale nie traktuję zmiany portu jako ważnej warstwy bezpieczeństwa. Znacznie większe znaczenie mają klucze SSH, firewall, VPN i ograniczenie dostępu do warstwy administracyjnej.
Czy Proxmox powinien mieć 2FA?
Dla kont z pełnymi prawami administracyjnymi uważam 2FA za bardzo rozsądną podstawę. Równie ważne jest bezpieczne przechowywanie danych potrzebnych do odzyskania dostępu.
Czy Home Assistant może wyłączyć Proxmoxa przy rozładowaniu UPS-a?
Może, ale nie budowałbym na Home Assistant jedynego mechanizmu awaryjnego shutdownu. Procedura ochrony hypervisora powinna działać w warstwie infrastruktury, niezależnie od kondycji HAOS.
Czy backup VM wystarczy do odzyskania Proxmoxa?
Nie. Backup VM chroni zawartość maszyny, ale nie odtwarza automatycznie całej konfiguracji fizycznego hosta, jego sieci, storage, firewalla i passthrough.
Czy Home Assistant potrzebuje klastra Proxmox?
W typowym domu nie. Pojedynczy dobrze utrzymany host, aktualne backupy i sprawdzona procedura restore mogą być znacznie prostszym rozwiązaniem niż klaster tworzony bez realnej potrzeby.
Co dalej w części 4?
Fundament hosta jest gotowy. Baza i backup są uporządkowane. Wiemy, jak chronić Proxmoxa i co ma się wydarzyć podczas awarii zasilania.
Zostaje temat, który w Proxmoxie wywołuje chyba najwięcej dyskusji wśród użytkowników Home Assistanta:
Sprawdzimy USB passthrough, stabilne mapowanie urządzeń, Sonoff Dongle, koordynatory Ethernet i PoE, Zigbee2MQTT jako App kontra osobny LXC, MQTT, Frigate, Intel iGPU oraz najważniejsze pytanie: kiedy separacja zwiększa niezawodność, a kiedy tylko zwiększa liczbę rzeczy do administrowania.
Na koniec
Bezpieczeństwo takiej instalacji nie sprowadza się dla mnie do silnego hasła i zmiany portu SSH.
Interesuje mnie również, co stanie się po awarii SSD, utracie zasilania, błędzie firewalla, nieudanej aktualizacji, uszkodzeniu hosta albo utracie dostępu do konta.
Proxmox daje świetne narzędzia do izolacji, backupu i odzyskiwania. Trzeba tylko pamiętać, że sam hypervisor również staje się krytycznym elementem infrastruktury domu.
Część 1: Home Assistant na Proxmoxie, dobre praktyki dla HAOS VM
Część 2: SQLite czy MariaDB, Recorder, InfluxDB i backup
E-learning: bezpieczeństwo Home Assistant
E-learning: bezpieczny dostęp zdalny do Home Assistant
E-learning: oddzielenie urządzeń IoT od komputerów
