Dokumentation
Dokumentation von den Kursen von sysops
- Proxmox
- Kopie OPNSense Workshop - Vorumstellung auf markdown
- Verschlüsselung mit Proxmox, ZFS und Debian / Windows
- Proxmox Best Practice Setup für ZFS und / oder Ceph im Cluster für Einsteiger (Stand Dezember 2024)
- ZFS Grundlagen am Beispiel Proxmox VE(Stand Januar 2025)
- OPNsense Migration Legacy zu Instance, ohne neues Ausrollen von Konfigurationen
Proxmox
Die Dokumentation für "Proxmox Produktiv mit ZFS betreiben" basiert auf einem kostenpflichtigen Kurs und soll dessen Inhalte wiedergeben, kann aber nicht die Betreuung und Beantwortung von Fragen, wie sie der Besuch des Kurses bietet, ersetzen. Es soll das Wissen von den hauptberuflichen Sysops Admins an Interessierte weitergegeben werden, die es danach auf den von Ihnen betreuten Systemen umsetzen können.
https://cloudistboese.de - Das Schulungsportal von sysops.tv
Proxmox VE - Alternative zu vSphere und Hyper-V mit Support aus Deutschland und Österreich
Was ist Proxmox VE
- Proxmox VE ist eine Gesamtlösung zur Virtualisierung
- Einsatzbereiche Standalone bis Cluster
- Es beinhaltet entscheidende Storagefunktionen mit ZFS und Ceph
- Umfangreiche Virtualisierung und Containering Lösung
- Moderner Unterbau mit aktuellem Debian Linux
- Reichhaltige Funktionen die durch eigene Kommandozeilenlösungen erweitert werden
Wo sind die Grenzen von Proxmox VE
- Kaum bis keine Funktionen in der GUI für Storage Steuerung und Monitoring
- Viele Funktionen lassen sich nur per Kommandozeile ausführen
- Es gibt keine Möglichkeit ein defektes System per Installation zu reparieren, Reparaturkenntnisse müssen vorhanden sein
- Das Eigenmonitoring ist so gut wie nicht vorhanden. Defekte Replikationen, Raids oder Datenträger nur mühsam feststellbar
Weitere Funktionen, die eher weniger Sinn machen
- SAN mit iSCSI (keine GUI)
- SAN mit NFS (beste Option)
- Hardware Raid mit LVM (kein Vorteil zu ZFS / CEPH)
- Multipath nur per manueller Konfiguration
Indikation für Einsatz
- Kleinere Anzahl von PVE Systemen mit direkt angeschlossenen Datenträgern (kein Hardware Raid!)
- Hoher Bedarf an Reparatur durch Snapshots (tausende Snapshots kein Problem)
- Leichte Replikation der Daten auf zweites System und eventuelle weitere Ziele (mit Bashclub Tools und GUI möglich, Pull Replikation nur mit unseren Tools)
- Hauseigene Datensicherungslösung auf Hypervisor Ebene
- Eigenes Monitoring und Reporting bevorzugt - Zentrales Monitoring wie Check_MK ist zwingend notwendig
** Bei Proxmox kommt alles aus den Kernel (ZFS, Ceph, LXC, KVM, uvm.) **
Linux Kommandos die man kennen sollte
- lsblk #zeigt Datenträger und Partitionen an
- ls -althr /dev/disk/by-id # zeigt Festplatten Aliase zum eindeutigen Zuweisen von Raids an
- ls -althr /sys/class/net #zeigt aktuelle Netzwerkkarten an
- ls -althr /dev/zvol/rpool/data # zeigt ZVOL Namenszuordnungen zu /dev/zdxxx an
- dmesg -Tw #zeigt Hardwareänderungen wie Diskwechsel oder Netzwerkkabel stecken live an
- systemctl --failed #zeigt hängende dienste an
- htop #zeigt load an. hier sollten die drei Zahlen unter der Anzahl der logischen Kerne sein. Also 16 Kerne, Load unter 16. Erste Zahl letze Minute, zweite Zahl letze fünf Minuten, dritte für letzte Viertelstunde
- zpool list # hier muss der Wert Cap unter 80% liegen, sonst müssen Snapshots oder sogar produktive Daten gelöscht werden
- zpool status #Raid Status
- zfs list -t snapshot #z. B. mit -oname,written,creation rpool/data/vm-100-disk-1
- qm stop 100 && zfs rollback rpool/data/subvol-100-disk-0@zfs-auto-snap_hourly-2024-10-24-0217 && qm start 100 # Rollback ohne Widerkehr der Daten einer VM
Proxmox Installation
Um Proxmox mit ZFS nutzen zu können, müssen die Platten direkt an Proxmox angebunden werden. Es sollte kein RAID Controller mit RAID 0 genutzt werden, da dies früher oder später zu Problemen und Datenverlusten führen wird! Damit auch eine Update von Promox 7.x auf 8.x gezeigt werden kann, wird im Kurs mit der Installation einer Proxmox Version 7.x begonnen und später auf 8 aktualisiert. Das Postinstall Script aus dem Bashclub wird installiert, um auch alle benötigten Tools für die tägliche Arbeit und im Problemfall im Zugriff zu haben. (z.B. ohne ein Netzwerkverbindung kann nichts mehr nachinstalliert werden)
Spickzettel für Installation
- Kein RAID Controller
- Platten direkt an Proxmox geben, es müssen die Herstellerbezeichnung der Platten im Linux Betriebssystem sichtbar sein. (z.B. nvme-INTEL_... über das Kommando
ls /dev/disk/by-id
) - ISO Installation mit Version 7.x
- Install Proxmox starten
- Die Standardauswahl im Installer würde LVM auf eine Disk installieren, was nur für Hardware Raid Sinn machen würde
- ZFS RAID 1 oder ZFS RAID 10 sind die empholenen Level für die Beste Leistung, haben jedoch einen Platzverlust von 50%, was in der Natur liegt
- Advanced Options - ZFS Optionen können default gelassen werden, ashift=12 + compression=on passt für alle Platten über 2TB
- Passwort muss sich in der HTML Console gut tippen lassen - HTML und JAVA Konsolen sind hier sehr schwierig mit deutsch Tastatur! Testen!
- Die Installation mit sorgfältig gewählten Namen und IP Adressen durchführen
- Install Proxmox starten
Proxmox GUI Zugriff
-
Im Browser: https://<ip>:8006
- Single PAM - ssh login # Benutzer auf Linux Ebene und PVE GUI
- Proxmox VE - Weboberfläche Cluster User
-
Proxmox CLI gegen root SSH Zugriff schützen (macht auch das SSH Hardening unseres Postinstallers)
-
/etc/ssh/.sshd_config
- PermitRootLogin without-password
- service sshd reload
Proxmox GUI
-
TOTP (time-based one-time password) kann über die Proxmox GUI gesetzt werden
- Datacenter - Permissions - Two Factor
- Selbst bei kompromitierem Passwort kann kein Dritter zugreifen!
- Für PAM und PVE User möglich
Update nach Proxmox 8.x - Für Einsteiger am einfachsten bei Erstinstallation zu üben
Das Pre-Upgrade Check Script pve7to8 sollte ausgeführt werden, um mögliche Probleme vor dem Upgrade erkennen zu können. Erstmal ohne Parameter und anschließend mit Parameter (--full: alle Checks).
** Für das Upgrade muss entweder eine Subskription erorben werden. Alternativ kann man auch das Enterprise Repository deaktivieren und das No-Subkription Repository aktivieren. Nur so erhält man Proxmox Updates!!! Ohne diese Auswahl kommen nur Debian Security Fixes!!!
Hier der Stand Version 7 zu 8
-
pve7to8
-
ve7to8 -- full
Wir empfehlen die VMs und Container zu stoppen und einen zeitnahen Reboot - Der neue Kernel passend zur GUI kann nur so aktiviert werden
apt update apt dist-upgrade pveversion
Letzte Version PVE 7 sollte nun installiert sein, kein Reboot notwendig hier
Upgradeprozedur bei Standardsystem
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list # ändert alle Repositories von Bullseye (Debian 11) zu Bookworm (Debian 12)
Enterprise Repo anpassen
echo "deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise" > /etc/apt/sources.list.d/pve-enterprise.list
Debian update
screen # falls etwas schief geht kann man mit screen -r zurück zur Sitzung apt update apt dist-upgrade #sollte hier mehrere hundert Aktualisierungen ankündigen
Während des Upgrades sollte man alles mit N beantworten und den Diensteneustarts zustimmen. Es kommt ggf. auch ein Textdokument was mit w zu verlassen ist
Unser Postinstaller sorgt in kürzester Zeit für alle notwendigen Sicherheits- und Komforfunktionen für den Notfall
Postinstall aus bashclub (proxmox-zfs-postinstall) auf github
-
Bashclub Postinstaller Proxmox
- ZFS L1ARC Size wird von PVE nur lieblos berechnet, empfohlen sind 1GB RAM für 1TB netto Datastore als first Level Cache
- Swappiness auf 10 Prozent oder kleiner, damit PVE nicht zu früh auslagert, jedoch am besten nicht den RAM überprovisioneieren!
- ZFS auto snapshots - die Werte können frei konfiguriert werden. Empfehlung für den Start (PVE weiß nichts davon!)
- monthly: 3
- weekly: 6
- daily: 10
- frequent: 12
- hourly: 96 --> wegen Weihnachten und Ostern
- Repo
- No Subscription auswählen, falls keine Subskription vorhanden
Wir sichern extra die /etc Ordner nach rpool/pveconf, da der Ordner /etc/pve aus einer Datenbank live erstellt wird. Er wäre bei einer Reparatur via Boot ISO leer!!!
Die ZFS auto Snapshots werden über die crontab ausgeführt. Dafür gibt es verschiedene Verzeichnisse:
- /etc/cron.hourly
- /etc/cron.daily
- /etc/cron.weekly
- /etc/cron.monthly
- /etc/cron.d (viertelstündlich)
In den Ordner liegt dann für jede "Aufgabe" ein eigene Datei (z.B. zfs-auto-snapshot
), in welcher die auszuführen Kommandos enthalten sind. Dort ist auch hinterlegt wieviele auto snapshots aufgehoben werden sollenn. (--keep=96
)
Die Zeitpunkte wann dieses ausgeführt werden sind in der Datei
/etc/crontab
definiert. z. B. könnte dort der tägliche Zeitpunkt angepasst werden
Ebenfalls finden sich Skripte ab Werk unter /etc/cron.d für z. B. Scrubbing und Trimming am Sonntag. Nicht jedem taugt dieser Zeitpunkt!
cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6 * * 7 root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6 1 * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
#
Zusätzlich gibt es für jeden User (z.B. root) noch eine eigene crontab, diese liegen unter cd /var/spool/cron/crontabs/
. Dort gibt es dann eine Datei root
für den User root, falls diese erzeugt wurde. Diese Datei wird z.B. auf den Linux VMs genutzt, um das Trimming zeitgesteuert ausgeführen zu können.
proxmox-boot-tool / ZFS Feature Upgrade / Trimming einschalten
Mit dem
promox-boot-tool
könnten Platten nach einen Hardwaretausch wieder bootfähig gemacht werden. Heute sollte nach Möglichkeit uefi Boot eingesetzt werden und nicht mehr legacy Boot, damit werden die Boot Platten automatisch erkannt und müssen nicht einzeln durch probiert werden, wie bei legacy boot. Autotrim sollte auf den SSD ZFS Datasets eingeschaltet sein, damit gelöschte Blöcke wieder im Dateisystem schnell verfügbar gemacht werden.
Optionale Funktionen zur ZFS Storage Optimierung
- zpool set autotrim=on rpool # für SSD Pools
- zpool set autoexpand=on rpool #vor Plattentausch auf größere Disks
- zpool upgrade #regelmäßig prüfen ob hier bei zpool status ein Hinweis ist. Der aktuelle PVE ISO Installer muss aber mit der Version bestückt sein, daher ggf. immer eine Version abwarten
- zpool trim rpool #test ob Trimming das System ausbremst
- zpool iostat -v 1 # Live Status
Einige wichtige Ordner vom Proxmox:
- Proxmox Konfiguration unter /etc/pve #Wie bereits oben erwähnt wird dieser Ordner nur zur Laufzeit von PVE aktiviert und ist bei einer Wiederherstellung per ISO leer! Daher unser Backup unter rpool/pveconf
- Template Ordner /var/lib/vz
- ISO Ablage Ordner /var/lib/vz/template/iso - z.B. virtio-win.iso
- Cache /var/lib/vz/cache/ z.B. *.tar.gz Proxmox Mailgateway
PVE startet noch, hat aber defekte Installation oder Konfiguration - Rollback vom Debian mit PVE
Wenn der Proxmox nicht mehr richtig funktioniert, werden die folgenden Schritte durchgeführt, um ihn wieder herzustellen zu können. Die erforderlichen ZFS snapshots werden durch die "Tools" des Postinstaller erzeugt.
Beim PVE Ordner (/etc/pve
) handelt es sich um eine Datenbank (/dev/fuse 128M 20K 128M 1% /etc/pve
), die ohne den Postinstaller nicht gesichert würden (rpool/pveconf 884G 128K 884G 1% /rpool/pveconf
).
Daher sollte der Postinstaller aus dem Bashclub auf jeden Promox PVE installiert sein, damit die Konfigurationsverzeichnisse von Proxmox auf ZFS gesichert und mit Auto Snapshosts versehen werden !!!
-
Proxmox CD bzw. ISO booten - Debug auswählen
-
exit - damit nicht der Installer bootet zpool status zpool import # zeigt ob der Pool komplett und fehlerfrei ist, könnte ja ein Hardware Problem sein zpool import rpool # würde wegen letztem Zugriff durch Fremdsystem nicht reichen zpool import -f rpool zpool status zpool list zfs list -t snapshot rpool/ROOT/pve-1 Dann z. B. auf funktionierenden Stand zurückrollen... zfs rollback -r rpool/ROOT/pve-1@zfs-auto-snap.hourly\_2023-09-26-1251 # entsprechender snapshot - boot und Proxmox geht wieder ``` Reboot oder Reset Server
**Sollte der Rollback Punkt z. B. auf einen Punkt von PVE 7 zeigen, so kann man beim Booten einen älteren Kernel auswählen
Nach erfolgreichem Neustart empfehle ich
- proxmox-boot-tool refresh
- apt update
- apt dist-upgrade
- reboot als Test
Installation Windows mit VirtIO Treiber
** Inzwischen installiert der Postinstaller einmalig eine aktuelle Virtio Treiber ISO als stabile Version - Für spätere Downloads...**
-
VirtIO Treiber im Internet finden
- Proxmox Windows Driver im Browser suchen
-
Auf Proxmox Seite nach Stable suchen
- Link kopieren
- In ProxMox GUI
- Download URL eintragen unter pvews - local (pvews) - ISO Images
- Filename: VirtIO-win.iso
- ISO Ablage Ordner **/var/lib/vz/**template/iso
- Download URL eintragen unter pvews - local (pvews) - ISO Images
-
Create VM
- General
- Node: pvews
- VM ID: 101
- Name: win
- Start at boot: Haken
- OS
- Use CD/DVD disc image file (iso)
- Storage: local
- ISO Image: Win10_22H2_German_x64.iso
- Use CD/DVD disc image file (iso)
- System
- Maschine q35 # nicht i440fx
- BIOS: OVMF (UEFI)
- Add EFI Disk: Haken
- Emu Agent Haken
- EFI Storage: local-zfs
- SCSI Controller: VirtIO SCSI Single # Achtung bei Hotplug weiterer Platten muss im Geräte Manager der neue Controller gefunden werden oder Reboot!
- Disks
- Bus/Device: SCSI 0
- VirtIO Block ist obsolet !!!
- SCSI - VirtIO SCSI Single - steht auf der Seite davor - SCSI Contoller kann ein Prozessorkern pro Festplatte exklusiv nutzen
- Discard: Haken # für Trimming der VM
- SSD emulation: # Haken für Trimming
- Cache: - Default (no cache) - keine Cache einschalten !!!
- Bus/Device: SCSI 0
- CPU
- Socket: 1
- Cores: 4 # relativer Wert zu anderen VMs
- Type: Host (Standard: x64-64-v2-AES) # mit Host wird die CPU 1:1 abgebildet, AES und Co. reduzieren den Funktionsumfang der virtuellen CPU, erhöhen aber die Kompatibilität bei Migration zwischen nur ähnlichen PVE Hosts
- Memory
- Memory: 4096
- Network
- Bridge: vmbr0
- Model VirtIO (paravirtualized) - kann mehr wie 1Gbit, 100Gbit möglich
- General
Inzwischen kann man die geladene virtio.iso als zweites Laufwerk in die VM einklinken
q35 Version 5.2 - weniger Probleme als mit Version 8.0 wegen deutschen Treibern - ist für US optimiert ... - Probleme mit Netzwerkkarten möglich
EFI hat feste Bildschirmauflösung - kann nur im EFI der VM eingestellt werden (EFI BIOS) - Im Bootvorgang in der Console (Proxmox GUI) - ESC drücken
Während der Installation am einfachsten nur die VIOSCSI Treiber installieren, da sonst keine Disks angeboten werden Den Rest des Setups von der VIRTIO ISO kann nach der Installation erledigt werden. Das spart die dummen Sicherheitsfragen und geht schneller.
Am Ende sollte auf der VM Statusseite die IP Adresse zu sehen sein, ansonsten noch prüfen ob der Haken bei Guest Agent an ist!
Für alle die von den APPS genervt sind etwas lustiges zum nachbasteln
Get-appxPackage | Remove-appxPackage # man verliert Taschenrechner - alle App werden entfernt - auch der Storage wird entfernt - Nach Feature Update wieder alles da
**Windows installiert am Ende des Setups eine Wiederherstellungspartition. Diese ist eventuell zu entfernen, da ansonsten kein Resize möglich ist. Der Resize ist auf der Disk in PVE jederzeit möglich
** Windows ist inzwischen in der Lage freie Blöcke an ZFS zurückzugeben, für den Fall daß wie beschreiben SCSI Single + SSD Emulation plus Discard gewählt wurde**
Optional noch Hilbernation Mode aus
-
attrib powercfg -h off # evtl. darf es der User nicht - powershell als administrator starten
Unser Datastore Swap kann genutzt werden um die Auslagerungsdatei auf eine eigene Disk zu legen. Das spart bei ramhungrigen Systemen viel Platz, da dort keine automatischen Snapshots ausgeführt werden. Die Platte muss nicht gesichert werden. Bei Linux bitte die Swap Disks mit Backup einmal sichern
Trimming unter Linux
-
Unter Linux wird nicht mehr benötigter Storage einer SDD wie folgt an ZFS freigeben
- Linux
/sbin/fstrim -av
# für Linux VM, nicht LXC!
- Linux
-
Eine automatisierte Freigabe von nicht mehr benötigtem Storage, kann über die crontab in Linux gesteuert werden
- crontab -e # crontab für den User root
- 5 * * * * /sbin/fstrim -a # Der crontab Eintrag bedeutet, daß jede fünfte Minute der vollen Stunde getrimmt wird
- crontab -e # crontab für den User root
fstrim -av # muss eine Ausgabe bringen - sonst ist die VM falsch konfiguriert - VM Platten auf SSD und Discard umstellen
Festplatten Tausch bei Defekt oder S.M.A.R.T Fehler
- Artikel von ProMox - ist nicht ganz korrekt: https://pve.proxmox.com/wiki/ZFS_on_Linux
Es reicht nicht mit zpool replace eine fehlende oder defekte Disk zu ersetzen. Sie könnte danach nicht booten. Wir benötigen ebenfalls zwei Partitionen mit dem Bootimage!
Der Fall beschreibt den Tausch optional gleich gegen eine größere Festplatte oder SSD
Erklärung zum Kommando sgdisk ... -- R ...
-
sgdisk \<gutes boot device\> - R \<neue Platte\>
# Partitionen werden kopiert und die GUID wird beibehalten - Soll eine neue GUID verwendet werden
sgdisk -G \<neue Platte\>
dmesg -Tw
Platte einbauen und Output prüfen, sdf ist neue Disk
zpool set autoexpand=on rpool # Erweiterung des Pools erfolgt am Ende automatisch! Bei Raid 10 reicht es zwei Disks zu Tauschen, bei RaidZx müssen allte getauscht werden um den Platz zu erweitern!
ls -althr /dev/disk/by-id | grep sdf (sdf wurde als neue Disk erkannt)
zpool status
Output zeigt aktive oder defekte Disks
rpool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-INTEL_SSDSC2KB019T8_PHYF951101ZS1P9DGN-part3 ONLINE 0 0 0
ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 ONLINE 0 0 33
Wir tauschen nun die zweite Disk vorsorglich
-part3 zeigt deutlich daß es sich hier um die dritte Partion handelt die ersetzt werden muss, folglich sind Parition 1 und 2 zum booten!!!
ls -althr /dev/disk/by-id | grep ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3
lrwxrwxrwx 1 root root 10 Oct 15 17:38 ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 -> ../../sdb3
Wir müssen also sdb3 ersetzen
Als erstes Paritionstabelle übernehmen und erweitern, falls größere Disk
sgdisk /dev/sdb -R /dev/sdf #sdb ist eine gute Disk, sdf die neue Disk
sgdisk -G /dev/sdf # neue GUID damit EFI die Disk unterscheiden kann
proxmox-boot-tool format /dev/sdf2 #format mit fat32
proxmox-boot-tool init /dev/sdf2 #kopiert Bootimage und notiert die Disk für künftige Updates
Optional
cfdisk /dev/sda # Partition vergrößern
** Beim nächsten sgdisk der Paritionstabelle einfach die große Disk als Vorlage nehmen
Jetzt den eigentlichen Datenbestand ersetzen
ls -althr /dev/disk/by-id | grep sdf | grep part3
zpool replace rpool ata-INTEL_SSDSC2KB019T8_PHYF951102271P9DGN-part3 ata-INTEL_SSDSC2KB019T8_PHYF95111111PXXX-part3
** Kontrolle des Erfolgs mit
zpool status # da soll dann die alte Disk raus sein und keine Fehler
zpool list # eventuell mehr freier Speicher nach Austausch von zwei Disks oder mehr
proxmox-boot-tool status #sollte zwei Treffer und einen Fehler melden, wegen gezogener defekter Disk
proxmox-boot-tool clean entfernt tote Bootdatenträger
Windows kaputt machen - Trojanersimulation
- Netwerkkarte disablen durch Trojaner
- VM herunterfahren
- Entwicklung der Größe der snapshot‘s - als Indikator
- Trojaner verursacht eine größere Änderung in den snapshots
- Rollback snapshot über Cockpit oder über command Line
ZFS Cache
- Parameter -n: dry-run
- erstmal anschauen, was das Kommando machen würde
zpool add -n rpool cache ata-intense..
zpool add -nf rpool cache ata-intense.. # wenn schon Daten auf der Platte
zpool add -f rpool cache ata-intense..
zpool iostat -v 3
zpool iostat -v 1 # 1 sec
Das Wort "cache" im Kommando ist sehr wichtig, da sonst die Platte evt. als einzel Mirror an den stehenden Mirror angehängt wird und das wollen wir nicht, daher immer mit -n testen !!!
Proxmox Cluster
-
GUI - Cluster - create cluster
-
pvecm create „clustername“
-
GUI - Cluster - „add Cluster“
-
pvecm add clusterserver1
-
Kein Cluster mehr
-
https://pve.proxmox.com/wiki/Cluster_Manager#_remove_a_cluster_node
-
Auf der Seite zu den folgendem Punkt springen: First, stop the corosync and pve-cluster services on the node:◦
-
cd /etc/pve
-
storage.cfg
-
qemu-server/*.conf
-
lxc/*.conf
-
nodes/... # Ordner mit den Cluster Member
-
top ps aux ps aux | grep qm # Herstellung aller Maschinen anhand dieser Ausgabe
-
Login in den Cluster funktioniert nach dem Fehlschlag nicht mehr
service pveproxy restart
- Neues Zertifikat - zwei Faktor Authentification der lokal User fliegt heraus
cd /rpool/pveconf
zfs list -t snapshot rpool/ROOT/pve-1
- PVE Config zurück rollen
zfs rollback -r rpool/ROOT/pve-1@zfs-auto-snap_hourly-2023-09-28-1017 # panic Variante und Stromkabel nach 2 s
-
besser von cd booten, rollback wie oben
-
Ordner .zfs unter /rpool/pveconf
-
cd snapshot # dieser Ordner nur in datasets vorhanden # Snapshot Order auswählen cd zfs-auto-snap_hourly-2023-09-28-0717 cd etc/pve/nodes/pvews cd lxc ls cp 100.conf /etc/pve/lxc cd .. cd qemu-server cp 101.conf /etc/pve/qemu-server # evtl. Alternativ cp 101.conf /etc/pve/nodes/pvews/qemu-server vi /etc/pve/nodes/pvews/qemu-server/101.conf # Anpassung von Namen
-
Boot Partitionen löschen
- Über dd
dd if=/dev/zero of=/dev/sda2 bs=1M count=511
dd if=/dev/zero of=/dev/sdd2 bs=1M count=511
proxmox-boot-tool status
-
Boot über CD/DVD - Advanced - debug mode console
-
Type exit - damit Installer nicht startet
-
https://pve.proxmox.com/wiki/ZFS:_Switch_Legacy-Boot_to_Proxmox_Boot_Tool
-
Aus der Webseite:
- Repairing a System Stuck in the GRUB Rescue Shell
-
If you end up with a system stuck in the grub rescue> shell, the following steps should make it bootable again:
-
Boot using a Proxmox VE version 6.4 or newer ISO
-
Select Install Proxmox VE (Debug Mode)
-
Exit the first debug shell by typing Ctrl + D or
exit
-
The second debug shell contains all the necessary binaries for the following steps
-
Import the root pool (usually named rpool) with an alternative mountpoint of /mnt:
-
zpool import -f -R /mnt rpool zfs list
-
Find the partition to use for proxmox-boot-tool, following the instructions from Finding potential ESPs
-
Bind-mount all virtual filesystems needed for running proxmox-boot-tool:
-
mount -o rbind /proc /mnt/proc
-
mount -o rbind /sys /mnt/sys
-
mount -o rbind /dev /mnt/dev
-
mount -o rbind /run /mnt/run
-
ls /mnt
-
change root into /mnt
-
chroot /mnt /bin/bash
-
- Repairing a System Stuck in the GRUB Rescue Shell
-
cat /etc/network/interfaces
- Zeigt die Netzwerk Interface Einstellungen
-
proxmox-boot-tool status lsblk proxmox-boot-tool format /dev/sdb2 proxmox-boot-tool format /dev/sdc2 proxmox-boot-tool init /dev/sdb2 proxmox-boot-tool init /dev/sdc2 proxmox-boot-tool status proxmox-boot-tool clean zpool export rpool # Falls der `zpool export` vergessen wurde, nach dem reboot `zpool import -f rpool`
-
<CTRL> <ALT> <ENF> # reboot auslösen
-
zpool import -f rpool # letzter Besitzer war CD exit # erneuter reboot zpool status
-
Wichtige Dateien:
- /etc/network/interfaces
- storage.cfg
- qemu-server/*.conf
- lxc/*.conf
-
Boot Partitionen löschen
- cfdisk /dev/sdb
- Partition 1 und Partition 2 löschen ◦
- fdisk /dev/sdc
- Partition 1 in Partition 2 löschen
- reboot
- cfdisk /dev/sdb
-
Proxmox neu installieren auf cache SSD ohne ZFS
-
Boot von CD
-
Install Proxmox ohne ZFS auf SSD
-
Würde mit ZFS installiert, hätten wir wieder ein rpool und müssten den original Pool rpool in z.B. rpool1 umbenennen und local-zfs anpassen !!!!
-
Profi Tipp: Alle anderen Platten ziehen, damit auf keiner falschen Platten installiert wird
-
Installation mit ext4 mit lvm
-
Neues Zertifikat
-
Passwort neu
-
ssh meckert wegen known_hosts # Neu Installation
-
zfs list # zeigt leere Liste zpool import -fa # alle importieren zfs list # rpool ist wieder da cd /rpool/pveconf cd etc cd pve ls cp storage.cfg /etc/pve cd qemu-server cp 101.conf /etc/pve/qemu-server # Produktiv System cp *.conf /etc/pve/qemu- server cd .. cd lxc cp 100.conf /etc/pve/lxc # Produktiv System cp *.conf /etc/pve/lxc
-
-
ISO‘s als DVD heraus werfen, da vermutlich nicht gesichert
-
zpool remove rpool <cache ssd> # cache ssd entfernen # atach und detach nur mirror - alles andere wird removed
-
Am Abend wieder ganz machen
- Booten von CD/DVD
- Advanced Mode - Debug mode
-
Partitionstabelle wiederherstellen
-
Anderen Proxmox anschauen
-
https://pve.proxmox.com/wiki/ZFS:_Switch_Legacy-Boot_to_Proxmox_Boot_Tool
-
Repairing a System Stuck in the GRUB Rescue Shell
-
zpool import -f -R /mnt rpool zfs list
-
Find the partition to use for proxmox-boot-tool, following the instructions from Finding potential ESPs
-
Bind-mount all virtual filesystems needed for running proxmox-boot-tool:
-
mount -o rbind /proc /mnt/proc mount -o rbind /sys /mnt/sys mount -o rbind /dev /mnt/dev mount -o rbind /run /mnt/run chroot /mnt /bin/bash # Partitionstabelle eines anderen ProxMox Systems anschauen sgdisk /dev/sdd -R /dev/sdb # muss resized werden cfdisk /dev/sdb
-
Partition 3 wieder vergrößern # Werte überprüfen mit Foto falls vorhanden
-
sgdisk /dev/sdb -R /dev/sdc sgdisk -G /dev/sdb sgdisk -G /dev/sdc
-
Änderungen haben nicht gegriffen - reboot erforderlich # alternativ parted - partprobe bekommt das im laufenden Betrieb hin
-
Reboot
-
Evtl. mit
proxmox-boot-tool
Partitionen wieder herstellen, zuvor muss die Proxmox Umgebung über die chroot Umgebung gebaut werden ... -
reboot zpool import -fa exit # reboot vom ProxMox zpool status proxmox-boot-tool status
-
-
-
-
-
Variante für das Arbeiten
- Externe SSD - True NAS installieren - geht aber nur für VM‘s - VM‘s per SCSI freigeben
-
Backup Proxmox Datenbank - Wie funktioniert das ?
-
cat /etc/cron.d/pve-conf-backup
-
rsync. -va --delete /etc /rpool/pveconf
# alle 15 min - ab 3. Minute
-
-
Import Daten
-
vmdk vhdx raw qcow2 > mounten vom original (VM aus!) /mnt/pve/nfsstore oder smbshare
-
zvol / lvm / usb / hdd /ssd
-
qm importdisk 100 /mnt/hypervfreigabe/dc.vhdx local-zfs
# (via samba) -
qm importdisk 100 /mnt/pve/nfsstore/vmfs/id/dc/dc.vmdk local-zfs #
(via NFS oder SSHFS) -
Echte Systeme (physikalische Server)
-
Clonezilla
-
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE
- Clonezilla Live CDs
-
Disks erscheinen erst mal unused - mit Doppelklick hinzufügen und booten
-
-
Backup und Monitoring
- Backup Dataset dürfen keine auto snapshots machen
-
zfs set com.sun:auto-snapshot=false backup
# siehe Codeblock
-
zfs list # Ziel Backup Disk - Pool Backup
zfs create backup/repl -o com.sun:auto-snapshot=false
zfs set com.sun:auto-snapshot=false backup
bash-club-zfs-push-pull # auf Ziel ausführen
- bashclub zfs-push-pull installieren
git clone https://github.com/bashclub/bashclub-zfs-push-pull.git
cd bashclub-zfs-push-pull
chmod +x 02pull
bashclub-zfs
cp bashclub-zfs /usr/bin
vi 02pull # Anpassen - In for Schleife ein echo zum Testen
bashclub-zfs # Parameter I und R - alte Snapshot und Zwischen-snapshots mitnehmen # Prinzipiell pull !!! - Quelle kommt nicht auf das Ziel, sondern nur Ziel kommt auf Quelle
cp 02pull /etc/cron.hourly
Für Trojaner sicher immer die "pull Methode" anwenden. Nur Ziel kommt auf die Quelle und nicht umgekehrt.
Monitoring
- ID: backup-repl
- ZFS Pool: backup/repl
- Thin provision: Haken
- Block Size: 16k
- https://github.com/bashclub/check-zfs-replication
wget -O /usr/local/bin/checkzfs https://raw.githubusercontent.com/bashclub/check-zfs-replication/main/checkzfs.py
chmod +x /usr/local/bin/checkzfs
checkzfs --sourceonly
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message
-
wget -O /usr/local/bin/checkzfs https://raw.githubusercontent.com/bashclub/check-zfs-replication/main/checkzfs.py
-
Keep: Hours 96, dayly 14
-
ProxMox GUI
- Storage - Add ZFS
-
cd /etc/pve/qemu-server cp 101.conf 9101.conf vi 9101.conf
-
Kommando im vi ausführen - local-zfs durch backup-repl ersetzen
- :%s/local-zfs/backup-repl/g # vi command
-
Swap entfernen
-
DVD Laufwerke entfernen
-
Name am Anfang repl- anfügen
-
- GUI der VM 9101
- Netzwerkkarte deaktivieren # Befehl kann man nachher in der conf nachschauen
- Autostart disablen
- VM 9101 starten # aber Replikationszeit beachten - cron.hourly
- LXC Container kann mittlerweile die Netzwerkkarte deaktivieren - alternativ in anderen vswitch
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns +message --output checkmk
# Datei generieren und auf anderen Server kopieren - über scp
zfs mount -a
ls /backup/repl/subvol-100-disk-0/etc/pmg
mkdir /mnt/restore
mount /dev/zvol/backup/repl/vm-101-disk-1-part3 /mnt/restore
ls /mnt/restore # Damit kann man Daten aus dem Windows zurückspielen
umount /mnt/restore
zfs create backup/klon -o com.sun:auto-snapshot=false
zfs list -t snapshot backup/repl/vm-101-disk-1
zfs clone backup/repl/vm-101-disk1@bashclub-zfs_2023-09-28_16:21:30 backup/klon/vm-101-disk-1
mount /dev/zvol/backup/klon/vm-101-disk-1-part3 /mnt/restore
ls /mnt/restore
vi /etc/pve/qemu-server/9101.conf # Anpassung das der Klon verwendet wird
- VM aus Klon booten und sich anschauen ...
umount /mnt/restore
zfs get guid
zfs get guid | grep bashclub-zfs_2023-09-28_16:46:50
zfs get creation rpool/data/subvol-100-disk-0@bashclub-zfs_2023-09-28_16:46:50
-
zfs Replication für arme
-
backup/repl # pull - Trojaner sicher
zfs snapshot rpool/data/vm-100-disk-0@snap1 # snapshot auslösen
zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # local
zfs send rpool/data/vm-100-disk-0@snap1 | ssh rot@zielip zfs recv -dvF # anderes System
- backup/repl # push - Quelle kommt auf Ziel !!! (Risiko Securtiy)
ssh root@sourceip zfs send rpool/data/vm-100-disk-0@snap1 | zfs recv -dvF backup/repl # pull
- checkzfs mit Mail - dafür muss Mail konfiguriert sein
checkzfs --filter rpool/data/ --replicafilter backup/repl --threshold 75,90 --columns+message --output mail
Kopie OPNSense Workshop - Vorumstellung auf markdown
Inhaltsverzeichnis
- Allgemein
- Links zu den Youtube Video und Nextcloud
- Virtuelle OPNSense auf ProxMox
- Sophos UTM9 Firewall
- OPNsense GUI - Einstiegskonfiguration
- OPNsense GUI - Basiseinrichtung
- Einschub Aliases
- Basis Setup
- Plugins
- Zertifikat für die Weboberfläche (GUI) der OPNsense
- OPNSense HA
- OPNsense Hardware / Virtuell
- Migrationswege zur OPNSense
- Harter Tausch
- Multivan
- Single WAN
- OPNSense
- DNS Server (alter: ISC )
- VPN
- IPSec
- WireGuard
- OpenVPN Einwahl - Roadwarrior
- Bridges
- Mailgateway
OPNSense
- Allgemein
- Links zu den Youtube Video und Nextcloud
Workshop 09.04.2024 und 11.04.2024
Kostenpflichtiger Link für Videos
Die Aufzeichnungen findet ihr im Kurs, der wiederum auf ein Textdokument in der Nextcloud verweist!
Der Nextcloudlink ist immer im Kurs oben, bzw. hier
Kostenpflichtiger Link für Videos
- Virtuelle OPNSense auf ProxMox
DNS Eintrag: opnws.sysops.de
Download: https://opnsense.org/download/
- Image Type: DVD (ISO)
- Mirror Location: Germany …. (Fulda)
Download Link kopieren
Im PVE funktioniert der „Download“ nicht, da ein .bz2 Datei
Auf ProxMox CLI:
-
cd /var/lib/vz/template/iso wget <gepeicherten Download Link> —> OPNSense*.iso.bz2 bunzip2 OPNSense*.iso.bz2
PVE GUI - anlegen der VM
- VM ID: 9999
- Name: opnws.sysops.de
- Start on boot: <Haken setzen>
- Tags: <auswählen bzw. erstellen>
- ISO Image: OPNsense…..iso —> Business Edition ist bei 23.x / Free Version 24.1
- Type: Other —> wegen BSD
- Maschine: q35
- BIOS: Default(SeaBIOS) —> UFI würde auch gehen
- SCSI Controller: VirtIO SCSI Single
- Quemu Agent: <Haken setzen>
- Bus / Device: SCSI 0
- Storage: local-zfs —> evtl. anderen Storage wählen
- Disk Size: 32 —> Log Files: 100 oder 200 GB - kein Weg bekannt für Vergrößerung
- SSD emulation: <Haken setzen>
- Discard: <Haken setzen>
- Sockets: 1
- Cores: 32 —> Chriz hat 32 CPU und will die komplette Power
- Type: Host —> wir sehen die CPU wirklich in der VM - Alternativ was mit AES
- Memory: 4096 - 4 GB für die meisten Fälle in Ordnung
- Bridge: vmbr0
- Model: VirtIO (paravirtualized)
- Firewall: <Haken entfernen>
Was fehlt hier noch ? Das WAN Interface
Wechseln zu Hardware:
- Add Network Device
- Bridge: vmbr3 —> sollte man vorher im PVE bei sich nachschauen …
- Model: VirtIO (paravirtualized)
- Firewall: <Haken entfernen>
MAC Adressen aus dem PVE aufschreiben / merken !
PVE Console OPNSense:
- Achtung: LAN IP Adresse (default): 192.168.1.1
- OPNSense Doku: https://docs.opnsense.org/manual/install.html#
- Login: installer —> für Installation der OPNSense, root —> temporäre Eingaben bis zum nächsten reboot
- Password: opnsense
- Tastaturlayout: German auswählen
- Install Filesystem:
- ProxMox: Install UFS —> ProxMox hat ja schon ZFS —> ZFS auf ZFS macht man nicht
- Hardware: Install ZFS —> eigene Hardware für OPNSense, hier will man ZFS haben, wegen snapshots
- SWAP —> Willst Du es haben ? Ja wahrscheinlich willst Du es haben …
- Sollte die Platte zu klein sein bleibt nur die Neuinstalliert und das zurückspielen vom Backup und Plugins neuinstallierten
- Root Passwort setzen
- Install and reboot auswählen, um die Installation zu starten
- OPNSense ist sehr gesprächig beim booten und braucht recht lange zum Booten
- Login als root
- Konfiguration des LAN Interfaces
- DCHP: N
- IP: 192.168.50.99
- Subnet Mask (bit counts - CIDR notation): 24
- Gateway address: <leer lassen> —> machen wir später
- IPv6 Address via WAN: N
- IPv6 DHCP6: N
- IPv6 IP Address: <ENTER> —> Keine IP Adresse
- Enable DHCP Server on LAN: n
- Do you want to change GUI protocol from HTTPS to HTTP: <ENTER>
- Do you want to generate a new self-signed web GUI certificate: <ENTER>
- Restore web GUI accès defaults: <Enter>
- In der Ausgabe steht dann die IP Adresse: https://192.168.50.99
- 2 —> Set Interface IP address
- 1 —> LAN
- Sophos UTM9 Firewall
In den Kurs wird immer mal wieder parallel auf die Sophos Firewall gegangen.
Bei ersten einloggen ist auf gefallen, dass die Lizenz abgelaufen oder herausgeflogen ist, dann kann man sich auch keine bestehenden Konfigurationen mehr anschauen.
Chriz hat die Lizenz wieder eingespielt und man kann sich wieder alles anschauen. Es muss der File aus dem myutm-sophos.com Portal heruntergeladen werden und dieser File muss eingespielt werden !
- OPNsense GUI - Einstiegskonfiguration
In der Dokumentation werden nur die wichtigsten Felder der OPNsense beschrieben, um sich die Bilder vom Workshop anzuschauen, kann die Volltextsuche vom Kurs verwendet werden. Um die Dokumentation recht schlank zu halten, wird möglichst auf Bilder verzichtet.
Im Webbrowser die GUI der OPNsense starten
- Mit root einloggen
ProxMox CLI:
-
—> bei gewissen Aktion kann man sich von der OPNsense ausschließen und da ist ein zfs-auto-snapshot für den Rückfall sehr willkommen/etc/cron.daily/zfs-auto-snapshot
Wieder zurück im Webbrowser der OPNsense
- System: Wizard: General Setup gestartet
- Einschub: Thema VDSL
- Hostname: openws
- Domain: sysops.de
- Language: English —> Chriz: würde es immer auf englisch belassen
- Primary DNS Server: 1.1.1.1
- Secondary DNS Server: 8.8.4.4
- Override DNS: <Haken entfernen> - Allow DNS servers to be overwritten by DHCP/PPP on WAN
- Enable Resolver: <Haken gesetzt lassen>
- <Next> Button
- Timezone: Amsterdam oder Berlin auswählen oder bei UTC belassen
- <Next>-Button
- IPv4 Configuration Type: PPPoE
- PPPoe Configuration —> Wir werden es nicht benutzen
- PPPoe Username: 12345678901201234567890120001@t-online.de
- PPPoe Password: 123123
- RFC1918 Networks
- Block RFC1918 private Networks: Haken standardmäßig gesetzt
- Block boron networks: Haken standardmäßig gesetzt
- Anmerkung Fritz!Box: Für Fritz!Box die beiden Haken entfernen
- <Next>-Button
- <Next>-Button
- <Next>-Button
- <Reload>-Button —> Button nicht gedrückt !!!
- Ein Point-to-Point Device - vtnet1
- + —> Add
- Device: vlan0.7
- Parent: vtnet1
- VLAN tag: 7
- Description: VDSL
- <Save>-Button
- <Apply>-Button
- Edit VLAN —> Sophos -DSL (PPPOE) - mit VDSL
- Link interface(s): vlan0.7
- <Save>
- <Next> Button
- General Information
- Time Server Information
- Configure WAN Interface
- Configure LAN Interface
- Set Root Passwort
- Reload Configuration
- Unter Interface - Point-to-Point - Devices
- Interface - Other Types - VLAN
- Interface - Point to point - Devices
- ==> Hardware OPNsense mit PPPoE
- Interface - Point-to-Point - Log File
- Debug
Einschub: Thema VDSL
- PVE GUI:
- Network Device
- Ergänzung: Tag 1 (Telefon), Tag 2 (TV) —> oder so was …
- VLAN Tag: 7
- Network Device
- VM: OPNSense (ID: 9999)
Im Textfile erklärt:
- BTX (Bildschirmtext)
- Anschlusskennung: 123456789012 (12-stellig)
- T-Online Nummer: 123456789012 (12-stellig) —> kürzer als 12 stellen # erforderlich - bedeutet sprint in das nächste Feld
- Mitbenutzer: 0001 (4-stellig)
- Password: xxxx (beliebig)
- DSL: @t-online.de
OPNsense VDSL
- Modem
- Interface
- Interface VLAN7
- PPPoe
Wieder zurück im Webbrowser der OPNsense
- PPPoE Konfiguration wieder aus der OPNsense löschen
- Wir machen jetzt richtiges Internet
- Interfaces - Assignments
- Ändern auf vtnet1 —> in Klammern wird die MAC Adresse angezeigt
- MAC Adressen im ProxMox kontrollieren
- Basic configuration
- Subnet mask: 24 —> Feld neben IP Adresse
- Lock: <Haken setzen> —> Prevent interface removal
- IPv4 configuration Type: Static IPv4 —> war vorher: PPPoE
- IPv6 configuration Type: None —> Erwartet hier kein IPv6 im Kurs
- MTU: —> Wenn z.B. beschießene Dialup Leitung
- IPv4 address: 194.30.174.105 —> Achtung bei kopieren - z.B. Klammer oder …
- <Save>
- <Apply>
- [LAN] lan vtnet0 —> in Klammern wird die MAC Adresse angezeigt
- [WAN] WAN pppoe (missing)
- <Save>
- [WAN] ist ein Link auf Interfaces: [WAN]
In einer CLI:
Pingtest funktioniert noch nicht, da noch kein Gateway
Wieder zurück im Webbrowser der OPNsense
- Im Suchfeld (Lupe): Gateway eingeben
- System Gateways: Configuration
- Edit gateway - war schon drin von PPPoE
- IP Address: 194.130.174.1
- Disable Gateway Monitoring: <Haken entfernen> —> wenn es pingbar ist
- Monitor IP: 1.1.1.1 - evtl. ist die IP nicht optimal
- <Save>
- <Apply>
- Edit gateway - war schon drin von PPPoE
In einer CLI:
Pingtest funktioniert noch nicht
Wieder zurück im Webbrowser der OPNsense
- System: Gateways: Configuration
- Status: offline
- <Apply>
- Status: grün —> online
In einer CLI:
Pingtest funktioniert noch nicht
Wieder zurück im Webbrowser der OPNsense
Im Suchfeld (Lupe): alias
- Firewall: Aliases
- + —> Add
- Name: sysops_Sites
- Type: Network(s)
- Content: 194.30.174.1/24 87.191.167.179/32
- Description: Wo wir sind
- <Save>
- <Apply>
- + —> Add
Wieder zurück im Webbrowser der OPNsense
- Im Suchfeld (Lupe): wan
- Firewall: Rules: WAN —> Erlaubende Regel
-
- + - Add
- Interface: WAN —> schon ausgewählt, da drüber eingestiegen
- Direction: in —> Eingehende Pakete
- Source: sysops_Sites
- <Save>
- <Apply>
- + - Add
In einer CLI:
Pingtest funktioniert jetzt
Sophos Interface - WAN angeschaut
Wieder zurück im Webbrowser der OPNsense
- Interfaces: Virtual IPs: Settings
- + Add
- Mode: IP Alias —> CARP könnte früher nicht mehr geändert werden
- Interface: WAN
- Network / Adress: 194.30.174.106/24
- Description: Alternative IP Workshop
- Edit Virtual IP
- <Save>
- <Apply>
- + Add
So jetzt haben wir zweite IP Adresse
Wieder zurück im Webbrowser der OPNsense
Im Suchfeld (Lupe): Gateways —> Wie ist das gedacht …
- System: Gateways: Configuration
- + - Add
- Name: OPNRZ
- Description: OPNsense Produktiv
- IP Adress: 192.168.50.113 —> Möchte ich eher für Routen als zum Surfen verwenden
- Disable Gateway Monitoring: <Haken entfernt> —> ob sie ping wissen wir nicht
- Monitor IP: 192.168.50.200 —> ProxMox könnte sich melden
- <Save>
- <Apply>
- Missconfigured Gateway IP
- Brauche ich jetzt auch nicht zwingend - so ist es gedacht
- Remove ORNRZ Eintrag als Gateway
- <Apply>
- + - Add
- Im Suchfeld (Lupe): Live
- Firewall: Log Files: Live View
- Action contrains block - + —> zeigt die block
- —> Unter Action steht grau hinterlegt: action-block
- Zeigt alles was geblockt wird
- >> - new - Feld Template Name: block - <Enter>
- Danach kann es später immer wieder ausgewählt werden
- Protoname is icmp - + - >> - new - Feld Template Name: Block ping
- —> Unter Action steht grau hinterlegt: action-block protname=icmp
- Zeigt alle geblockten ping’s
- Bei Lookup hostnames kann ein haken gesetzt werden - Bei Bedarf
- Im Suchfeld (Lupe): alias
Im anderen Browser Tab: Google
- Blocklisten
- Local copy: download local copy —> diesen Link kopieren
- firehol_level1:
- firehol_level2:
Wieder zurück im Webbrowser der OPNsense
- Firewall: Aliases
- + - Add
- Name: Firehol L1
- Type: URL Table (IPs) —> aktualisieren sich
- Refresh Frequency: Days. Hours
- Feld unter Days: 1
- Feld unter Hours: 0
- Content: <hier die kopierte URL eintragen>
- Description: Firehol L1
- <Save>
- <Apply>
- <Apply> - Nach dem zweiten Apply hat sich die Zahl oben rechts verändert von 92 auf 2090
- Edit Alias
- + - Add
- Im Suchfeld (Lupe): alias
- Firewall: Diagnostics: Aliases
- Feld: sysops_Sites
- Zeigt zwei Treffen
- Feld: Firehol L1
- Zeigt mehr / viele Treffer
- Feld: sysops_Sites
Frage: Firehol L1: ausgehend oder eingehend ?
Firehol L1 enthält private Netze, d.h. eingehend - L1 eingehend auf WAN
- Im Suchfeld (Lupe): WAN
- Firewall: Rules: WAN
- + - add
- Action: Block
- Log: <Haken bei Bedarf>
- Source: Firehol_L1
- Description: Firehol L1
- <Save>
- <Apply>
- Firewall:Rules: WAN
- + - add
Was ich immer machen würde:
- Block Regel
- Haken setzen bei Firehol L1
- Dann oberste Regel - Pfeile —> Move selected rules before this rule —> damit steht die Firehol L1 Regel ganz oben
- <Apply>
- Immer erst die Block Listen und dann die Erlauben Listen
- Im Suchfeld (Lupe): Live
- Block auswählen
- Es werde erste Firehol L1 Elemente geblockt
- Block auswählen
OPNsense Business License - hat Chriz für das RZ gekauft —> anderes Browser Tab
- OPNsense Business Edition (3Yr) - Angebot 359 € statt 447 €
- Anderes Repository
- GeoIP database
- Free E-Book
Business Edition:
- Im Suchfeld (Lupe): alias
- Firewall: Aliases
- Reiter: GeioIO settings
- Edit Alias
- z.B. Afrika
- Unwanted Geolocations
- Search Geo
- Edit Alias
- Alias kann in einer Firewall Rule als Block definiert werden
- In der freien Version muss man über einen Drittanbieter gehen …
- Reiter: GeioIO settings
- OPNsense GUI - Basiseinrichtung
- Einschub Aliases
Für die Aliases wäre ein Konzept sinnvoll, aber Chriz meinte auf Grund der Kundenanzahl und … wird er es nicht konsequent umsetzen können. Darüber muss sich jeder selbst Gedanken machen, inwieweit das für einen sinnvoll ist.
- N_DONTROURE Regel enthält alle privaten Netze
- 192.168.0.0/16
- 10.0.0.0/8
- 172.16.0.0/12
Wieder zurück im Webbrowser der OPNsense
- Firewall: Aliases
- Name: N_Dont_Rroute
- Type: Networks(s)
- Content: 192.168.0.0/16 10.0.0.0/8 172.16.0.0/12
- Description: Nicht aus dem Internet
- <save>
- <apply>
- + - add
Sophos - Firewall - rules
—> gibt es so nicht in der OPNsense
Regel in der OPNsense im RZ angeschaut
- Firewall: Rules Firma X
- Dadurch und die Aliases kann ein Regel auch schonmal komplex werden, aber dann muss man sich die Source und die Destination der Regel klar machen
- Destination: N_DONTROUTE wird negiert in der Regel eingesetzt
- Für die Firma X gibt es ein eigenes Interface, bei Source wird das Netz der Firma angegeben
Chriz erklärt es noch mal anders:
- Firewall: rules: LAN
- Problem bei Chriz: Er hat viele Kunden, die nicht untereinander zugreifen soll / dürfen - da kommt die N_DONTROUTE Regel zum Einsatz aber negiert im Destination und Destination / invert wird angeklickt —> Zeigt er wieder am Beispiel im RZ
- D.h. ich könnte den Bereich Destination: N_Dont_Route setzen aber der Destination / invert muss angeklickt werden
- + - add
- <save>
- <apply>
- Damit wird eine Regel erstellt mit der man alles darf
Achtung: Hier ist die Reihenfolge der Regeln entscheidend. Erst verbieten dann erlauben. Eine erlauben Regel vor der verbieten Regel würde wieder z.B. ein Netz erlauben
- Basis Setup
Wieder zurück im Webbrowser der OPNsense
- System: Settings: Administration
- Server: Local Database - auswählen, das hilft - vorher Nothing selected
- Protocol: HTTPS - ausgewählt
- TCP port: 4444 - 443 wollen wir später für was cooles haben, wir machen mal einen neuen Port 4444
- HTTP Redirect: Haken setzen - damit redirect disabled wird, evtl. brauche ich den Port 80 später auch noch
- Alternative Hostnames: opnws.sysops.de - DNS Name wegen rebind check
- Access log: Haken setzen (enable)
- Listen interfaces: ALL
- Secure Shell Server: Haken setzen - enable
- Root Login: Haken setzen - permit root user login
- Authentication Method: Haken nicht setzen - disable permit password login - kein Passwort Login
- Listen Interfaces: ALL
- Authentication
- <save>
OPNsense: Für jeden neuen Dienst muss eine Firewall Regel definiert werden
SOPHOS: da war das nicht so - dort werden Netze definiert, die im Hintergrund eine Firewall Regel gebaut haben
- Im Suchfeld (Lupe): User
- System: Access: Users
- Authorized keys: public key des ssh key hinterlegen (System das Zugriff haben soll z.B. Laptop)
- Root user —> Edit (Stift)
- <save>
CLI:
- ssh root@opnws.sysops.de
- Passwort loser Zugriff per CLI
Wieder zurück im Webbrowser der OPNsense
- System: Settings: Administration
- Chriz zeigt es doch schon:
- Zeigt QR Code
- Jetzt kann Du den QR Code im z.B. Google Authentificator ab fotografieren, damit die „Verbindung“ zur OPNsense hergestellt ist für die Code Generierung
- Achtung: bei so was kann man sich leicht aussperren - daher vorher eine Snapshot machen
- OTP seed: haken setzen —> Generatenew secret (160 bit)
- <save and to back>
- OTP QR Code: <Click to unhide>
- Chriz zeigt es doch schon:
- OTP seed: Hier könnte man jetzt noch one time password setzen / konfigurieren —> machen wir später
- Zum Testen aus und wieder einloggen
- Hier ist noch nichts mit 2 Faktor aktiv !!!
Ob man das ssh auf WAN will muss man sich überlegen.
- Plugins
Im Suchfeld (Lupe): Plugins
- System: Firmware
- Unter der Reiterleiste gibt es den Punkt Name —> Suche (Eingabe zur Suche des Plugins)
- acme
- os-acme-client —> + Zeichen anklicken
- Sollte die Installation starten, aber die Firmware ist nicht aktuell, d.h. es muss vorher ein Firmware Update durchgeführt werden —> Installation out of date
- Reiter: Plugins
- Im Suchfeld (Lupe): firmware
- System: Firmware
- Info zum Update bestätigen
- <update> - meist wird ein reboot benötigt - manchmal bootet er sogar 2 mal
- <check for updates>
- System: Firmware
OPNSense: kann im laufenden Betrieb Netzwerkkarten hinzufügen
SOPHOS: da ging das nicht im laufenden Betrieb - Interface - um hinter Interface einzutragen muss die SOPHOS herunterfahren - eintragen und wieder starten - Bei HA muss beide heruntergefahren werden - das bedeutet RZ offline - ging dann nur abends
OPNSense: Wieder in die Oberfläche einloggen
- Im Suchfeld (Lupe): cron —> Updates automatisieren
- System: Settings: Cron —> nur wenn ihr Zugang zur Firewall habt, Backups und snapshot vorhanden sind —> ALLOW_RISKY_MAJOR_UPGRADE
- Minutes: 0
- Hours: 0
- Command: Firmware update check
- Description: C —> wie check
- <save>
- <apply>
- Minutes: 0
- Hours: 1
- Command: Automatic firmware update
- Parameters: ALLOW_RISKY_MAJOR_UPGRADE —> ohne Eintrag würde er keine großen Updates machen, Eintrag nur mit Absicherung - siehe oben
- Description: U
- <save>
- <apply>
- System: Settings: Cron —> nur wenn ihr Zugang zur Firewall habt, Backups und snapshot vorhanden sind —> ALLOW_RISKY_MAJOR_UPGRADE
- Im Suchfeld (Lupe): Plugins
- System: Firmware
- Unter der Reiterleiste gibt es den Punkt Name —> Suche (Eingabe zur Suche des Plugins)
- acme
- os-acme-client —> + Zeichen anklicken
- Unter der Reiterleiste gibt es den Punkt Name —> Suche (Eingabe zur Suche des Plugins)
- Next
- Os-nextcloud-backup —> + Zeichen anklicken
- Unter der Reiterleiste gibt es den Punkt Name —> Suche (Eingabe zur Suche des Plugins)
- ngi —> hätte ich gerne in meinen Kurs
- os-nginx
- Unter der Reiterleiste gibt es den Punkt Name —> Suche (Eingabe zur Suche des Plugins)
- qem
- os-qemu-guest-agent —> + Zeichen anklicken
- Reiter: Plugins
- Reiter: Plugins
- WireGuard war früher ein Plugin, ist jetzt fest drin
- Reiter: Plugins
- HA Proxy —> Erklärung liegt in der Nextcloud —> Chriz benutzt es nicht
- Reiter: Plugins
- Dashboard
- Starten —> <play Button>
- QEMU Guest Agent
- System: Firmware
ProxMox GUI:
- VM 9999 opnws.sysops.de auswählen
- Nach kurzer Zeit werden z.B. IPs angezeigt
- Summary
QEMU Agent erlaubt es die VM sauber herunterzufahren
- Zertifikat für die Weboberfläche (GUI) der OPNsense
Let’s encrypt war in der SOPHOS recht spät und richtig schlecht - Certificate Management - Reiter Certificate Authority - geht nur mit http challenge
- Im Suchfeld (Lupe): acme
- Services: ACME Client: Settings
- Show introduction pages: Haken entfernen —> haben wir alles hier gelernt
- Enable Plugin: Haken setzen
- <apply>
- + / add
- Name: sysops_le —> le für let’s encrypt
- ACME CA: Let’s Encrypt (default)
- E-Mail Address: christian@sysops.de
- <save>
- Edit Account
- + / add
- Name: sysops_zs
- ACME CA: ZeroSSL —> anderer Anbieter
- E-Mail Address: christian@sysops.de
- <save>
- Edit Account
- Symbol: Viereck mit Pfeil nach unten —> Account registrieren ==> bei sysop_le
- <yes>
- Conformation Required
- Symbol: Viereck mit Pfeil nach unten —> Account registrieren ==> bei sysop_zs
- <yes>
- Conformation Required
- + / add
- Name: LE_HTTP
- Description: HTTP Challenge
- Challenge Type: HTTP-01
- HTTP Service: OPsense Web Service (automatic port forward)
- Interface: WAN
- <save>
- Edit Challenge Type
- + / add
- Common Name: opnws.sysops.de —> DNS muss passen
- Description:
- ACME Account: sysops_de
- Challenge Type: LE_HTTP
- DNS Alias Mode: Not using DNS alias mode —> vorher: Not using DNS alias mode
- <save>
- Edit Certificate
- Reiter Settings
- Services: ACME Client: Accounts
- Services: ACME Client: Accounts
- Services: ACME Client: Challenge Types
- Service: ACME Client: Certificates
- Button unten: <Issue/Renew all Certifcates> - erneuert alle Zertifikate —> Chriz würd ich nicht machen
- Rechteck mit Pfeil als Kreis —> Issue or renew certificate —> erneuert nur das eine Certificate „Common Name: opnws.sysops.de
- Service: ACME Client: Log Files
- Dort sollte die Zertifikates Erzeugung und Ablage zu sehen sein
- Reiter ACME Log
- Services: ACME Client: Certificates
- Dort ist das Zertifikat zu sehen
- Es gibt einen Cron Job der die Erneuerung macht - normalerweise bringt dieser einen immer an —> Chriz hat es gerade nicht gefunden
- Wenn Dir Let’s Encrypt auf den „Sack“ geht könnte man auch ZeroSSL verwenden
- Services: ACME Client Challenge Types
- Name: ZSSL_HTTP
- Description: HTTP Challenge Zero SSL
- <save>
- Name: LE_HTTP Clonen —> Zwei Rechtecke übereinander als Symbol
- Edit challenge Type —> Anpassungen vornehmen
- Service: ACME Client: Certificates
- Edit Certificate
- ACME Account: sysops_zsl
- <save>
- Clone Let’s Encrypt Eintrag —> zwei Rechtecke übereinander
- Renew bei neuen Eintrag über den Pfeil als Kreis ausführen
- Edit Certificate
- Services: ACME Client: Log Files
- Auch hier sollte der Abruf des neuen Zertifikates sichtbar sein
- Zero SSL lässt sich etwas mehr Zeit - ein sleep von 15s
- Reiter: ACME Log
- Services: ACME Client Certifcates
- Dort findet man jetzt zwei Zertifikate
- System: Trust: Certicates
- Self-signed
- Let’s Encrypt
- Zero SSL
- …
- Dort landen alle Zertifikate
- Services: ACME Client: Settings
- Services: ACME Client: Challenge Types —> Wildcard Certificate
- Edit Challenge Type
- Name: Hetzner
- Description:
- DNS Service: DNS-01
- DNS Service: Hetzner
- API Token: <Paste from Clipboard - siehe Hetzner unten>
- <save>
- + / add
- Services: ACME Client: Certificates
- Edit Certificate
- <yes>
- Common Name: *.sysops.de —> Wild Card Zertifikate
- Description: Wildcard
- ACME Account: sysops_le
- Challenge Type: Hetzner_DNS
- <save> —> dauert ein paar Sekunden länger
- Symbol Rechteck mit Pfeil als Kreis —> Zertifikat abholen
- Conformation Required
- Edit Certificate
- + / add
- Services: ACME: Log Files
- Reiter: ACME Log
DNS Anbieter: macht bloss 2 Faktor Authentifizierung rein
Browser Hetzner Login Seite
- DNS Console
- Token Name: Workshop
- Create access Token
- API Token —> <Copy to Clippboard> Button
- <Confirm>
- Manage API tokens
Nachdem das Zertifikat in der OPNSense angefordert wurde, sieht man im Hetzner Portal —> Record deleted
Da heißt OPNsense steuert jetzt Deinen Hetzner.
Chriz hat anschließend gleich den Revoke token ausgeführt, damit ist der Token in der OPNsense unbrauchbar geworden.
- Services: ACME Client: Automations
- Edit Automation
- Name: NGINX
- Description:
- Run Command: Restart Nginx (OPNsense plugin)
- <save>
- + / add —> Das habe ich überall vergessen
- Services: ACME Client: Certificates
- Automation: NGINX —> Gibt es ein neues Zertifikat gibt, wird der NGINX durchgestartet - Bei der SOPHOS ging das alles automatisch
- Common Name: *.sysops.de
- Edit (Stift)
- System: Settings: Administration
- SSSL Ciphers: < hier kann jetzt unter verschiedenen Zertifikaten ausgewählt werden> —> z.B. Zero SSL
- <save>
Browser:
- opnws.sysops.de:4444
- Offizielles Zertifikat ohne jetwillige Warnung des Browsers
Frage: intern Domain .z.B. xxx.lan
- Du nimmst ein internet Domain mit der interne IP Adressen
- Der DNS Server läuft intern, trotzdem bekommst Du ein Zertifikat
- OPNSense HA
Du könntest Dir jetzt das umständlich zusammen klicken, aber das machen wir hier nicht
- System: High Availability: Settings —> das ist richtig kompliziert
SOPHOS: High Availability —> war nicht der SOPHOS viel einfacher
Youtube Video
OPNsense High Availability, höher und günstiger denn je - Live 24.08.2023
Link: OPNSense HA
Wenn Du ein ProxMox Cluster hast
ProxMox GUI:
- VM 9999 opnws.sysops.de auswählen
- Add
- Schedule: */5 —> alle 5 min
- <create>
- <Schedule now>
- <Log>
- Migrate
- Achtung: vorher ISO herausnehmen
- CD/DVD
- ISO … auf don’t Use this media setzen
- Hardware
- Output
- Das braucht seine Zeit
- Platte wird migriert
- Auch der RAM muss migriert werden - da ist weniger mehr
- Achtung: vorher ISO herausnehmen
- Kann auf den anderen PVE (PVE3) umgezogen werden
- <Migrate>
- Replication
- Rechte Maustaste auf VM 999
CLI:
- Über einen ping während der Migration sieht man das es nur einen kurzen aussetzen im ping Ablauf gibt
Chriz reduziert den RAM der OPNsense Workshop, dafür wird die VM heruntergefahren. Bei der offline Migration im ProxMox braucht nur der Storage migriert werden, durch ZFS werden nur die Änderungen übertragen. Anschließend wird der RAM auf 4096 MB reduziert, minimaler RAM auf 2048 gesetzt und wieder gestartet.
- OPNsense Hardware / Virtuell
An hand der „Themenstruktur.md“:
- Thomas Krenn Hardware: Chriz braucht die Hardware nicht
- Mini Forum GK41
- Ist doppelt so schnell wie eine SG230
- Zwei Interface mit 1 Gbit/s
- Firma IPU - die hat Chriz noch nicht getestet
- Kann man sich bauen lassen, wie man es haben will
- Mini PC 2.5 GHz und WLAN was auch mit der OPNsense funktioniert - mit N100
- Es kann noch eine SATA SSD dazu gebaut werden
- Standard wäre 128 GB SSD - das ist auch völlig ausreichend
- Transcend 128 GB - könnten OK sein
- KingSpec hat Chriz letztens gekauft, waren ganz OK
- 3 * schneller als eine SG230 und wird gut warm
- 2,5 Gbit/s
- Evtl. mit 16 GB RAM, wenn Du sie bekommst —> ProxMox müssen es 16 GB seinSta
- SSD sind zum Teil durch wachsen, d.h. sie können ausfallen
Virtuelle OPNsense Parameter an hand der „Themenstruktur.md“ durchgesprochen
- Disk size: 64 GB - da Vergrößerung schwierig …
- Migrationswege zur OPNSense
- Harter Tausch
Als erstes müssen die Redbox (Red) los werden
Site to Site VPN und Fernzugriff
- IPsec
- OpenVPN
Praxis Beispiel:
- GK 41
- IPsec
- Strongworm können Sophos und OPNsense beide gut
- OPNsense
- Site to site VPN
- NextCloud Backup
- OPNsense online bringen und Sicherheitslevel erhöhen IKEv2
- Wenig Config
- Wegfall Lizenz oder Hardware
- Home- und Monatslizenz
- Multivan
Bei Multivan bringe beide Firewalls online auf verschiedenen IP’s. Über Routen oder über DHCP Server ändern des Gateways auf ONPsense.
- Single WAN
Auf der OPNSense wird alles durch geNATet.
Sophos Kabel für den Internet Zugang abziehen und auf die OPNsense umstecken.
Danach auf der Sophos auf Internal das „IPv4 default GW Address“ auf die OPNsense ändern und das war’s. Danach die NAT Regel auf der Sophos auf die OPNsense eintragen. D.h. Du NATest die Sophos raus und das hat den Nebeneffekt, dass Du siehst wie weit Du mit der Migration bist.
OPNSense:
- Firewall: Rules: WAN
- In den Beispiel läuft gar nichts mehr über die alte Firewall (Sophos), d.h. die kann ausgeschaltet werden
- Automatische Rules aufgrund von NAT haben keine Edit Knopf
- Inspect - da sehe ich ob noch Traffic drüber geht
Sophos:
- Kaum noch Traffic drauf
- Eine Redbox ist online
- Nutzt eigentlich auch schon VPN, kann also auch aus
Ausschalten der Sophos
Wichtig ist die Änderung der Gateway auf die neue Firewall. Im DHCP Server muss das neue Gateway eingetragen sein. Ist in diesen Fall so, da die OPNsense den DHCP Server spielt. Wo das Gateway von Hand eingetragen ist, muss es auch von Hand geändert werden.
Alles noch mal kontrollieren, ob alles auf die OPNSense umgestellt ist.
- OPNSense
Es gibt zwei DHCP Server
- ISC (alt) - ist gut, er der besten DCHP Server
- Kea (neu) - hat sich Chriz noch nicht angeschaut
Unbound DNS
Backup
- System: Configuration: Backups
- Enable: Haken setzen
- Weitere Configuration …
- Kannst ganz viele Backup’s in der Nextcloud aufheben, hat Chriz an einer anderen OPNsense gezeigt
- Backup count: 50 - Chriz würde hier mal ein 50 reinschreiben
- <save>
- —> Backup im System
- Backup kann man herunterladen
- Backup Datei kann in Teilen wieder hergestellt werden
- NextCloud Backup
Qemu Agent nochmal kurz angesprochen.
Sophos - NAT Regeln
- Masquarding ist von Hause aus an
OPNsense
- Masquarding muss nicht separat konfiguriert werden
PVE - Container anlegen (ID: 9998) - kleiner Webserver zu herauslegen
- PVE CLI:
apt install apache2
- Keine Internet Verbindung
pct enter 9998
OPNSense
- Live View: Firewall: Log Files: Live View
- icmp Block: Destination 192.168.50.99, Source 192.168.50.98
- Im Suchfeld (Lupe): lan
- Firewall: Rules LAN
- Nicht eintragen
- <save>
- <apply>
- LAN Rule darf eigentlich überall hin - sollte gehen
- Regeln disabled bzw. löschen
- Neu LAN Rule anlegen
- Ping auf das Gateway funktioniert, aber kein Zugriff auf das Internet z.B. ping 1.1.1.1
- Geht trotzdem noch nicht …
- Live View: Firewall: Log Files: Live View
- Ping wird nicht geblockt
- Firewall: NAT: Port Forward
- Kein Problem ersichtlich
- Im Suchfeld (Lupe): ping
- Interfaces: Diagnostics: ping
PVE CLI
-
pct enter 9998 nslookup web.de —> keine Antwort Server 192.168.50.99 web.de —> Firewall antwortet, aber lässt uns aber nicht ins Internet
- ==> Gateway Thema
- Nslookup test’s
OPNSense
- Im Suchfeld (Lupe): gateway
- System: Gateways: Configuration
- Passt alles
- Edit Gateway
- Firewall: NAT: Outbound
- Hybrid outbound rule generation
- Automatic outbound NAT rule generation
- Viele gehen auch auf:
- Im Suchfeld (Lupe): live
- Wir wollen sehen ob er etwas blockt: Block / Block ping
- Es wird nichts geblockt
- Firewall: Log Files: Live View
- Interfaces: [LAN]:
- Ob LAN Interface richtig konfiguriert
- Interfaces: [WAN]:
- IPv4 Upstream Gateway: Auto-dect (Ist Zustand)
- IPv4 Upstream Gateway: WAN_GW: 194.30.174.1 (geändert auf) - Chriz hatte da schonmal ein Problem
- <Save>
- <Apply>
- Das war’s der konnte sich hier nicht von alleine entscheiden - Am Anfang über Assistenten für VDSL PPoE eingetragen !!!
PVE CLI
-
pct enter 9998
- Web Server antwortet
-
apt update apt install apache2 apt install curl curl localhost
OPNSense
- Im Suchfeld (Lupe): nat
- + / add
- Interface: WAN
- TCP/IP Version: IPv4
- Protocol: TCP
- Destination: WAN address —> oder Alternative —> Kurs: WAN address gewählt
- Destination: 194.30.174.106 (Alternative IP Workshop)
- Destination Port range: from: HTTP to: HTTP
- Redirect target IP: single host or Network
- Sauber wäre: Speichern, alias anlegen, Regel auf alias anpassen - wird man in der Regel nicht tun, Anmerkung Chriz
- IP Address: 192.168.50.99
- Redirect target port: HTTP
- <save>
- <apply>
- Edit Entry
- + / add
- Firewall: NAT: Port Forward
Browser:
- opnws.sysops.de
- Browser macht daraus https !!! Umleitung auf http auf https
Terminal:
- curl <link aus Browser kopiert>
- Da sieht man https://opnws.sysops.de/
- curl http://opnws.sysops.de —> auf http geändert
- Gibt Seite des Web Servers aus
PVE CLI
-
pct enter 9998
- acme
- Dann kann ich aber nur einen WebServer herauslegen
- Daher nimmt man einen Reverse Proxy
- Wie bekomme ich jetzt https für den Webserver
Fritz!Box oder OPNSense
- NAT regel für Port 80 und 443 auf NGINX
Browser
- NGINX einloggen
- Installiert über
- Docker
- PVE gibt es ein fertigen Installer
- IP Adresse des NGINX nach draußen NATen (http und https)
- Edit Proxy Host
- Domain Name: home.eesy.de
- Scheme: http
- Forward Hostname / IP: 10.x.y.z
- Forward Port: 8123
- SSL Certificate: Request a new SSL Certificate
- Reiter: Details
- Reiter: SSL
- E-Mail Adresse / Passwort
- Proxy Hosts
Für kleine Setup.
Richtige Weg wäre … ist mühsam …bietet aber auch mehr Möglichkeiten
OPNSense
- Im Suchfeld (Lupe): nat
- Evtl. vorhandene NAT Regel für Port 80 und 443 entfernen
- <apply>
- Firewall: NAT: Port Forward
- Im Suchfeld (Lupe): nginx
- Reiter: General Settings
- Enable nginix: Haken setzen —> Erst mal einschalten
- <apply>
- Reiter gib es einige
- Viele haben dann noch Unterpunkte …
- Also nicht für schwache Nerven
- Reiter: Upstream - Upstream Server
- Edit Upstream
- Description: webserver_host
- Server: 192.168.50.98
- Port: 80 —> hat kein SSL
- Server Priority: 1
- <save>
- + / add
- Reiter: Upstream - Upstream
- Edit Upstream
- Description: webserver_upstream —> der alle Webserver zusammenfasst
- Server Entries: webserver_host —> Wir haben jetzt nur einen Webserver
- Enable TLS (https): keinen haken setzen —> Webserver hat noch kein TLS
- <save>
- —> Ein Webserver ist alleine in einer Gruppe
- + / add
- Reiter: HTTP(S) - Location
- Edit Location
- Description: webserver_host_root
- URL Pattern: / —> oder /webapp oder …
- Upstream Servers: webserver_upstream
- Force HTTPS: Haken setzen
- <save>
- + / add
- Reiter: HTTP(S) - HTTP Server —> der veröffentlich dann wirklich
- Edit HTTP Server
- HTTP Listen Address: 80 [::]:80 —> das würde auf allen Adressen veröffentlichen !!
- HTTP Listen Address: 194.30.174.105:80 —> Veröffentlichung auf der Hauptadresse
- HTTPS Listen Address: 443 [::]:443
- HTTPS Listen Address: 194.30.174.105:443
- Server Name: opnws.sysops.de
- Locations: webserver_host_root
- TLS Certificate: *.sysops.de (ACME Client) —> wild card certificate
- Client CA Certificate: R3 (ACME Client)
- Enable Let’s Encrypt Plugin Support: haken ist schon gesetzt —> Er kann ein neues Zertifikat haben, wenn es ein neues gibt
- HTTPS only: haken setzen
- <save>
- Rechteck mit Pfeifen im Kreis neben dem + Button —> wichtig
- + / add
- Services: Nginx: Configuration
Browser
- opnws.sysops.de
- Browser hat eine sichere Verbindung, ob der Webserver kein gültiges Zertifikat hat
- *.sysops.de —> Wild Card Certificate
- Zeigt die Demo Seite von Apache 2 Debian Default Page
- Im Browser kann man sich das Zertifikat anzeigen lassen
Für einen weiteren Eintrag müssen alle 4 Schritte wiederholt werden …
Im Schnelldurchgang weitere Einträge in der OPNsense:
- Upstream Server - webserver_host clone
- Anpassen
- Upstream - webserver_upstream clone
- Anpassen
- HTTP(s) - Location - webserver_host_root clone
- Anpassen
- HTTP(s) - HTTP Server - opnws.sysops.de clone
- Anpassen
Nginx in der OPNsense bietet noch mehr
- ACL IP’s
- Zusatz login
- …
OPNSense
- Im Suchfeld (Lupe): nginx
- Services: NGINX: LOGS / HTTP ACCES —> bietet viele verschiedne Ansichten, wie Traffic Statistik, …
SOPHOS- Web Application Firewall (WAF) - verschiedene Reiter
Nextcloud - Kurs Files - Cynfo Setup - OPNSENSE_HA_PROXY.docx
- Wenn es interessiert kann sich den HA_Proxy in diesen Dokument anschauen, ist nicht Teil des Kurses
ISPConfig funktioniert nicht hinter einen NGINX Proxy, da braucht man den HA_Proxy —> Dafür hat Chriz die Anleitung schon ein paarmal benötigt
Wie bekommen wir raus, ob alles funktioniert ?
- Dashboard anschauen
- Alles grün
- Available Widgets können nach Bedarf hinzufügt werden wie z.B. IPsec, Interface Statics, Firewall log, WireGard, TrafficGraph
Browser
- GitHub.com/bashclub —> bashclub
- Checkmk-opnsense-agent
- How to install - 3 Zeilen
- ssh auf die OPNsense —> ssh root@opnws.sysops.de
- Geht mit 8 auf die shell
- Einfügen der 3 Zeile in die Shell —> Plugin wird installiert
- Sucht auf der Seite nach opnsense
- Geht mit dem Browser auf Deinen Check_MK —> Check_MK
- Setup - Hosts - Add host
- Hostname (required): hostname eintragen —> IP Adresse mit der ich da komme muss im Paket Filter drin sein
- Save & run connection Tests
- Run tests
- Save and go properties
- Accept all
- Activate on selected sites
- Suche mir den Host
- Man sieht die ganzen Services
- Einloggen
- Monitor
Sophos - Network Protection - Firewall
- z.B. Nur zwei Server dürfen auf das Backup Netz zugreifen
- Sources:
- Destinations:
Um das in der OPNSense abzubilden muss man sich vorher eine Alias für Sources und Destinations bauen, um das abgebildet zu bekommen … - dann als Firewall Regel anlegen
OPNSense
- Im Suchfeld (Lupe): history
- Backup (compare)
- Hier kann man einen zweiten Zeitpunkt wählen und man kann sehen was zwischen den beiden Schritten konfiguriert wurde
- Unter dem ersten Auswahl Fenster kann ein Zugang in der Vergangenheit ausgewählt werden, um auf diesen zurück zu springen, wenn man sich vierkonfiguriert hat
- Sytem: Configuration: History
Chriz zeigt nochmal einige in seiner Firewall
- Wozu brauche ich Firewall Regeln im LAN ?
- Firewall Rule im WAN
- Button <Inspect>
- Welche Regeln greifen und welche greifen nicht ?
- Die Description sollte immer ausgefüllt werden, da sonst der Sinn der Regel nur anhand der Regel selbst ermittelt werden kann
- Frage offen: Welcher Zeitraum wird angezeigt ?
- Vermutlich nur seit dem Start von Inspect
- Selbst erzeugte Regeln erkennt man am Stift - Editierter !
- Regeln die durch die NAT Rules kommen - die kann man nur löschen !
- Was braucht man noch davon ?
- Button <Inspect>
- Firewall Regeln könnten kategorisiert werden
- Darauf können dann auch wieder Regeln aufgesetzt werden - Nutzt Chriz nicht
- Gibt es z.B. 3 Regeln von unterschiedlichen Source auf den gleichen Port
- Regeln könnten über einen Alias für die Source auf eine Regel reduziert werden
- Port Range für eine Aufgabe z.B. OpenVPN könnten auf eine Regel reduziert werden und es müsste nicht für jeden Port ein eigene Regel geben …
- Umstellung Redbox können dir mit Logs vollgeschrieben werden
- Auf die Destination localhost schicken und das Log der Sophos wird nicht mehr vollgeschrieben
2. Tag 11.04.2024
- DNS Server (alter: ISC )
Anmerkung: Neuer DNS Kea
OPNSense
- Im Suchfeld (Lupe): DNS
- Jetzt kann man sich den DHCP Range anschauen
- Range: ….
- Services: DHCPv4: [LAN]
Wie kann man das Testen ?
Linux Server mit nmap - dort gibt es ein Script: broadcast-dhcp-discover
LInux CLI mit nmap
- nmap --script broadcast-dhcp-discover
- Interface: vmbr0
- IP offered: <IP Adress>
- …
- IP Address Lease Time: 4h00m00s
- …
- Domain Name Server: <IP Adress>, 1.1.1.1
- …
OPNSense
- Im Suchfeld (Lupe): DHCP
- System X suchen und MAC Adresse merken
- machender.com —> kommst auf eine grüne Seite
- Gibt Apple aus
- Mac Adress eingeben
- machender.com —> kommst auf eine grüne Seite
- 3 stellen aa:bb:cc ist der Vendor
- Browser suchen: Mac address vendor
- System X suchen und MAC Adresse merken
- Services: DHCPv4: Leases
- Im Suchfeld (Lupe): DHCP
- Hinweis: hat verschiedene Level
- Je nachdem was man braucht
- Über Multi select können dann alle Level angeklickt werden
- Hinweis: hat verschiedene Level
- Services: ISC DCHPv4: Log File
DHCP gibt es pro Interface, wenn er aktiviert ist.
Nachtrag zum ersten Tag:
OPNsense
- Interfaces: Assigments
- [WAN] WAN
- Device von PPoE auf vtnet1 umstellen
- VPN
- IPSec
SOPHOS: Site-to-Site VPN - IPSec
OPNSense
- Im Suchfeld (Lupe): IPSec
- Im Kurs werden wir noch Tunnel Settings (legacy) nutzen
- Im nächsten Kurs wird Connections verwendet
- Ist nur ein anderes FrontEnd beides ist Strongswan
- VPN: IPsec: Connection
OPNSense
- Im Suchfeld (Lupe): IPSec
- Es gibt zwei Phasen - Phase 1 ist zwischen den Sites
- 2 Phase: da hast Du alle Subnetze
- VPN: IPsec: Tunnel Settings [legacy]
- Encryption algorithm: Standard: 256 bit AES-GCM with 128 bit ICV
- Encryption algorithm: AES —> zweite Fenster geht auf !
- Zweites Feld: 256
- Hash algorithm: MD5
- DH key group: 5
- Key Exchange version: v1 —> besser v2 - SOHOPS kann nur v1
- Interface: TelekomFTTHPPoE
- Remote Gateway: sophos.sysops.de
- Discription: AB DMZ nach RZ Sophos
- Phase 1 proposal (Authentication)
- VPN: IPsec: Tunnel Settings [legacy]
- + / add —> add phase 1 entry
- VPN: IPsec: Tunnel Settings [legacy]
Gegenseite SOPHOS:
- Wir geben der SOPHOS eine externe IP Adresse - Interfaces - WAN
- Es gibt noch ein alte IP Adresse: 194.30.174.96
Anmerkung: Geht nicht mit der Schulung OPNsense wegen Routing
CLI:
ping 194.30.174.96 # —> ergibt keine Antwort
PVE GUI:
- Suchen nach Sophos
- Hardware
- Einige Netzwerk Interface sind down
- VM1002
Gegenseite SOPHOS:
- IP Adresse liegt auf dem Interface eth2 und hat die MAC Adresse ..:..:57
PVE GUI:
- Suchen nach Sophos
- Hardware
- Bridge: vmbr3
- Disconnect: Haken entfernen —> Interface wird wieder aktiv
- VM1002
CLI:
ping 194.30.174.96 # —> ping gibt eine Antwort - IP Adresse aktiv
OPNSense
- Fortsetzen der Konfiguration / Ändern Remote gateway
- Remote Gateway: 194.30.174.96
- Fest IP Adressen
- My identifier: My IP Address
- Peer identifier: Peer IP Address
- DynDNS - Chriz testet damit - funktioniert wahrscheinlich nicht
- 2. Feld: sysops2024
- 2. Feld: sysops2024
- My identifier: Auswahl Distinguished name
- Peer identifier: Auswahl Distinguished name
- Pre-Shared Key: sysops2024sysops2024
Gegenseite SOPHOS:
- Was bietet uns die SOPHOS auf der Gegenseite an, was gehen würde …
- …
Chriz will erstmal ein Erfolgserlebnis, darum nehmen wir jetzt die festen IP Adressen …
SOPHOS:
- New Remote Gateway
- Add network Definition
- Name: DMZ-WS
- IPv4 address: 192.168.66.0
- <save>
- Name: loftdmzws
- Gateway: office.sysops.de —> Stand noch zur Verfügung
- Authenticaton Type: Preshared key
- Key: <heraus kopierten> einfügen
- Repeat: <heraus kopierten> einfügen
- VPN ID type: IP address
- Remote networks:
OPNSense
- Fortsetzen der Konfiguration / Ändern Remote gateway
- Dead Peer Detection: Haken setzen —> eingeschaltet - nur bei OPNSense zu OPNSense
- Dead Peer Detection: Haken setzen —> AUS - bei OPNSense zu SOPHOS
- Lifetime: 7800 —> bei SOPHOS - wichtig muss eingetragen sein
- <save>
- <apply>
- Netz kommen die Netze
- VPN: IPsec: Tunnel Settings [legacy]
- Address:
- Type: DMZ-subnet
- Remote Network
- VPN: IPsec: Tunnel Settings [legacy]
- + / Add
SOPHOS:
- Wir brauchen ein neues Netzwerk
- Name: Workshop
- Type: Ethernet
- Hardware: eth3 —> nehme eine freie Netzwerkkarte, vorher eine freigemacht
- Wir haben keine Karte mehr übrig - löschen etwas: eth3 Pandora
- IPv4 address: 192.168.65.1
- IPv4 netmask: /24 (255.255.255.0)
- IPv4 default GW: kein Haken setzen —> brauchen wir nicht
- <save>
- New Interface
- Interface muss eingeschaltet werden
OPNSense
- Fortsetzen der Konfiguration / Ändern Remote gateway
- Netz kommen die Netze
- VPN: IPsec: Tunnel Settings [legacy]
- Address: 192.168.67.0
- Zweites Feld: /27
- Type: DMZ-subnet
- Remote Network
- Phase 2 Proposal (SA/Key Exchange)
- Encryption algorithms: AES256
- Hash algorithms: SHA256 —> MD5 nicht mehr auswahlbar - SOPHOS was passendes finden …
- VPN: IPsec: Tunnel Settings [legacy]
- + / Add
SOPHOS:
- Policy - AES-256-PFS
- IKE authentication algorithm: SHA2-256 —> Zukunft sicher
- IPsec authentication algorithm: SHA2-256 —> Zukunft sicher
- IPsec PFS group: Group 1: MODP 2048 —> eine Gruppe höher gestellt
OPNSense
- Fortsetzen der Konfiguration / Ändern Remote gateway
- Netz kommen die Netze
- Phase 2 Proposal (SA/Key Exchange)
- PFS key group: 14 (2048 bits)
- Lifetime: 3600
- VPN: IPSec: Tunnel Settings [legacy]
- Hash algorithm: SHA256
- DH key Group: 14 (2048 bits)
- + / Add
- <save>
- Zurück auf die 1. Phase gehen und die Anpassungen durchführen
- <save>
- <apply>
SOPHOS:
- 2.Phase
- Name: WS
- Remote gateway: loftdmzws
- Local Interface: external
- Policy: AES-256-PFS —> normaler kopieren und dann editieren
- Local Networks:
- Workshop (Network)
- Automatic firewall rules: haken davor gesetzt
- <save>
- New IPsec Connection
- Jetzt schauen wir ob es schon passt
- IPsec Connection hat er schon angeschaltet
- Site-to-Site VPN Tunnel Status
- Da geht noch nichts - dann prüfen wir das gleich
OPNSense
- Falsche Subnet Mask /27 gesetzt in der Phase 2
- 192.168.67.0
- /24
- <save>
- <apply>
- Anpassung der Subnet Mask
SOPHOS und OPNSense Ansichten müssen aktualisiert werden
OPNSense
- VPN: IPsec: Status Overview
- Status links ist jetzt grün geworden
- Rechts gibt es einen Play Button für reconnect
- Die 2. Phase wird noch nicht angezeigt
SOPHOS
- SOPHOS will noch gar nichts davon wissen - alles rot
OPNSense
- VPN: IPsec: Log File
- Evtl. über Multiselect alle Level auswählen, um etwas zu sehen
SOPHOS
Auch nach die Änderung des Preshared Keys hat nicht gebracht, die IPsec Verbindungen werden nicht komplett aktiv.
Problem der Ursache gerade nicht bekannt.
Wir schauen uns jetzt ein erfolgreiche Verbindung an, die gestern konfiguriert wurde.
OPNSense
- VPN: IPsec: Status Overview
- Dort sehen wir gerade keine zweite Phase ==> Tunnel steht nicht - Test über ping
- IPSec Verbindung über Play Button gestartet und die zweite Phase wird angezeigt
- Andere Seite auch noch mal angeschaut und dort gibt es auch eine zweite Phase
- Manchmal funktioniert der ping noch nicht, dann ping stoppen und wieder starten
OPNSense - DynDNS
- Services: Dynamic DNS: Settings
- Edit VDSL Eintrag
- Relativ einfach:
- Check ip method: Interface (IPv4)
- Relativ einfach:
- Edit DynDNS Eintrag
- Check ip method: loopia —> Damit hat Chriz gute Erfahrungen gemacht
- Current IP darf keine private Adresse der Fritz!Box stehen
- Edit VDSL Eintrag
IPSec funktioniert immer in beide Richtungen
Bein OPENVPN und WireGuard braucht nur eine Richtung für den Aufbau funktionieren.
- WireGuard
Wir löschen die IPSec Verbindung und wollen sie durch WireGard ersetzten
Bei WireGuard ist die SOPHOS raus.
WireGuard site-to-site
- WireGard ist Multiprozessor fähig und mehrere Prozesse
- Server: das ist die Instanz
- Gegenstelle: das ist die Peer
OPENSense Kunde
- VPN: IPsec: Connections - Auf beiden OPNSensen löschen
- Die zweite Phase löscht sich automatisch
- Oberste Verbindung löschen (Phase 1), aber schauen, dass man die richtige löscht
- Enable IPsec: Haken entfernen —> IPsec aus machen
- <apply>
- VPN: WireGuard
- + / Add
- Name: sysops
- Public key: —> Public key von der „Gegenstelle“ also vom Server / Instance
- Pre-shared key: Zahnrad drücken —> erzeugt den Pre shared key in einen neuen Feld —> beide Seiten identisch
- Allowed IPs: —> ip der Gegenstelle intern plus Netze
- Endpoint address: —> interne Adresse
- Endpoint Port: —> Port
- Man muss erstmal eine Instanz erzeugen
- + / Add
- Public key: <erzeugter Public key>
- Private key: <erzeugter Private key>
- Name: sysops-rz
- Public key: Zahnrad erzeugt Public und private key in zwei Feldern
- Listen port: 52451
- Tunnel address: 172.16.12.2/32 —> wir brauchen ein Netz, was es auf beiden Seiten noch nicht gibt - muss erst noch herausgesucht werden - gefunden: 172.16.12.0
- <save>
- Reiter: Peers —> Gegenstelle
- Reiter: Peer generator —> Client Einwahl
- Reiter: Instances
- Im Suchfeld (Lupe): routes
- System: Routes: Status —> zeigt keine IPsec Netze an !!!
- Hier kann man nach vorhanden Netze in der Liste der Netze suchen
- Das gleiche muss auf der Gegen OPNSense auch geschaut werden
- IPSec Netze werden nicht angezeigt, sonder nur WireGard Netze
- IPSec Netze werden nicht angezeigt, sonder nur WireGard Netze
- Netz: 172.16.12. als freies Netz gefunden —> Ist oben schon eingetragen
- System: Routes: Status —> zeigt keine IPsec Netze an !!!
OPENSense OPNrz
- VPN: WireGuard
- + / add
- Public key: Zahnrad erzeugt Public und Privat key in zwei neuen Feldern
- Public key: <erzeugter Public key>
- Private key: <erzeugter Private key>
- Listen Port: 52451
- Tunnel Address: 172.16.12.1/32
- <save>
- <apply>
- Name: Leister
- + / add
- Reiter: Instances
OPENSense Kunde
- VPN: WireGuard
- + / add
- Name: sysops
- Public key: <public key OPNsense opnrz>
- Pre-shared key: <pre-shared Key OPNSense opnrz>
- Allowed IPs: 10.0.0.0/24
- Endpoint address: opnrz.sysops.de
- Endpoint Port: 52451
- Instances: sysops-rz
- Keepalive internal: 25
- <save>
- <apply>
- Reiter Peers
OPENSense OPNrz
- VPN: WireGuard
- + / add
- Name: Leister
- Public key: <public key OPNsense Kunde>
- Pre-shared key: <pre-shared Key OPNSense Kunde>
- Allowed IPs: 192.168.50.0/24
- Endpoint address: leister.dyndns.ws
- Endpoint Port: 52451
- Instances: Leister
- Keepalive internal: 25
- <save>
- <apply>
- Reiter: Peer
OPENSense Kunde
- VPN: WireGuard: Status
- Zeile in Status braucht einen Handshake fehlt noch …
- Firewall: Rules: WireGuard (Group)
- <save> —> d.h. im WireGuard ist alles offen
- + / add
Frage: Wie geht es einfacher ?
Browser:
- GitHub.com/bashclub
- Nimmst die Installationsanleitung
- Wg-config
Du gehst auf eine Linux Kiste
CLI:
-
apt install wireguard qrencode wget -O /usr/local/bin/wg-config \ https://git.bashclub.org/bashclub/wg-config/raw/branch/main/wg-config chmod +x /usr/local/bin/wg-config wg-config -h clear wg-config —help wg-config -e oparz.sysops.de -E leister.dyndns.ws - t 172.16.12.1/32 \ -T 172.16.12.2/32 -d 1.1.1.1 -n 192.168.50.0/24 -N 10.0.0.0/24 Erzeugt eine WireGard Config und zeigt diese an wg-config -e oparz.sysops.de -E leister.dyndns.ws - t 172.16.12.1/32 \ -T 172.16.12.2/32 -d 1.1.1.1 -n 192.168.50.0/24 -N 10.0.0.0/24 -o -O # Ausgabe im OPNSense Format
Jetzt macht man nur noch Copy & Paste - ist doch viel einfacher - wichtig alles kopieren und nicht das letzte Zeichen vergessen
OPENSense OPNrz
- VPN: WireGuard
- + / add
- Public key: Zahnrad erzeugt Public und Privat key in zwei neuen Feldern
- Public key: <erzeugter Public key>
- Private key: <erzeugter Private key>
- Listen Port: 52451
- Tunnel Address: 172.16.12.1/32
- Peer: Leister
- <save>
- Name: Leister
- + / add
- Reiter: Instances
OPENSense OPNrz
- VPN: WireGuard
- + / add
- Name: Leister
- Public key: <public key OPNsense Kunde>
- Pre-shared key: <pre-shared Key OPNSense Kunde>
- Allowed IPs: 192.168.50.0/24
- Endpoint address: leister.dyndns.ws
- Endpoint Port: 52451
- Instances: Leister
- Keepalive internal: 25
- <save>
- <apply>
- Reiter: Peer
OPENSense Kunde
- Reiter: Instances
- Name: sysops-rz
- Public key: Zahnrad erzeugt Public und private key in zwei Feldern
- Public key: <erzeugter Public key>
- Private key: <erzeugter Private key>
- Listen port: 52451
- Tunnel address: 172.16.12.2/32
- Peer: sysops
- <save>
- + / Add
OPENSense Kunde
- VPN: WireGuard
- + / add
- Name: sysops
- Public key: <public key OPNsense opnrz>
- Pre-shared key: <pre-shared Key OPNSense opnrz>
- Allowed IPs: 172.16.12.1/32 192.168.50.0/24
- Endpoint address: opnrz.sysops.de
- Endpoint Port: 52451
- Instances: sysops-rz
- Keepalive internal: 25
- <save>
- <apply>
- Reiter Peers
OPENSense OPNrz
- Im Suchfeld (Lupe): Live
- WireGard Port wird geblockt
- Firewall: Log Files: Live view
- Im Suchfeld (Lupe): WAN
- Regel Clones und Anpassen
- Destination Port range:
- From: 52451
- To: 52451
- Description: wg Leister
- <save>
- <apply>
- Edit
- Regel Clones und Anpassen
- Firewall: Rules: WAN
OPENSense Kunde
- Im Suchfeld (Lupe): Live
- WireGard Port wird nicht geblockt —> es scheint das die neuere OPNSense die WireGard Ports von selbst auf machen - Chriz ist sich nicht sicher
- Immer noch nicht OK
- Firewall: Log Files: Live view
- VPN: WireGuard: Status
Überprüfung der WireGuard Config.
Nochmal überprüft im Live Log beider OPNSense das der Port nicht blockt wird. Keine Block Meldungen gefunden.
Wir machen die Config noch mal neu.
Jetzt wird alles aus wg-config kopiert außer dem Port 52451
CLI:
- wg-config -e oparz.sysops.de -E leister.dyndns.ws - t 172.16.12.1/32 -T 172.16.12.2/32 -d 1.1.1.1 -n 192.168.50.0/24 -N 10.0.0.0/24 -o -O -p 52451
- Ausgabe im OPNSense Format
Mit dieser Ausgabe können wir jetzt wirklich copy & Paste machen - wir generieren nichts
Bei DynDNS braucht man auf der DynDNS Seite bei Peer keine Endpoint Address eintragen, es reicht auf einer Seite.
OPENSense Kunde
- VPN: WireGuard: Status
- Sieht man das es jetzt geklappt hat —> Handshake ist jetzt da
Der ping funktioniert auch wieder !!!
Braucht man mehrere braucht trägt man die im Peer eine weitere Netz unter Allowed IPs ein. Die Paket Filter müssen auch passen.
Wichtig bei Tunnel Address muss die Subnet Mask eingegeben werden, sonst sucht man eine Fehler der nicht da ist !!! (War in der Instance)
Hinweis: WireGuard Regeln müssen erstellt werden
- Firewall: Rules: WireGuard (Group)
- OpenVPN Einwahl - Roadwarrior
Mit IPsec und Einwahl ist nicht geil, gibt kaum clients.
OPNSense
- OPNSense hat ein neues FrontEnd für OpenVPN, die Software hinten dran ist die selbe
- VPN: OpenVPN: Instances
- Reiter Instances
- Wir nehmen Legacy
- VPN: OpenVPN: Servers [legacy]
- Server Mode:
- Peer to Peer —> wäre Site-to-Site —> Chriz: besser bedient mit IPSec und WireGuard
- SSL/TLS
- Shared Key
- Remote Access
- SSL/TLS —> Zertifikat —> CA
- User Auth
- SSL/TLS + User Auth
- Sprung zum anderen Bereich
- Verschiedene Auswahl Möglichkeiten:
- Server Mode:
- + / add
- System: Trust: Authorities
- Descriptive Name: vpn_ca
- Method: Create an internal Certificate Authority
- Key Type: RSA
- Key length (bits(: 4096
- Digest Algorithm: SHA256
- Lifetime (days): 9999 -> Chriz macht immer 9999
- Country Code: DE (German)
- State or Province: by —> Was Du hier reinschreibst - siehe keine, gilt auch für die folgenden Felder
- City: ab
- Organization;: sysops
- Email Address: christian@sysops.de
- Comman Name: vpn-ca
- <save>
- + / add
- Method: Create an internal Certificate
- Descriptive name: vpn_cert
- Certificate authority: vpn_ca
- Type: Server Certificate
- Key Type: RSA
- Key length (bits): 4096
- Digest Alorithm: SHA256
- Lifetime (days): 9999
- Private key location: save on this firewall
- Common Name: vpn_cert
- <save>
- + / add
- System: Trust: Certificates
OPNSense
- Im Suchfeld (Lupe): Server
- + / add
- TLS Authentication: Enabled - Auhtetication only
- TLS Shared Key: Automatic generate a share TLS authentication key - Standard Haken gesetzt
- Man kann auch seinen eigenen Eintragen
- Peer Certificate Authority: vpn_ca
- Server Certificate: vpn_cert (vpn_ca)
- Encryption algorithm (depicted): None —> am besten frei lassen - es wird ausgehandelt
- Auth digest Algorithm: SHA256 (256 bit)
- IPv4 Tunnel Network:172.16.13.0/24
- IPv4 Local Network: 10.0.0.0/24
- Compression: Legacy - Disabled LZO algorithm (--comp-lzo no) —> macht man auch nicht mehr
- Standard: No Preference
- Duplicate Connections: Haken setzen
- Description: Roadwarrior
- Server Mode: Remote Access (SSL/TLS + Auth User) —> evtl. später 2 FA
- Backend for authentication: Local Database —> Zur Zeit nur Local Database —> d.h. nur User root
- Protocal: UDP
- Device Mode: tun
- Interface: WAN —> WAN hat mehr Upstream
- Local Port: 1194
- Cryptographics Settings:
- Tunnel settings;
- Client Settings —> Hängt vom Client ab, ob er drauf Block hat …
- Server #1: 10.0.0.4
- Server #2: 1.1.1.1
- DNS Default Domain: leister-schuhe.local
- DNS Domain search List: leister-schuhe.local
- DNS Servers:
- + / add
- VPN: OpenVPN: Servers [legacy]
- <save>
SOPHOS
- War sehr schön gelöst gewesen - vorbildlich
- Site-to-site VPN
- SSL
- Encryption algorithm: AES-128-CBC
- Problem Werte sind zu alt und müssten neu gemacht werden, d.h. jeder Client braucht ein neues Zertifikat
- CBC ist seit einen Jahr auf dem iPhone nicht mehr möglich - das war das Ende von SOHOPS und iPhone, deshalb wird bei der OPNSense diese Feld mittlerweile leer gelassen
- Reiter Profiles
- Reiter Settings
- Reiter Advanced
- SSL
- Remote Access
- Egal wieviel Du klickst, da ist eine Instanz mit einen Kern
OPNSense
- Im Suchfeld (Lupe): WAN
- + / add
- From: 1194
- To: 1194
- Protocol: UDP —> wichtig !
- Destination port range:
- <save>
- + / add
- Firewall: Rules: WAN
- Im Suchfeld (Lupe): Export
- VPN: OpenVPN: Client Export
- Remote Access Server: Roadwarrior UDP:1194
- Export type: File only
- Hostname: leister.dyndns.ws —> Ich trage die Internet Adresse ein
- vpn_cert: hinten download Button drücken
Mac von Chriz:
- Finder —> Windows Explorer für Windows User
- Roadwarrior_vpn_cert.ovpn
- Open with … - OpenVPN Connect
- Download
- OpenVPN connect
- User: root
- Password: <passwort von root>
- <CONNECT>
- <Schalter> auf ON stellen
- Verbindung geht noch nicht
- Troubleshooting
- Import Profile
OPNSense
- Im Suchfeld (Lupe): Log
- Fehlermeldung im Browser googeln
- Edit
- Encryption algorithm: AES-256-GCM —> Hat Chriz die letzten Jahre genommen, eigentlich soll man es leer lassen - Test, ob es daran liegt
- <save>
- VPN: OpenVPN Log File
- VPN: OpenVPN: Servers [legacy]
- Wenn man seine Reihenfolge im Kurs ändert …
- Im Suchfeld (Lupe): User
- Root User - Edit
- + / add
- Method: Create an internal Certificate
- Key length (bits): 4096
- Lifetime (days): 9999
- <save>
- User Certificates:
- Root User - Edit
- System: Access: Users —> für jeden User wird ein eigenes Zertifikat benötigt, auch für alle LDAP User - das geht nicht automatisch
- Danach sieht man im User das User certificate(s), dass wir gerade erzeugt haben
- Im Suchfeld (Lupe): Export
- Root
- <Download>
- Certificate
Browser download
- Zertifikate auswählen und anklicken
- Wird in derApplikation geöffnet
- <Retry>
- <cancel>
- Username: root
- Password: <password root>
- <CONNECT>
- <Schalter> auf ON stellen
- Verbindung klappt
CLI
- traceroute -d 10.0.0.4 ==> keine Antwort
- ping 10.0.0.4 ==> keine Antwort
OPNSense
- Im Suchfeld (Lupe): live
- Firewall: Log Files: Live View
- 10.0.0.4 —> icmp
- Block Regel erweitern und unter neuen Namen speichern
- Portname is icmp
- + / neue Regel machen
- Name eingeben: block ping <Return / Enter> oder Diskette anklicken
- Block
- Im Suchfeld (Lupe): openvpn
- + / add
- <save> —> Chriz: Ich erlaube erstmal alles
- <apply>
- Firewall: Rules: OpenVPN
CLI
- traceroute -d 10.0.0.4 ==> Antwort
- Geht über das Transfer Netz: 172.16.15.1
- Zum Ziel: 10.0.0.4
- ping 10.0.0.4 ==> Antwort
Bei Chriz: kein VPN sondern eine Bridge zum RZ
Jetzt mit LDAP oder Windows AD
OPNSense
- Im Suchfeld (Lupe): user
- System: Access: Server
- Descriptive Name: LDAP-UCS
- Type: LDAP —> wir machen jetzt nur LDAP ohne 2 FA
- Hostname or IP address: 10.0.0.4
- Port value: 7389 —> Standardwert: 389 Windows AD
- Bind credentials:
- User DN:
- Password:
- + / add
Browser UCS Server
- 10.0.0.4
- Users
- Einfaches Authentiisierungskonto
- <weiter>
- Benutzername: ldapopn
- Passwort: <ldapopn Password>
- Passwort (Wiederholung): <ldapopn Password>
- <LDAP-Object erzeugen>
- Neues LDAP-Objekt hinzufügen
- Users
- System- und Domäneinstellungen —> Chriz: Bei UCS ist es besonders schön
- LDAP-Verzeichnis
CLI UCS Server
- ssh root@10.0.0.4
- univention-ldapsearch --LLL uid=ldapopn
- dn: uid=ldapopn,cn=users,dc=leister-schuhe,dc=local —> Bei Windows ist vorne ein cn=ldapopv
OPNSense
- Im Suchfeld (Lupe): user
- System: Access: Server
- Descriptive Name: LDAP-UCS
- Type: LDAP —> wir machen jetzt nur LDAP ohne 2 FA
- Hostname or IP address: 10.0.0.4
- Port value: 7389 —> Standardwert: 389 Windows AD
- Bind credentials:
- User DN: uid=ldapopn,cn=users,dc=leister-schuhe,dc=local
- Password: <ldapopn Password>
- Base DN: cn=users,dc=leister-schuhe,dc=local
- Authentication containers: <select> Button anklicken
- cn=users,dc=leister-schuhe,dc=local
- <save>
- Es wird in das Feld davor übernommen
- cn=users,dc=leister-schuhe,dc=local
- Fenster: Please select which containers to Authenticate against:
- User naming attribute: uid —> Standard: cn, Univention: cid
- Read properties: Haken setzen
- Synchronize groups: Haken setzen
- Automatic user creation: Haken setzen
- <save>
- + / add
- System: Access: Tester
- Gibt einen Output zurück das funktioniert hat + weitere Info’s zum User
- Authentication Server: LDAP-UCS
- Username: o.leister
- Password: <Password>
- <Test>
SOPHOS
- Authentifcation Services
- Bind DN:
- Tester
- Username:
- Password:
- <Test>
- SOPHOS hat zu einer bestimmten Zeit die User erzeugt und gleichzeitig auch die Zertifikate für die User angelegt
- Edit LDAP
- Advanced
An dieser Stelle kann Du Dich aussperren !
CLI
- /etc/cron.daily/zfs-auto-snapshot
OPNSense
- Im Suchfeld (Lupe): user
- System: Access: Server
- —> Immer noch keine Auswahl
- Im Suchfeld (Lupe): Administration
- Setting - Administration
- Server: LDAP-UCS und Local Database anklicken —> Bei Auswahl erscheint hinter dem Eintrag ein Haken
- Wählt Du nur LDAP UCS aus, hast Du Dich ausgesperrt !!! —> LDAP User haben keine Rechte auf der OPNSense
- <save>
- Authentication
- Im Suchfeld (Lupe): user
- Gibt es neben dem + Zeichen - die Wolke
- Haken hinter dem Eintrag setzen
- Erscheint ein neues Fenster aus dem Du Dir die User heraussuchen kannst
- <save>
- —> Die User müssen von hand importiert werden —> Kein Cron Job dafür bekannt
- Über und unter dem root User sind die User zu sehen
- Jeden User einzeln editieren
- + Zeichen anklicken
- Method: create an internal Certificate
- Key length (bits): 4096
- Lifetime (days): 9999
- <save>
- User Certificates
- Gibt es neben dem + Zeichen - die Wolke
- System: Access: Users
- VPN: OpenVPN: Servers [legacy]
- Backend for authentication: LDAP-UCS —> anklicken —> Haken dahinter
- LDAP-UCS
- Local Database
- <save>
- Edit
- Im Suchfeld (Lupe): export
- User suchen und auf <download Button> klicken - OpenVPN File wird heruntergeladen
Browser
- Auf den Download File klicken und in der App OpenVPN importieren
- Username: o.leister
- Vor Save password —> haken setzen
- Password: <Password vom User>
- <CONNECT>
- —> OpenVPN funktioniert nachdem auf der LDAP_UCS für die Authentifikation eingetragen wurde
CLI
- traceroute -d 10.0.0.4
- Zeigt wieder den gleichen Weg wie oben, Transfer Netz und dann Ziel
Jetzt kommt noch 2 FA dazu
OPNSense
- Im Suchfeld (Lupe): Server
- Descriptive Name: LDAP-UCS 2fa
- Type: LDAP + Timebase One Time Password —> LDAP mit 2 FA
- Hostname or IP address: 10.0.0.4
- Port value: 7389 —> Standardwert: 389 Windows AD
- Bind credentials:
- User DN: uid=ldapopn,cn=users,dc=leister-schuhe,dc=local
- Password: <ldapopn Password>
- Base DN: cn=users,dc=leister-schuhe,dc=local
- Authentication containers: <select> Button anklicken
- cn=users,dc=leister-schuhe,dc=local
- <save>
- Es wird in das Feld davor übernommen
- cn=users,dc=leister-schuhe,dc=local
- Fenster: Please select which containers to Authenticate against:
- User naming attribute: uid —> Standard: cn, Univention: cid
- Read properties: Haken setzen
- Synchronize groups: Haken setzen
- Automatic user creation: Haken setzen
- Reverse token order: haken setzen —> token after password - Standard: kein Haken token before Password
- Hinweis: Damit 2 FA richtig funktioniert darf der Haken nicht gesetzt sein - siehe weiter hinten in der Doku
- <save>
- System: Access: Servers
- + / add —> Leider gibt es hier kein Clone, also komplett neu anlegen
- Im Suchfeld (Lupe): Server
- Backend for authentication: LDAP-UCS 2fa haken setzen
- Wichtig: LDAP-UCS —> Haken entfernen
- VPN: OpenVPN: Server [legacy
- Description: Roadwarrior - Stift (Edit) anklicken
- <save>]
- Im Suchfeld (Lupe): User
- System: Access: User
- OTP seed
- Generate new secret (160 bit): Haken davor setzen
- <save> —> und nicht <save and go back>
- OTP QR Code: <Click to unhide>
- QR Code wird angezeigt
- Edit User z.B. o.leister
QR Code mit dem Handy in der 2 FA App einlesen
Zurück im OpenVPN Client
- Entsprechende Open VPN Verbindung editieren
- Password Abfrage:
- Passwort gefolgt von OTP
- <OK>
- Save Password muss raus - zu mindest für einen Moment
- <save>
- Connection aktivieren
- Connection wieder trennen
Im Browser
- Suche: opensense openvpn ask top
- Code: static-challenge „Please enter your OpenOTP PIN“ 1
OPNSense
- Im Suchfeld (Lupe): export
- Custom config: static-challenge „Please enter your OpenOTP PIN“ 1
- Hier gibt es keine <Save Button> - einmal raus aus dem Feld und es wird automatisch gespeichert !!
- User: o.leister - <download> anklicken
- VPN: OpenVPN: Client Export
Browser download
- Zertifikate auswählen und anklicken
- Wird in derApplikation geöffnet
Zurück im OpenVPN Client
- Import .opn profile
- <OK>
- Username: o.leister
- <CONNECT>
- Please enter your OpenOTP PIN
- Response: <PIN aus der Handy App>
- <Send>
- Authentication failed —> falsche Reihenfolge …
- Abfrage Password: <password von o.leister>
- <OK>
- Multi-factor authentication
OPNSense
- System: Access: Server
- Reverse token order: Haken herausnehmen —> kein Haken gesetzt
- <save>
- LDAP-UCS 2fa - Stift (Edit)
Zurück im OpenVPN Client
- Richtige Profil auswählen
- Connect Schalter auf ON schieben
- Password: <password von o.leister>
- <OK>
- Please enter your OpenOTP PIN
- Response: <OTP PIN aus Handy App>
- <SEND>
- Verbindung steht —> grün connect Button
- Enter Password
- Multi-factor authentication
- Verbindung wieder trennen
- Jetzt kann der User sein Passwort wieder im Profil speichern
- Richtige Profile auswählen
- Edit
- Haken vor Save Password
- Password: <password von User o.leister>
- <save>
- Richtiges Profil auswählen
- Connect Schalter auf ON schieben
- Please enter your OpenOTP PIN
- Response: <OTP PIN aus Handy App>
- <SEND>
- Verbindung steht —> grün connect Button
- Multi-factor authentication
- Verbindung wieder trennen
- Bridges
OPNSense (Bridge Server)
- Im Suchfeld (Lupe): open
- VPN: OpenVPN: Servers [legacy]
- Description: BridgeServer
- Server Mode: Peer to Peer (Shared Key)
- Device Mode: tap
- Shared key: Haken vor Automatically generate a shared key
- Auth Digest Algorithm: SHA256 (256 bit)
- <save>
- Shared key: zeigt den Static key an
- + /add
- Edit Eintrag
- Im Suchfeld (Lupe): Assign
- Interfaces: Assignments
- Device: opnsl (OpenVPN Server BridgeServer)
- Description: Bridgeinterface
- <Add>
- Interfaces: [Bridgeinterface]
- Enable. Haken setzen
- Hinweis: Es wird nichts konfiguriert
- <save>
- <apply>
- + Assign a new Interface
- Interface [Bridgeinterace] —> Link in eckiger Klammer anklicken
- Im Suchfeld (Lupe): Bridge
- Interfaces: Other Types: Bridge
- Member interfaces: Bridgeinterface, LAN
- Description: Bridge
- <save>
- + / add
Da es gerade im Netzwerk ist, werde ich das mal ändern.
Browser
- PVE: PVE3 im RZ
- Hardware
- Bridge: vmbr0
- Disconnect: Haken setzen
- <ok>
- Bridge: vmbr99
- Disconnect Haken heraus nehmen
- <ok>
- Edit Network Device net0
- Edit Network Device net0 - vmbr0 wird auf Tote Bridge vmbr99 umgehängt - damit da ja nichts passiert
- Hardware
CLI Studio
- ping 192.168.0.99 —> wird nicht mehr erreicht
Browser
- OPNSense in Aschaffenburg - office.sysops.de:4444
- Im Suchfeld (Lupe): open
- Clone von OPVN Bridge RZ
- Host or Adress: openws.sysops.de
- Port: 1194
- Shared key: <Hier den Shared von opnws.sysops.de (Server) herein kopieren>
- Encryption algorithm (deprecated): None —> soll er selber verhandeln
- Auth Digest Algorithm: SHA256 (256 bit)
- Description: OVPN Bridge WS
- Server Mode: Peer to Peer (Shared Key)
- Device Mode: tap
- Interface: TelekomFTTHPPoE
- Remote Server:
- Cryptographic Settings
- <save>
- Man sieht an den Bytes Sent und Bytes Received das die beiden Verbunden sind
- Clone von OPVN Bridge RZ
- VPN: OpenVPN: Clients [legacy]
- VPN: OpenVPN: Connection Status
- Im Suchfeld (Lupe): assig
- Device: opnc3 (OpenVPN Client OVPN Bridge WS
- Description: OVPNBridgeWS
- <add>
- Interfaces: Assignments
- + Assign new interface
- Interface: [OVPNBrigdeWS] - anklicken
- Enable: Haken setzen
- Hinweis: es wird nicht konfiguriert
- <save>
- <apply>
- Im Suchfeld (Lupe): Bridge
- Edit
- LAN, OVPNBridge, OVPNBridgeWS
- <save>
- Interfaces: Other Types: Bridge
- Im Suchfeld (Lupe): open
- OPNSense (Bridge Server)
CLI
- ping 192.168.0.99 —> geht nicht, vermutlich eine Kleinigkeit übersehen
Es bringt nichts, da ich keine Standorte habe mit denen ich das Testen kann.
Rückabwicklung der Bridge
Chriz zeigt es nochmal am Beispiel RZ.
SOPHOS
- Redboxen sind die Clients
- Evtl wird noch ein LAN da gesteckt, damit die alle in einen Netz sind
Hinweis von Chriz: Es gibt einen alias Typ OpenVPN group, aber hat sich Chriz noch nicht weiter angeschaut. Damit kann man Regeln auf User Ebene machen. (IP Address) Chriz nutzt die Group nicht.
Unter Firewall: Diagnostics: Aliases sieht man die eingewählten IP Adressen.
Im Stammtisch gab es die Frage, ob das auch mit LDAP funktioniert.
LDAP Gruppen können vermutlich nicht importiert werden, damit können die auch nicht OpenVPN group verwendet werden.
Es kann nur eine local Gruppe angelegt werden und dort können die LDAP User hinzugefügt werden.
Und dann kann man einen Alias machen.
- Mailgateway
SOPHOS
- Email Protection
- SMTP
- SMTP Profiles
ProxMox Mail Gateway müssen wir raus NATen, wir schauen das mal bei uns an.
Browser
- Opensense RZ
- Quelle: Internet
- Ziel: Mail Gateway
- Port für Quelle und Ziel gleich
- Port: 8006 —> Web Interface
- Port: 26 —> Port 26 muss nicht zwingend nach draußen gelegt werden, über den Port werden die Mail raus geschickt, je nachdem wie Du aufgestellt bist
- Port 25
- Im Suchfeld (Lupe): nat
- Firewall: NAT: Port Forward
ProxMox
- Local Data Store
- Reiter Templates
- Template wird heruntergeladen
- ProxMox Mail Gateway Version …
- Download
- Reiter Templates
- CT Templates
- Create Container
- CT ID: 101
- Hostname: pmgtest
- Password: <password>
- Confirm password: <password>
- <Next>
- Template: ProxMox Mail Gateway auswählen
Die Installation des ProxMox Mail Gateways sollte jeder hin bekommen, Chriz spart sich die Installation.
Browser
- ProxMox Mail Gateway im Browser mit dem Port 8006 aufrufen
- Einrichtung: Bilder zur Einrichtung
- Dazu gibt es ein Video, das wird gleich in die Themenstruktur aufgenommen
- Einrichtung dauert min. 1 Stunde
- Die Bilder zeigen das stupide Einrichten des Mail Gateways
- Configuration
- Reiter Relaying
- Reiter Domains —> diese Domain relayen wir
- Reiter Ports —> Hier können die Ports angepasst werden
- Bei Chriz ist mehr auf dem UCS los
- tail .f /var/log/mail.log
- Test Mail nach außen geht über das ProxMox Mail Gateway und es geht an den Mail Piler
- Beispiel Leister UCS: mail/relayhost: 192.168.50.253:26
- Reiter options
- Message Size (bytes) —> Mail Größe für eingehende und ausgehende Mail - Empfehlung 10 MB
- DNSBL Sites: —> weniger ist mehr …
- Use Greylisting for IPv4: yes —> Mehrfach Anfragen
- Use SPF: yes —> SPF Record muss vorhanden sein
- SMTPD Banner: -> so meldet sich unser Server
- Reiter Transports —> Server Eintrag wohin die Domain gehen soll - kein MX - eingehend
- Host: —> eintragen
- Protocol: SMTP
- Port: 25
- Use MX: kein Haken setzen
- Reiter Networks —> für das Relayen von eben - kannst Du nur an Port 26 schicken, wenn es in der Liste steht
- Reiter TLS —> gibt es in der Webseite und im SMTP Server
- Enable TLS: yes
- Enable TLS Logging: yes
- Add TLS receiver header: yes
- Reiter ACME Accounts/Challenges
- Hetzner
- Zertifikat für Web Oberfläche
- Zertifikate für SMTP
- Challenge Plugins
- Certificates
- Reiter DKIM
- Mail wird raus geschickt und mit DKIM signiert
- Empfänger vergleicht den DKIM mit dem DNS Eintrage der Domain
- Reiter Whiteliste —> Wunderbar Whitelisten
- Mail Proxy —> der wichtigste Part
- Certificates —> Wer sich erinnert Hetzner Plugin
- Mail Proxy —> zurück zum Mail Proxy - restliche Reiter
- User Management
- Nur Whiteliste zu pflegen oder eine Quarantäne Mail freizuschalten
- Reiter LDAP
- Virus Charts
- Avast —> ist gut (findet Betrugsmaschen), ist aber sehr teuer und zickig - findet viel mehr als clam AV
- Reiter Summary
- Hängen hier Sachen
- Button <Flush Queue>
- Reiter Deferred Mail —> wo geht das Zeug hin
- Filter: …
- Dann sieht man was da hängt
- Einloggen
- Hinweis: In der Themenstruktur findet man die ganzen Bezüge dafür
- Wir schauen uns an was es bedeutet
- Mail Filter —> Hier würde Chriz nichts verändern, er ist damit gescheitert
- Cluster —> Du kannst das PMG sehr geil Clustern
- Subscription —> Hab ich auch
- Statitistics
- Queues
- Tracking Center —> wissen was passiert ist
- User Whitelist —> Mail kann Whiteliste hingefügt werden
- User Blacklist —> Mail kann aber auch der Blackliste hinzugefügt werden
- Hinweis: Über die Quarantäne Mail kann auch ohne Web Login auf die Blacklist oder Whiteliste eingestellt werden
SOPHOS
- Gab es den geilen Mailmanager, den gibt es im PMG nicht
Verschlüsselung mit Proxmox, ZFS und Debian / Windows
Hier mal zur Überlegung was für einen Sinn macht
Physischer PC
- Festplatte
- Partition mit FS
- Mount / c:\
- Partition mit FS
Proxmox LXC
- Festplatte+Festplatte als Raid
- Dataset
- Mountpoint /rpool/data/subvol-100-disk-0
- Dataset
Proxmox LXC ZFS verschlüsselt
- Festplatte+Festplatte als Raid
- Dataset entsperrt
- Mountpoint /rpool/data/subvol-100-disk-0
- Dataset entsperrt
zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on
#Datastore im PVE anlegen auf rpool/encrypted
nach Reboot zfs load-key #Passphrase eingeben, dann pct start xxx
Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen
Proxmox VM
- Festplatte+Festplatte als Raid
- ZVOL
- Gast Partition mit FS
- Mount / c:\
- Gast Partition mit FS
- ZVOL
Proxmox VM ZFS verschlüsselt
- Festplatte+Festplatte als Raid
- ZVOL entsperrt
- Gast Partition mit FS
- Mount / c:\
- Gast Partition mit FS
- ZVOL entsperrt
zfs create rpool/encrypted -o keylocation=prompt -o keyformat=passphrase -o encryption=on
#Datastore im PVE anlegen auf rpool/encrypted
nach Reboot zfs load-key #Passphrase eingeben, dann qm start xxx
Alternativ kann man das auch von außen alle Stunde auf Verdacht oder nach Prüfung per SSH auslösen
Proxmox VM Gast verschlüsselt
- Festplatte+Festplatte als Raid
- ZVOL
- Volumemanager
- LV mit encrypted FS
- entsperrter Mount / c:\
- LV mit encrypted FS
Verschlüsselung wird bei der Installation vorgenommen. Nach jedem Reboot muss das Passwort in KVM Konsole von Proxmox eingegeben werden. Automatisierung nicht möglich
Abschließend ist das Ziel zu prüfen. Verschlüsselung gegen Diebstahl ist die ZFS Lösung völlig ausreichend. Replikation geht mit Raw (send -w), Backup nur wenn entsperrt ist. Eine Sicherung einer intern verschlüsselten VM ist jederzeit, mit jeder Methode (PBS, ZFS) möglich, muss halt in jeder VM vorgenommen werden, LXCs lassen sich verschlüsselt nur gegen Diebstahl schützen, nicht gegen Einsicht.
Proxmox Best Practice Setup für ZFS und / oder Ceph im Cluster für Einsteiger (Stand Dezember 2024)
Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 15 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS
Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine Ceph Expertise vorhanden!
Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de
18.12.2024 - 11h Proxmox Best Practice Cluster mit ZFS + Ceph für Einsteiger
ZFS ist die perfekte Grundlage für kleine und mittlere Kunden komplett unverwundbar gegen Ausfall, Trojaner und vor allem Dummheit zu sein.
Ceph ist die Basis der höchsten Verfügbar- und Skalierbarkeit
In diesem Kurs vermitteln wir ZFS und Ceph Grundkenntnisse für Proxmox
Achtung: Das Tempo dieses Kurses ist relativ schnell, dafür werden alle Schritte mit Screenshots dokumentiert!
Er eignet sich für den schnellen Einstieg mit mit Wissen aus zuverlässiger Quelle.
Dauer ca 4h+
- Basisinstallation Proxmox VE mit EFI auf ZFS
- Installation und Hinweise auf Fehlerbehebung von PVE-Clustern
- Einrichtung eines einfachen Ceph Clusters
- Musteranlage einer VM und LXC für höchste Leistung und Platzersparnis
- Konfiguration einer Hochverfügbarkeit für eine VM
- Replikation mit Bordmitteln und deren Erfolgskontrolle
- Automatisches Snapshotting von ZFS + Ceph mit CV4PVE + Admin GUI
- Einrichtung Proxmox Backupserver auf LVM oder ZFS mit Sicherheitsoptimierung
- Monitoring mit Check_MK plus Special Agent
Nach diesem Kurs kannst Du Proxmox im Cluster sicher und einfach betreiben.
Für erweiterte Trojanerabwehr bitte den Trojanersicherkurs besuchen.
Der folgende Artikel eignet sich besonders für Einsteiger die mit mehr als einem Host im Cluster starten müssen.
Der Bezug auf Ceph soll lediglich zum Funktionsvergleich dienen. Wir empfehlen bis 10 Hosts immer ZFS!
Installation Proxmox
Ein System hat extra Platten für unseren Workshop, zwei wurden bereits installiert.
Es kommt der HPE Microserver Gen10 Plus V2, vorzugsweise mit ECC, zum Einsatz
Wir installieren mindestens einen Raid1, 10 oder Z, niemals auf Basis eines Hardware Raid Controllers!
Für Cluster dringend alle IPs und Namen vorher klären, sonst kommt es zu späteren Zusatzarbeiten für den Cluster
Cluster mit drei PVE erstellen
Cluster wird in Sekunden erzeugt, ein Node alleine läuft problemlos
Cluster Nodes hinzufügen
Nodes mit den Join Information des ersten Clusternodes in der Zwischenlage auf neuen Node unter Join Cluster Einfügen und Rootpasswort und Clusternetz(e) bereitstellen
Der neue Node wird im Vorgang die Verbindung zum Browser verlieren, da er Schlüssel und Zertifikate des Clusters übernimmt. Der Browser muss neu geladen werden. Danach ist die Administration von jedem Clustermitglied aus möglich.
Lokale Storages benötigen lokalen Login zum Einrichten
Postinstaller für erweiterte Funktionen
Unser Postinstaller vom #Bashclub funktioniert am besten mit Standalone.
Für unser Setup verzichten wir auf Autosnapshots für rpool/data, also dem local-zfs Store und auf das SSH-Hardening, aus Kompatibilitätsgründen
Diese Zusammfassung zeigt die für unser Setup günstigsten Settings, mehr Kontext im Kurs
Demonstration ZFS Raid
Software Raid mit ZFS ist ultra schnell bei Problemen entstört. Der direkte Zugriff auf die Platten bringt via Monitoring Probleme vor Ausfall zum Vorschein. Im Beispiel packen wir eine Platte vor Reboot offline, bitte nicht nachmachen!
Trotz defektem Raid zeigt das Summarydashboard kein Problem. Hier muss mit Check_MK oder CV4PVE kontrolliert werden, oder...
S.M.A.R.T Kontrolle via GUI aus Erfahrung oft noch ohne Fehler, während unser Check_MK Plugin schon Probleme erkennt!
Mühselige Kontrolle aller Systeme via GUI pro Host ist nicht praxistauglich!!!
Musterinstallation Linux / Windows als VM
Der Postinstaller stellt die aktuelle Windows Treiber ISO in der Stabilen Version bereit, der Proxmox Installer das zweite Laufwerk dafür
i440FX als Maschinentyp und Bios sind inzwischen eher zu vermeiden, schliesslich soll der Kram lange laufen.
Funfact, i440FX war für die Pro Version des ersten Pentiums, dung ding da ding!
Proxmox VE legt im ZFS oder Ceph ebenfalls einen Blockstorage für TPM und EFI Einstellungen an, diese werden Raw ohne Dateisystem geschrieben und haben nichts mit der EFI-Boot-Partition zu tun.
Die native Bildschirmauflösung des Systems wird in der VM beim Starten mit ESC eingestellt.
Der Virtio SCSI single Controller wird im Host als eigener Prozess und im Gast als eigener Controller pro Disk aktiviert
Der Qemu Agent sorgt für Shattenkopien, Freezing, Herunterfahren und mehr!
Die Kombination von Discard, SSD Emulation, wie auch IO thread gibt bessere Auslastung und Entlastung von gelöschten Daten an den Host
CPU Typ Host ist für identische Hardware in Clustern und Standalone zu bevorzugen, da hier alle Prozessorfunktionen genutzt werden
Ballooning spart RAM beim einschalten und macht noch mehr. Treiber unter Windows sind notwendig
Virtio Netzwerkkarten brauchen unter Windows eigene Treiber, performen aber bis 100Gbit
Die eingebaute Replikation ist erst mal gut genug, auch wenn es mit Zsync besser geht. Dafür hat man, leider nur in der VM hier, Kontrolle über den Erfolg. Löscht man den Job, löscht sich das Replikat
Das Zeitfenster ist mit 15-60 Minuten optimal, mit einer Minute perfekt. Jedoch sollte man nicht jede VM auf eine Minute stellen. da hier das ZFS Auflisten zu Timeouts führt.
Autosnapshotting ist nicht vorgesehen, leider!
Linux unterstützt alle Virtio Laufwerke und Netzwerkkarten nativ
Installation Ceph
Der Assistent installiert die notwendigen Repositories. Wir empfehlen hier wenigstens die Community Subscription zu nehmen, da ein defekter Ceph-Cluster ein Single-Point-of-Failure ist
Die Auswahl der Netze für Cluster, Ceph, Rendundanz und weitere Segmentierungen sollten von einem Erfahrenen Fachmann vorgenommen werden. Wir empfehlen hier Inett aus Saarbrücken
Im aktuellen Setup können wir zum Testen nur das LAN nehmen, das wir ausdrücklich so nicht empfohlen!!!
Die Installation muss auf allen Clustermitgliedern wiederholt werden, wobei die Konfiguration via PVE Cluster übernommen wird
Jeder Host bekommt mindestens eine SSD als sog. OSD, ab drei Stück haben wir einen funktionierenden Ceph Cluster, ohne extra Sicherheit. Als Nettonutzplatz erhalten wir 1/3 der SSDs, in dem Fall knapp 1TB
Auf keinen Fall dafür in irgendeiner Weise Hardware Raid Controller nutzen!!!
Ceph OSD Einrichtung
Ceph Pool anlegen
Der Pool verbindet die OSDs zum Verbund, die Rolle Monitor und Manager können auf mehrere Nodes verteilt werden, sonst wäre der Reboot des ersten Nodes nicht ohne Schaden möglich!
VM Migration Node zu Node
Die Übertragung einer laufenden VM oder eines LXC mit Shutdown ist bei ZFS und Ceph möglich.
Wärend bei CEPH der Speicher verteilt ist, muss bei ZFS RAM und Disk nocheinmalübertragen werden.
Bei vorheriger ZFS Replikation ist das meiste der VM schon auf dem Ziel und kann inkrementell ergänzr werden.
Gab es vorher keine Replikation muss die komplette VM übertragen werden.
Das Mittel der Übertragung ist je nach Zustand der VM via KVM oder ZFS möglich.
Ersteres würde zum Verlust von Snapshots führen!
Klonen zwischen ZFS und Ceph
Proxmox kann mit Bordmitteln die meisten Formate konvertieren.
Qemu-Guest-Agent Installation
Dieses Paket für geordnetes Herunterfahren immer mitinstallieren und starten!
IO Leistung der Systeme bei diesen Voraussetzungen
ZFS ist dreimal schneller und auf zwei Kisten verfügbar
Wir gehen von der sechsfachen benötigten Leistung aus um Leistungsmässig an ZFS Raid1 zu kommen
Login für Root und PVE User mit zwei Faktor absichern!
Weitere User benötigen entsprechende Rechte!
Login Realm ist Linux User oder Proxmox Userbasis
Es können in der GUI keine weiteren Linux/PAM User angelegt werden, jedoch GUI aktiviert
SSH Daemon gegen Passwort Login absichern
Eigene virtuelle Switche für VMs trennen das Verwaltungsnetz ab
Wenn die Resourcen vorhanden sind, dringend dafür sorgen daß Anwender und Gast VMs keinen Zugriff auf Proxmox VE, Switche und Firewalls haben
Ein Blick auf ZFS klärt nicht welche VM auf welchem Host aktiv ist!
PVE1 und zwei sind auf den ersten Blick nicht zu unterscheiden, auch nicht mit Snapshotauflistung
Unser erweitertes Ablagekonzept macht die Funktion von abgelegten Daten viel deutlicher. Mehr auf cloudistboese.de
Prüfung der Replikationen muss mühselig pro VM vorgenommen werden
Leider zeigt das PVE Dashboard weder defekte Platten, noch Raids oder Replikationen in der Übersicht an. Hier wird später Check_MK oder CV4PVE für Übersicht sorgen müssen!
Postinstaller sichert komplette Konfiguration und dessen Historie mit Rsync und ZFS-Auto-Snapshot
Üblicherweise nutzen wir zfs-auto-snapshot gnadenlos auf alle Datasets und Volumes
Die Proxmox Konfiguration liegt jedoch in einer Datenbank und wird nach /etc/pve gemountet
Diesen Ordner sichern wir regelmässig nach /rpool/pveconf und bauen mit Autosnapshots eine Historie
Hochverfügbarkeit einer VM / HA
Die HA Engine sorgt dafür daß VMs / LXC bei Ausfall eines Hosts auf einem anderen Host gestartet werden.
Der Übergang dauert mindestens zwei Minuten, wobei nur bei SAN oder CEPH kein Datenverlust entsteht
Bei ZFS verliert man dier die Replikationslücke!
Daher eignet sie sich am besten für Firewalls und Telefonanlagen
Die HA Gruppe definiert die gewünschte Ausführungspriorität, wobei höher mehr Prio hat
Prio 1 ist am niedrigsten
Die VMs werden den Gruppen zugewiesen und definieren unseren Wunschort und Zustand
Da PVE1 die höchste Priorität hatte wird VM 100 sofort dort hin migriert, die Replikation umgedreht
Wird ein Node neu gestartet, werden die VMs nicht automatisch umgezogen, sondern heruntergefahren.
Die Weboberfläche eines anderen Nodes muss dann geöffnet werden, die VMs vorher umgezogen werden!
Bei Ceph sollte es kein Problem sein einen Node neuzustarten, jedoch muss dafür der Cluster redundant gebaut sein. Sonst besser alle VMs stoppen
Manuelle und automatische Snapshots
Manuelle Snapshots via GUI oder API werden mit dem passenden Datastoresnapshot ausgeführt, also ZFS, Ceph oder KVM
Bei ZFS werden diese Zustände mitrepliziert und die Konfigurationsdatei um diesen Zustand erweitert
Automatische Snapshots Monitoring und Management mit CV4PVE-Admin
kann eine sinnvolle Alternative zu zfs-auto-snapshot sein und ergänzt wichtige, fehlende Einblicke der PVE GUI
Diese Anleitung scheint die sinnvollste, bitte auf eigene Maschine
Eigener PVE User plus gewünschte Rechte sind hier erklärt
Alle Replikationen mit Bordmitteln im Blick, nicht mehr jede VM muss aufgeklappt werden
Automatische Snapshots können hier definiert werden, jedoch muss das Teil auf laufen
ZFS Snapshots können via GUI nur einzeln zurückgerollt werden, hier ist Ceph im Vorteil
Replikation bricht nicht bei Rollback
Proxmox kann von HW Raid, ZFS, BTRFS, jedoch nicht von Ceph booten
Den Ceph Zustand kann man nicht mit Check_MK Bordmitteln prüfen
Datensicherung mit Proxmox Backup Server
Proxmox kann nativ erst mal nur eine Vollsicherung
Erst der Proxmox Backup Server bringt inkrementelle Backups und Management
Er kann auf einen bestehenden PVE installiert werden, alternativ auch als LXC
Die Repos fehlen jedoch hier
Hier wäre aktuell Bookworm
Zugriff in diesem Fall via PVE3 auf Port 8007 mit SSL
Das Dateisystem könnte mit BTRFS, ZFS oder Ext4 bereitgestellt werden, wobei Ext4 keine Snapshots zum Absichern von Backups beherrscht, dafür 100% Platzausnutzung
Der Backupstore wird als Mountpoint bereitgestellt. SMB performt hier sehr schlecht
Root User plus Backupuser werden mit 2fa abgesichert!
Für die Sicherung benötigen wir einen Token auf den Backupuser
Backup Benutzer und -Token benötigen die Berechtigung Datastore Backup
Für den Datastore in PVE benötigen wir mehrere Parameter
Oben den Datastorenamens seitens PVE, den Tokennamen wie sein Passwort.
Auf der Rechten Seite der Datastorename aus dem PBS und unten dessen Fingerabdruck, den wir auf der Startseite des PBS finden
Danach taucht der Backupstore in jedem PVE auf, wenn gewünscht
Achtung, das Bootvolume von PVE ist per Default auch als Backupstore definiert, weg damit!
Erstes manuelles Backup zeigt den Dirty-Bitmap Status: created-new, was eine Vollsicherung bedeutet
Die zweite Sicherung wird dann inkrementell durchgeführt, bis die VM gestoppt wird!!!
Löschen einer Sicherung ist gewollt nicht über PVE möglich, in PBS kann man das manuell durchführen oder automatisch.
Der Platz wird erst nach einem Prune lauf freigegeben!
Nach einem Reboot des Hosts oder Stoppen des Gasts wird wieder eine Vollsicherung durchgeführt, jedoch nur neue Chunks auf das Ziel geschrieben. Dadurch geht das auch noch relativ flott. Siehe die MB angaben unten bei der Sicherung
Für den automatischen Lauf immer VMs ausschliessen oder alles mitnehmen. Eine Auswahl der VMs führt zu Fehlern über die Zeit durch Unterlassung
Die Retention, also das Aufräumen hier ist nicht sinnvoll, noch möglich
In Prunejobs regelst Du die Aufhebezeiten und die Ausführung der Regel, was aber nur für die Auswahl relevant ist. Der Vorgang geht relativ schnell
Der Simulator von Proxmox hilft dabei
Die Garbage Collection räumt dann alle Junks auf die in keinem Backup mehr benötigt werden.
Der Vorgang hat hohe Last und dauert, also bei Stilstand ausführen
Der Verify Job überprüft regelmässig die Vollständigkeit der Junks und die Integrität der Backups. Der Erfolg wird in der Rechten Spalte in PVE und PBS angezeigt
Optional Replikationskontrolle mit checkzfs von #Bashclub
Da unklar ist welcher Host gerade welche ZFS Maschine aktiv betreibt, bleibt uns nur den Vergleich aller Datastores gegeneinander.
Der Vorgang sollte nur ausgeführt werden wenn gerade keine Replikation läuf, sonst spuckt er Fehler
Für diesen Anwendungsfall ist eventuell CV4PVE einfacher, da es auch viele Teile vom Monitoring übernimmt
Vielen Dank für Ihre Aufmerksamkeit
Christian-Peter Zengel (sysops.tv)
Resourcen
https://aow.de/books/ubersicht-des-projekts/page/prospekt - Unser aktueller Prospekt
https://aow.de - Linkliste zu allen Projekten
https://cloudistboese.de - Schulungsportal, alle Kurse können kostenfrei wiederholt werden. Kurse meist online, auch vor Ort
http://youtube.com/sysopstv - Livesendung Montags und Donnerstags gegen 17:15h, Donnerstags Stammtisch online
ZFS Grundlagen am Beispiel Proxmox VE(Stand Januar 2025)
Der Verfasser des Artikels, Christian-Peter Zengel, hat zum Zeitpunkt des Artikels ca 15 Jahre Erfahrung mit ZFS und Proxmox. Er betreibt aktuell ca 150 Systeme mit Proxmox und ZFS
Das Einsatzgebiet geht von Standaloneinstallation bis zu ca 10 Hosts im Cluster. Es ist keine Ceph Expertise vorhanden!
Dieser Dokumentation basiert auf diesem online Kurse von cloudistboese.de
21. + 23.01.2025 (13.00 Uhr bis 17.00 Uhr) - ZFS Grundlagen
ZFS ist die perfekte Grundlage für kleine und mittlere Systeme um gegen Ausfälle, Dummheit anderer und Erpressungstrojanern ideal aufgestellt zu sein.
In diesem Kurs erhalten sie Grundkenntnisse für Systeme wie Proxmox, TrueNAS oder ähnliche Systeme.
Der Fokus liegt auf der Technologie und der permanenten Sicherheit im Umgang mit Daten, Linux und dem Terminal.
Themen:
- Begrifflichkeiten und Überblick
- Basisfunktionen von Proxmox und TrueNAS per GUI
- Erklärung und Beispiele Snapshots und Rollbacks
- Praxisbeispiele Replikation
- Prüfung der Replikationen
- Weitere Features die das Leben massiv erleichtern
Nach diesem Kurs bist Du bei Ausfällen und Datenverlust vor dem Schlimmsten geschützt und in Minuten wieder produktiv!
So erstellt Proxmox VE seinen ZFS Raid
zpool create -f -o cachefile=none -o ashift=12 rpool mirror disk1 disk2
Destruktives Anlegen (-f), kein automatisches Importieren beim Start (-o cachefile=none)
-o ashift=12 ist für 4k Festplatten, ashit=9 für 512e Disks, wobei man mit 12 nichts verkehrt macht
rpool ist der Name vom künftigen Pool, mirror der Raidlevel und die Disks wurden zweifelsfrei über Ihre ID definiertOptionen für Raidlevel wären noch: ohne als Stripe, raidz, raidz2 oder raidz3, also Raid Level 5-7
Die ersten Zpool Manöver und die endlose Aktionsliste sieht man mit
zpool history
Manuelles Trimmen der SSDs um gelöscht Blöcke schner überschreiben zu können findet man unter /etc/cron.d
Ebenso wird nach diesem Zeitplan der sog. zpool scrub durchgeführt, der die Konsistenz der Redundanz prüft und ggf. korrigiert. Gefundene Fehler findet man dann mit zpool status
Zum identifizieren der Platten bieten sich neben der PVE GUI noch folgende Befehle an. Es wird dringend empfohlen bereits genutzte Platten via PVE GUI zu wipen
dmesg -Tw (live)
lsblk
ls -althr /dev/disk/by-id
Erstellen verschiedener Raidlevel und Ihrer Vorzüge
Mit ls -althr /dev/disk/by-id haben wir folgende Festplatten anhand ihrer aufgedruckten WWN Kennung identifiziert. Es ist dringend empfohlen bei HBAs sich die Slots und die Seriennummern beim Einbau zu notieren und in die Dokumentation aufzunehmen
wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8 wwn-0x5000cca01a8417fc
Stripe, also Raid0
zpool create -f test wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8
Mirror, also Raid1
zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c
Striped Mirror, also Raid10
zpool create -f test mirror wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c mirror wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 mirror wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8
RaidZ, also Raid 5, Nettoplatz x-1
zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8 wwn-0x5000cca01a8417fc
RaidZ2, also Raid 6, Nettoplatz x-2
zpool create test raidz2 wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8 wwn-0x5000cca01a8417fc
RaidZ-0, also Raid 5-0, Nettoplatz x-2, in diesem Beispiel
zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8
oder mit Spare, wenn Du davon nicht booten musst
zpool create test raidz wwn-0x5000cca01a72ded4 wwn-0x5000cca01a7b1e2c wwn-0x5000cca01a83a61c raidz wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8 spare wwn-0x5000cca01a8417fc
Erweiterung eines RaidZ zum RaidZ-0
zpool add -n test raidz wwn-0x5000cca01a832d24 wwn-0x5000cca01a83331c wwn-0x5000cca01a7495b8
Erweiterung eines Raid durch Ersetzen mit größeren Platten
Die Platten müssen die Gleiche Geometrie hanben, also 4k zu 4k oder 512e zu 512e
Bei Raid 1 und 10 reicht es zwei Disks zu tauschen, bei RaidZx müssen alle Disks getauscht werden
Replace Vorgänge können auch laufen ohne die Redundanz zu brechen, wenn weitere Slots frei sind
Bei Erweiterung durch Austausch von großen und vor allem älteren Raid 10 prüfen ob in einem Mirror ggf. neue Platten getauscht wurden, diese sollten weiter im Betrieb bleiben, während ältere Paare getauscht werden können
Caches und Logdevices
Vorsichtig formuloiert, Lese- und Schreibcache
First Level Cache, sog. ARC kommt aus dem RAM und bekommt idealerweise ca. 1GB für 1TB Nettodaten
Second Level Cache wird als Cachedevice als Partition auf einer schnelleren Disk als der Pool hat bereitgestellt, z. B. am idealsten mit NVMe
zpool add test -n cache sdl
Logdevice (Writecache muss gespiegelt werden)Damit der Log auch genutzt wird muss man noch mit zfs set sync den cache aktivieren
zpool add test -n log mirror sdl
zfs set sync=always test
Arc wird mit "arcstat 1" ausgelesen, er wird bei der Installation festgelegt oder später unter /etc/modprobe.d/zfs.conf geändert. update-initramfs -u macht das dann persistent und aktiviert die Änderungen beim nächsten reboot.Zur Laufzeit ändert man den Firstlevelcahce mitCache- und Logdevices mit zpool iostat 1
echo 2147483648 > /sys/module/zfs/parameters/zfs_arc_max
echo 1073741824 > /sys/module/zfs/parameters/zfs_arc_min
free -h && sync && echo 3 > /proc/sys/vm/drop_caches && free -h
arcstat 1
Test der Leistung eines Pools
zfs create -o compression=off test/speed
cd /test/speed
dd if=/dev/zero of=dd.tmp bs=256k count=16384 status=progress
dd if=/dev/zero of=dd.tmp bs=2M count=16384 status=progress
Erweiterung der Funktionen des Pools
zpool status meldet neue Funktionen im ZFS und kann leicht und schnell mit
zpool upgrade -a
erledigt werden
Jedoch würde ich in jedem Fall empfehlen zu prüfen ob meine Notfall ISO diese Funktionen bereits unterstützt!
Für das Auslesen der Parameter von Pools, Volumes, Datasets und Snapshots gibt es den Parameter get
Bereitstellen und entfernen von Pools ohne löschen
zpool import #zeigt was es zum importieren, also bereitstellen gibt
zpool import poolname oder -a für alle importiert den Pool oder alle verfügbaren Pools
Am elegantesten importiert man den Pool über
zpool import -d /dev/disk/by-id
damit man hinterher nicht sda, sdb, sondern die Bezeichner im Status sieht
Nach der Bereitstellung würde man hier lediglich einen Mountpoint /test finden, bei TrueNAS /mnt/test. Dazu noch die Systemdatasets vom Proxmox selbst. Danach legen wir gleich mal ein Dataset namens dateisystem und ein Volume namens volume an.
Datasets werden als Ordner gemountet und / oder /mnt
Volumes findet man unter /dev/zd... und zusätzlich mit vernünftigen Namen unter /dev/zvol/tankname/....
Datasets werden mit Linuxcontainern, Backupfiles, Vorlagen oder Serverdateien bespielt
Volumes verhalten sich wie eingebaute Datenträger, jedoch virtuell. Sie stehen nach dem Import des Pools bereit und können in einer VM genutzt werden. Manipulationen an Volumes zur Vorbereitung oder Datenrettung können jedoch ebenso auf dem PVE Host vorgenommen werden
Diese Schritte übernimmt üblicherweise der Installer in der VM und sollen nur aufzeigen wie diese ZVOLs genutzt werden
Proxmox legt seine Datasets für LXC so ab
und so die ZVOLs für VMs mit KVM, hier findet man die virtuellen Disk und /dev/zvol...
Thin- und Thickprovisioning für Datasets und Volumes
Am Beispiel von Proxmox VE via GUI wird hier eine Thinprovision Festplatte für VM 301 mit 32GB und einer Standardblockgröße von 16k erzeugt. 8k sind nur bei Raid1 und 10 möglich. Hakt man den Thinprovision Haken nicht an, wird beim Erzeugen noch die Option -o refreservation=32G ergänzt. Diese macht bei ZFS mit Autosnapshots aber keinen Sinn
zfs create -s -b 16k -V 33554432k rpool/data/vm-301-disk-4
rpool/data/vm-301-disk-4 56K 1.17T 56K - #hier kein Mount sonder unter /dev/zvol/...
Bei LXC werden Datasets genutzt und der Platz via Reservierung genutzt, wobei bei der genutzten Refquota auch die Snapshotaufhebezeiten den Nettoplatz verkleinern, daher größer dimensionieren, gerne mal doppelt so groß
zfs create -o acltype=posixacl -o xattr=sa -o refquota=33554432k rpool/data/subvol-106-disk-1
rpool/data/subvol-106-disk-1 96K 32.0G 96K /rpool/data/subvol-106-disk-1 #hostzugriff möglich
Virtuelle Diskimages wie QCOW2, VMDK oder RAW-Dateien legt man üblicherweise nicht in Datasets, bestenfalls für NFS oder iSCSI Server
Snapshots
Snapshots können jederzeit erstellt oder gelöscht werden. Die Datasets und Volumes befinden sich immer in einem Livezustand der sich durch die Vektorkette der eventuell vorhandenen Snapshots ergibt. Entfernt man einen Snapshot, so verändert sich der Weg der Vektoren. Das Ganze geschieht fast ohne Last!
ZFS selbst bringt weder Workflows für Snapshotting, noch Replikationen mit. Es stellt nur die Werkzeuge bereit
Snapshots generiert man bei Proxmox offiziell mit der GUI manuell oder für Replikationen, jedoch leistet dieser Workflow nicht genug.
Daher nutzen wir...
apt install zfs-auto-snapshot -y
ZFS-AUTO-SNAPSHOT legt seine Verknüpfungen in alle Cronordner. Proxmox VE weiß erst mal nichts davon. Zu berücksichtigen ist hier lediglich daß wir den Pool nicht über 80% befüllen wollen. Gehen wir darüber hinaus, müssen wir in den Cronordnern die Verknüpfungen anpassen um die Aufhebezeiten zu reduzieren.
nano /etc/crontab #kann angepasst werden, die viertelstündlichen finden sich unter cron.d!
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6 * * 7 root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6 1 * * root test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }
cat /etc/cron.hourly/zfs-auto-snapshot
exec zfs-auto-snapshot --quiet --syslog --label=hourly --keep=96 // #also in dem Fall 96 Stunden
Wir empfehlen für den Start folgende Settings: Drei Monate, sechs Wochen, zehn Tage, 96h und 12 Viertelstunden
Damit kommt man auf ca. 2,5x- 3x so viele Daten wie belegt wären ohne Snapshots. Erfahrungswert.
Das wären pro virtueller Disk oder LXC Mountpoint etwa 127 Snaphots, bei 20 Disks über 2540.
Nicht davon abschrecken lassen, es geht auch easy fünfstellig, wenn die IO stimmt!
Die in PVE eingebaute Snapshotfunktion sollte nicht mit den Autosnapshots kombiniert werden.
Im Problemfall stoppen wir die VM, manipulieren was zu machen ist und starten sie wieder!
Der eigentliche Vorteil der Snapshots in der GUI ist die Notierung der VM Definition zur Zeit der Erstellung, was wir über ein Backup im hauseigenen Postinstaller kompensieren. Dort findet man die Historie der PVE Config
Kleines manuelles Beispiel, was für uns aber Z-A-S übernimmt
Snapshot
zfs snapshot tank/sub/datasetodervolume@snapshotname
Auflisten
zfs list -t snapshot tank/sub/datasetodervolume
VM oder LXC ausmachen
Rollback
zfs rollback -r rpool/data/vm-100-disk-0@Test #danach ist alles neuere weg!
VM oder LXC starten
Dynamik von Snapshots
Wir unterscheiden zwei Sorten von Datennutzung
- Zunehmende Datennutzung wie bei einem NAS
- Es kommt nur was dazu und wird selten gelöscht
- Viele Snapshots auf lange Zeit ändern nichts an der Gesamtnutzung des Pools
- Replikation außer Haus kann in kleinen Schritten passieren, da die Gesamtübertragung gleich groß ist
- Rotierende Datennutzung wie bei einem Datenbankserver
- Daten verändern sich permanent, wenig Zuwachs
- Viele Snapshots auf lange Zeit ändern brachial viel an der Gesamtnutzung des Pools
- Replikation außer Haus sollte in einem Schritt, ohne Zwischensnapshots passieren, da die Gesamtübertragung sonst ein vielfaches größer sein kann
- Nur essenzielle Wiederherstellungspunkte sollten aufgehoben werden um das System nicht unnötig zu befüllen
Dynamik von Snapshots
Dank ZFS kann man langfristig Replikationen inkrementell vornehmen, jedoch dauert die erste Replikation natürlich länger, wenn schon Datenbestand da war
Übliche Vorgehensweise einer Datenübertragung
PC NTFS>SMB> Datei > SAMBA Server BTRFS LVM > EXT4 Datei = Konsistent? Bitrod?
Zu viele Köche verderben die Köchin
Funktion von Snapshotreplikation
Von ZFS zu Datei, was wenig Praxis findet
zfs send tank/dataset@snapshot > datei.zfs
zfs recv tank < datei.zfs
Von ZFS zu ZFS, was üblich ist
zfs send | zfs recv #laufen immer gleichzeitig
zfs send rpool/data/vm-100-disk-0@Test | zfs recv -dvF backuptank
#überträgt den Zustand Test auf ein lokalen weiteren Pool, wobei das zfs Tool immer doppelt läuft
Pushreplikation
zfs send -pvwRI rpool/data/vm-100-disk-0@Test rpool/data/vm-100-disk-0@zfs-auto-snap_hourly-2025-01-23-1317 | zfs recv -dvF backuptank
#Fortschritt, Infos, Rohdaten plus Historie, ideal für verschlüsselte Volumes, erspart das De- und Komprimieren
Workflow
- Erzeugen eines Datasets oder Volumes
- Snapshot auf Dataset oder Volume ausführen
- Übertragung des Snapshotzustands auf Ziel, optional mit Zwischenständen
Trojanerproblem: Wer auf Quelle sitzt kann Pushziele löschen
Lösung: Pullreplikation, ähnlich Backupsoftware, Transport SSH, Daten ZFS
Quelle |> Pullserver
zfs recv | ssh root@quelle zfs send #Pull Replikation via SSH
Von PVE zu PVE, was uns zu wenig ist
Proxmox baut selbst keine Notfallpunkte auf und nutzt ZFS nur als Transport, nimmt jedoch manuelle und automatisierte Snapshots mit, auch von Z-A-S!
Weitere Kopien per ZFS sind nur per Pushverfahren möglich, was ideal für Angreifer ist wenn sie alles löschen möchten. Ein Backupserver ist hier unverzichtbar, bei Pullreplikation gehts ggf. auch ohne. Außer Haus ist es nicht möglich ein ZFS Replikat zu senden, da sich der Partner im lokalen Cluster befinden muss!
Nondestruktiver Rollback nach Trojanerbefallt bei Forensikbedarf
OPNsense Migration Legacy zu Instance, ohne neues Ausrollen von Konfigurationen
Sicher habt ihr schon die Meldung der OPNsense Firewall unter OpenVPN / Legacy gesehen
This component is reaching the end of the line, official maintenance will end as of version 26.1
Die Migration zur Instanz ist nicht sonderlich kompliziert, jedoch gibt es zwei Fallstricke.
- Deaktiviert den alten Server
- Falls Shared Key verwendet wurde, unter Static Key diesen Text übernehmen, Mode Auth
- Konfiguriert eure neue Instanz mit mindestens diesen Einstellungen
- Role: Server
- Enabled: yes
- Port Number: wie bisher, z. B. 1194
- Type: TUN
- Server IP: Hier den alten Wert von IPv4 Tunnel Network übernehmen, z. B. 172.16.1.0/24
- Toplolgy: subnet
- Certificate: hier den alten Eintrag von Server Certificate übernehmen
- Certificate Authority: hier den alten Eintrag von Peer Certificate Authority übernehmen
- Dann links oben Advanced Mode einblenden
- Unter TLS static key den vorher angelegten Key auswählen
- Auth: den alten Wert von Auth Digest Algorithm übernehmen, z. B. SHA256
- Autentication: den vorherigen Serveranbieten, z. B. DC, UCS, Zamba auswählen, wenn vorhanden
- Renegotiate Time: 3600
- Auth Token Lifetime: 43200
- Local Network: den alten Wert von IPv4 Local Network auswählen
- Falls vorher bei Compression etwas ausgewählt war, selbst Disabled, dann Compression migrate unter Advanced anklicken
- Weitere Parameter falls benötigt
Der technische Stand dieser Dokumentation ist von April 2025 und funktioniert mit der Version OPNsense 25.1.4_1-amd64.
Die Business Edition 24.10 verfügt noch nicht über den Compression Migrate. Daher muss die Version Business 25.x abgewartet werden!
Beispiel
cz