Zdalnie zarządzasz węzłem Proxmox. Interfejs webowy odpowiada na TCP 8006, SSH na TCP 22, a włączenie zapory ogniowej natychmiast stawia dobre pytanie: z jakiego źródła administracyjnego możesz jeszcze się dostać, jeśli brakuje reguły?
Procedura jest celowo ograniczona: konsola IPMI, KVM lub lokalna, inwentaryzacja istniejącego stanu, zakres management, uprawnienia 8006 i 22, kompilacja, symulacja, a następnie aktywacja jednego poziomu. Testujesz z nowego połączenia, zanim pójdziesz dalej.
Zapora Proxmox działa na kilku poziomach
Proxmox rozróżnia poziomy Datacenter, Node i VM/CT. Plik /etc/pve/firewall/cluster.fw zawiera współdzieloną konfigurację klastra. Plik /etc/pve/nodes/<nodename>/host.fw dotyczy konkretnego węzła. Reguły VM i kontenerów znajdują się w /etc/pve/firewall/<VMID>.fw.
Reguły węzła mogą pochodzić z Datacenter lub pliku hosta. Poziom hosta ma priorytet nad poziomem Datacenter. Dla tej pierwszej aktywacji, najpierw zabezpiecz dostęp do węzła i nie mieszaj Datacenter, Node i VM/CT w tej samej zmianie.
Dokumentacja Proxmox wskazuje, że zapora jest domyślnie wyłączona na poziomie klastra z enable: 0. Po włączeniu, ruch do hostów jest domyślnie blokowany, za wyjątkiem dokumentowanych wyjątków, jak ruch lokalny, ustalone połączenia i niektóre wewnętrzne przepływy. Zdalny dostęp do 8006 lub 22 musi więc opierać się na zidentyfikowanym źródle administracyjnym.
Przygotuj konsolę i inwentaryzuj istniejący stan
Przed zastosowaniem jakiejkolwiek polityki restrykcyjnej, otwórz niezależną konsolę: IPMI, KVM, dostęp lokalny lub konsolę dostarczoną przez dostawcę. Otwarte sesje SSH pomagają obserwować zmiany, ale nie stanowią prawdziwej pomocy, jeśli korzystają z tej samej sieci co twój zwykły dostęp.
Z węzła zidentyfikuj nazwę, adresy, trasę i bieżący stan zapory ogniowej:
hostname
ip -br address
ip route
pve-firewall statusOdnotuj adres IP rzeczywiście używany przez twoje stanowisko, VPN lub bastion administracyjny. Nie ograniczaj się do IP węzła: reguła musi rozpoznać źródło przychodzącego połączenia.
Jeśli ścieżka zarządzania nadal przechodzi przez most Proxmox do zmiany, traktuj tę modyfikację osobno za pomocą przewodnika dotyczącego konfiguracji mostu sieciowego Proxmox. Zapora nie powinna być używana do jednoczesnego korygowania zmiany interfejsu lub bramy.
Zdefiniuj źródła administracyjne
Standardowy IPSet management stosuje się do zapór hostów. Może on grupować publiczny adres IP administracyjny lub podsieć używaną dla interfejsu webowego, VNC, SPICE i SSH. Lokalne sieci klastra są automatycznie dodawane poprzez alias cluster_network dla komunikacji między hostami.
Przykład dokumentu w /etc/pve/firewall/cluster.fw wygląda tak:
[IPSET management]
203.0.113.10
192.0.2.0/24203.0.113.10 oraz 192.0.2.0/24 to wartości przykładowe. Zamień je na swoje rzeczywiste źródło, a następnie sprawdź adres, z którego otwierasz nową sesję. Zmieniające się IP publiczne, VPN wychodzący z innego zakresu lub zapomniany bastion wystarczy, aby reguła przestała działać.
Nie otwieraj 0.0.0.0/0 do portu 8006 jako standardowe ustawienie. Tego typu szeroki wyjątek uzasadniony jest tylko w izolowanym laboratorium, a nie na produkcyjnym węźle dostępnym zdalnie.
Zezwól na Web UI i SSH na poziomie hosta
Dwoma dostępami administracyjnymi, które należy najpierw załatwić, są interfejs webowy Proxmox na TCP 8006 oraz SSH na TCP 22. Umieść reguły na poziomie hosta lub Datacenter w zależności od twojej organizacji, ponownie wykorzystując IPSet +management.
[RULES]
IN ACCEPT -source +management -p tcp -dport 8006
IN ACCEPT -source +management -p tcp -dport 22Ten blok ilustruje ukierunkowane reguły przychodzące. Zachowaj politykę przychodzącą jako pobłażliwą podczas pierwszego testu, jeśli IPSet nie został jeszcze zweryfikowany. Utwardzenie przychodzi po udowodnieniu dostępu, a nie przed.
SPICE używa TCP 3128, a konsola VNC Web używa TCP 5900-5999. Dodaj te potrzeby tylko wtedy, gdy twoja administracja faktycznie z nich korzysta. W klastrze nie zepsuj też Corosync na UDP 5405-5412 ani migracji na TCP 60000-60050.
IPSet management dotyczy hostów. Nie konfiguruje reguł VM i kontenerów. Szczegółowe reguły IN i OUT dla gości pozostają oddzielnym zagadnieniem.
Kompiluj, symuluj, a następnie aktywuj tylko jeden poziom
Przed aktywacją, wyświetl skompilowane reguły:
pve-firewall compile
pve-firewall statuspve-firewall status ponownie odczytuje i kompiluje pełną konfigurację. Ostrzeżenia, które wyświetla, muszą zostać rozwiązane przed zmianą. Czysta kompilacja nie dowodzi jeszcze, że twoje zdalne źródło może połączyć się z 8006 lub 22, ale błąd konfiguracji wystarczy już by wstrzymać sekwencję.
Następnie możesz symulować dwa dostępy administracyjne z rzeczywistym adresem administratora i adresem węzła:
pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 8006 --protocol tcp
pve-firewall simulate --from outside --to host --source <IP_ADMIN> --dest <IP_NOEUD> --dport 22 --protocol tcpSymulacja testuje reguły z dostarczonym źródłem, docelowym, portem i protokołem. Nie symuluje tablicy routingu jądra. Pozytywny wynik nie zastępuje więc ani konsoli ratunkowej, ani prawdziwego testu z nowego połączenia.
Następnie aktywuj Datacenter lub Node, tylko jeden poziom na raz, z Datacenter > Firewall lub Node > Firewall. Jeśli korzystasz z pliku klastra, dokumentowana aktywacja wygląda tak:
[OPTIONS]
enable: 1Nie przechodź od razu do plików VM. Pierwsza zmiana musi odpowiedzieć na jedno pytanie: czy dostęp administracyjny do węzła pozostaje dostępny z autoryzowanego źródła?
Testuj z nowego połączenia
Po aktywacji, otwórz nowe okno i załaduj https://<ip-noeud>:8006/. Uruchom również nową sesję SSH z źródła umieszczonego w management. Starsza sesja pozostaje otwarta podczas tych dwóch kontroli.
Następnie sprawdź stan zapory:
pve-firewall statusNa starszym backendzie, iptables-save umożliwia odczytanie wygenerowanych reguł. Użyj go, aby obserwować, a nie edytować bezpośrednio łańcuchów produkowanych przez Proxmox. Artykuł dotyczący odczytu reguł iptables w Linuxie obejmuje tę kontrolę niskiego poziomu.
Zamknij starą sesję dopiero po potwierdzeniu, że Web UI działa oraz po nawiązaniu nowego połączenia SSH. Jeśli test się nie powiedzie, użyj niezależnej konsoli, aby usunąć problematyczną regułę lub dezaktywować opcję na włączonym poziomie.
Uwaga: pve-firewall stop aktywnie usuwa reguły Proxmox VE powiązane z iptables. Host może wtedy pozostać bez ochrony. To krok w ramach działań naprawczych, nie jest to jednak rekomendowany stan końcowy.
Zatrzymaj się przed regułami VM
Na tym etapie zapewniłeś zabezpieczenie kolejności aktywacji i zweryfikowałeś dostęp administracyjny węzła. Zatrzymaj się tutaj, jeśli twoim celem było skonfigurowanie zapory Proxmox bez lockoutu.
- Szczegółowe reguły VM i kontenerów należą do tematu dedykowanego regułom zapory VM Proxmox.
- Zablokowana sieć wymaga odrębnej diagnostyki, z własnym zakresem i kontrolami.
- Szczegółowe odczytanie logów zapory będzie przedmiotem innego artykułu.
- Przypadek już zablokowanego dostępu SSH nie powinien być mieszany z tą prewencyjną aktywacją.
Backend nftables proxmox-firewall pozostaje przeglądem technologicznym według oficjalnej dokumentacji, z możliwymi błędami lub niekompatybilnościami. Nie wybieraj go jako drogi produkcyjnej dla tej pierwszej aktywacji.
Jeśli VM później straci łączność, diagnostyka nie dotyczy już dostępu administracyjnego węzła. Należy wtedy wrócić do tematu sieci VM w artykuł poświęcony wirtualnej karcie sieciowej Proxmox.
