U beheert een Proxmox-knooppunt op afstand. De web UI reageert op TCP 8006, SSH op TCP 22, en het inschakelen van de firewall roept onmiddellijk de juiste vraag op: via welke beheersbron kunt u nog toegang krijgen als er een regel ontbreekt?
De procedure blijft opzettelijk beperkt: IPMI-console, KVM of lokaal, inventarisatie van de bestaande situatie, bereik management, machtigingen 8006 en 22, compilatie, simulatie, en dan activatie van slechts één niveau. U test vanuit een nieuwe verbinding voordat u verder gaat.
De Proxmox-firewall werkt op verschillende niveaus
Proxmox maakt onderscheid tussen de niveaus Datacenter, Node en VM/CT. Het bestand /etc/pve/firewall/cluster.fw bevat de gedeelde configuratie van het cluster. Het bestand /etc/pve/nodes/<nodename>/host.fw betreft een specifiek knooppunt. De VM- en containerregels bevinden zich in /etc/pve/firewall/<VMID>.fw.
De regels van het knooppunt kunnen afkomstig zijn van het Datacenter of van het hostbestand. Het hostniveau heeft prioriteit boven het Datacenter-niveau. Voor deze eerste activatie, bescherm eerst de toegang tot het knooppunt en meng het Datacenter, Node en VM/CT niet in dezelfde wijziging.
De Proxmox-documentatie geeft aan dat de firewall standaard is uitgeschakeld op cluster-niveau met enable: 0. Eenmaal ingeschakeld wordt het verkeer naar de hosts standaard geblokkeerd, met uitzondering van gedocumenteerde gevallen zoals lokaal verkeer, gevestigde verbindingen en bepaalde interne stromen. Toegang op afstand naar 8006 of 22 moet dus steunen op een geïdentificeerde beheersbron.
Bereid de console voor en inventariseer de bestaande situatie
Voordat u een restrictief beleid instelt, opent u een onafhankelijke console: IPMI, KVM, lokale toegang of console verstrekt door de host. Een geopende SSH-sessie helpt om de wijziging te observeren, maar is geen echte hulp als deze via hetzelfde netwerk gaat als uw gebruikelijke toegang.
Vanaf het knooppunt, inventariseer de naam, adressen, route en de huidige status van de firewall:
hostname
ip -br address
ip route
pve-firewall statusNoteer het IP-adres dat daadwerkelijk door uw werkstation, uw VPN of uw beheersbastion wordt gebruikt. Neem niet alleen het IP van het knooppunt: de regel moet de bron van de binnenkomende verbinding herkennen.
Als het beheerpunt nog steeds via een Proxmox-brug gaat die moet worden gewijzigd, behandel deze wijziging separaat met de handleiding over de configuratie van een Proxmox-netwerkbrug. De firewall mag niet worden gebruikt om tegelijkertijd een wijziging aan de interface of gateway te corrigeren.
Definieer de beheersbronnen
De standaard IPSet management is van toepassing op de host-firewalls. Het kan het publiek IP-adres van beheer of het subnet van de VPN die wordt gebruikt voor de web UI, VNC, SPICE en SSH groeperen. Het lokale cluster netwerk wordt automatisch toegevoegd via de alias cluster_network voor communicatie tussen hosts.
Een documentvoorbeeld in /etc/pve/firewall/cluster.fw ziet er als volgt uit:
[IPSET management]
203.0.113.10
192.0.2.0/24203.0.113.10 en 192.0.2.0/24 zijn voorbeeldwaarden. Vervang ze door uw echte bron en controleer vervolgens het adres waarmee u de nieuwe sessie opent. Een veranderend publiek IP, een VPN die door een ander bereik uitkomt of een vergeten bastion is voldoende om de regel niet-operationeel te maken.
Open 0.0.0.0/0 niet naar poort 8006 als normale instelling. Deze brede uitzondering is alleen gerechtvaardigd in een geïsoleerd en gecontroleerd laboratorium, niet op een productieknooppunt dat op afstand toegankelijk is.
Sta Web UI en SSH toe op hostniveau
De twee beheertoegangen die als eerste moeten worden behandeld zijn de Proxmox-web UI op TCP 8006 en SSH op TCP 22. Plaats de regels op host- of Datacenter-niveau, afhankelijk van uw organisatie, door de IPSet +management opnieuw te gebruiken.
[RULES]
IN ACCEPT -source +management -p tcp -dport 8006
IN ACCEPT -source +management -p tcp -dport 22Dit blok illustreert gerichte inkomende regels. Houd de inkomende beleidslijn permissief tijdens de eerste test als de IPSet nog niet is gecontroleerd. Het verhardingsproces komt na het bewijs van toegang, niet ervoor.
SPICE gebruikt TCP 3128 en de VNC-webconsole gebruikt TCP 5900-5999. Voeg deze behoeften alleen toe als uw beheer ze daadwerkelijk gebruikt. Breek ook Corosync niet in een cluster op UDP 5405-5412 of de migratie op TCP 60000-60050.
De IPSet management betreft de hosts. Het configureert geen regels voor de VM’s en containers. De IN en OUT regels van gasten zijn een ander project.
Compileer, simuleer, en activeer vervolgens slechts één niveau
Voordat u deze activeert, laat u de gecompileerde regels weergeven:
pve-firewall compile
pve-firewall statuspve-firewall status leest en compileert de volledige configuratie. De waarschuwingen die het weergeeft moeten worden behandeld voordat de wijziging. Een schone compilatie bewijst nog niet dat uw externe bron 8006 of 22 kan bereiken, maar een configuratiefout is al voldoende om de sequentie te stoppen.
U kunt vervolgens de twee beheertoegangen simuleren met het werkelijke adres van de beheerder en dat van het knooppunt:
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 tcpDe simulatie test de regels met de gegeven bron, bestemming, poort en protocol. Het simuleert de routetabel van de kernel niet. Een gunstig resultaat vervangt dus noch de noodconsole, noch een echte test vanuit een nieuwe verbinding.
Schakel vervolgens Datacenter of Node in, slechts één niveau tegelijk, via Datacenter > Firewall of Node > Firewall. Als u het clusterbestand gebruikt, wordt de gedocumenteerde activatie als volgt geschreven:
[OPTIONS]
enable: 1Ga niet direct naar de VM-bestanden. De eerste wijziging moet één vraag beantwoorden: blijft de beheertoegang van het knooppunt bereikbaar via de geautoriseerde bron?
Testen met een nieuwe verbinding
Na de activatie opent u een nieuw venster en laadt u https://<ip-noeud>:8006/. Start ook een nieuwe SSH-sessie vanaf de bron die in management is geplaatst. De oude sessie blijft open tijdens deze twee controles.
Controleer vervolgens de status van de firewall:
pve-firewall statusOp de oude backend stelt iptables-save u in staat om de gegenereerde regels te lezen. Gebruik het om te observeren, niet om de door Proxmox geproduceerde ketens direct te bewerken. Het artikel over het lezen van iptables-regels onder Linux behandelt deze laagdrempelige controle.
Sluit de oude sessie pas af nadat de Web UI en een nieuwe SSH-verbinding zijn gevalideerd. Als de test mislukt, gebruik dan de onafhankelijke console om de onjuiste regel te verwijderen of de optie op het ingeschakelde niveau te deactiveren.
Let op: pve-firewall stop verwijdert actief de Proxmox VE-regels die aan iptables zijn gekoppeld. De host kan dan zonder bescherming blijven. Dit is een ingekaderde herstelhandeling, geen aanbevolen eindstatus.
Stop vóór de regels van de VM
Op dit punt heeft u de activatievolgorde beveiligd en de beheertoegang tot het knooppunt gecontroleerd. Stop hier als uw doel was om de Proxmox-firewall op te zetten zonder lockout.
- De gedetailleerde regels van de VM en containers vallen onder het onderwerp van de specifieke regels voor Proxmox-VM-firewalls.
- Een geblokkeerd netwerk vereist een afzonderlijke diagnose, met zijn eigen bereik en controles.
- De gedetailleerde lezing van de firewall-logs zal in een ander artikel worden behandeld.
- De situatie van een SSH-toegang die al geblokkeerd is, mag niet worden gemengd met deze preventieve activatie.
De backend nftables proxmox-firewall blijft een tech preview volgens de officiële documentatie, met mogelijke bugs of incompatibiliteit. Kies het niet als productiepad voor deze eerste activatie.
Als een VM daarna zijn connectiviteit verliest, heeft de diagnose geen betrekking meer op de beheertoegang van het knooppunt. U moet dan het netwerkw vraagstuk van de VM opnieuw oppakken in het artikel gewijd aan de virtuele netwerkadapter van Proxmox.