In Cluster 1 wurde die technische Basis des LF10-Homelabs aufgebaut: Hyper-V-Unterbau, internes Firmennetz, Debian-Router und Linux-Client CL01. Der Router wurde als Übergang zwischen externem Lab-Netz und internem Homelab-Netz vorbereitet, inklusive IP-Forwarding und NAT/MASQUERADE. Während des ersten Internettests auf CL01 trat ein Fehler auf, der systematisch auf eine falsch eingetragene Router-LAN-IP in /etc/network/interfaces zurückgeführt wurde. Nach Korrektur von 192.169.10.1/24 auf 192.168.10.1/24 wurde der IP-basierte Internetzugriff von CL01 mit ping 1.1.1.1 belegt.

Cluster 1 schafft die Basiskonnektivität für Proxmox, SRV1, DHCP, DNS, Storage, Backup und Webdienste. Die Prüfkette führt vom virtuellen Switch über Router, IPv4-Forwarding und NAT bis zum erfolgreichen Verbindungstest auf CL01.

Ziel war es, ein isoliertes internes Lab-Netz aufzubauen, in dem CL01 über einen Debian-Router Internetzugriff erhält. Der Router sollte eine externe Schnittstelle im vorgegebenen Lab-Netz und eine interne Schnittstelle im Homelab-Netz besitzen. CL01 sollte statisch mit 192.168.10.50/24 konfiguriert werden und den Router unter 192.168.10.1 als Gateway verwenden.

Prüfkette vom Netzwerkaufbau bis zum Verbindungstest

Die Prüfkette verbindet den privaten Hyper-V-Switch, Router-WAN und -LAN, IPv4-Forwarding, NAT, die statische CL01-Konfiguration, die Fehlerdiagnose und den Verbindungstest nach der Korrektur.

Fehlerursache durch eine Prüfkette eingrenzen

Der Fehler mit 192.169.10.1 wird nicht geglättet. Er ist ein zentraler Troubleshooting-Fall, weil er zeigt, wie ein zunächst allgemeines Symptom „kein Internet“ durch systematische Prüfungen auf eine konkrete Ursache reduziert wurde.

Prüfreihenfolge nach der Korrektur

Die Prüfreihenfolge verbindet Switch-Zuordnung, CL01-Netzwerte, Gateway-Erreichbarkeit, Router-LAN-Adresse und den externen Ping. Der Tippfehler 192.169.10.1 wird dabei dem korrigierten Wert 192.168.10.1 gegenübergestellt.

Virtuelles internes Netz

Der private Hyper-V-Switch bildet das interne Firmennetz. Dieser Switch ist die Layer-2-Grundlage, über die CL01 und das interne Router-Interface miteinander kommunizieren sollen.

Prüfung: Hyper-V Switch Aussage: Sichtbar sind den Hyper-V-Kontext und die Erstellung bzw. Verwaltung eines privaten virtuellen Switches. Grenze: Nicht geprüft ist, ob Router und CL01 später korrekt miteinander kommunizieren.

Router: Forwarding und NAT

Der Router benötigt zwei Bedingungen für die spätere Weiterleitung von CL01-Traffic: aktiviertes IPv4-Forwarding und eine NAT-/MASQUERADE-Regel für das interne Netz.

Zwischenergebnis: Forwarding und NAT wurden technisch vorbereitet. Ein End-to-End-Erfolg liegt zu diesem Zeitpunkt noch nicht vor, weil CL01 den Router zu diesem Zeitpunkt wegen der später entdeckten LAN-IP-Abweichung nicht erreichen konnte.

CL01: statische IPv4-Konfiguration

CL01 wurde statisch für das interne Netz konfiguriert. Die relevanten Zielwerte waren:

IP-Adresse: 192.168.10.50/24
Gateway:    192.168.10.1

Die sichtbaren NetworkManager-Werte zeigen die manuelle Konfiguration; entscheidend bleiben Gateway- und Verbindungstest.

Initiales Fehlerbild: CL01 erreicht 1.1.1.1 nicht

Der erste Internettest auf CL01 schlägt mit Destination Host Unreachable beziehungsweise einer fehlgeschlagenen Route zum Ziel fehl. Damit beginnt die Prüfung von Route, Gateway, ARP und Router-LAN-Adresse.

Diagnose: IP und Default Route vorhanden, Gateway aber unerreichbar

Die nächste Prüfung zeigte, dass CL01 eine IP-Adresse und eine Default Route über 192.168.10.1 hatte. Trotzdem war ping 192.168.10.1 nicht erfolgreich. Damit wurde die Ursache enger eingegrenzt: Der Fehler lag nicht an einer vollständig fehlenden Route, sondern an der Erreichbarkeit des Gateways.

ARP/Neighbor-Diagnose: INCOMPLETE

ip neigh show meldete für 192.168.10.1 den Zustand INCOMPLETE. Das bedeutet, dass CL01 keine MAC-Adresse für den Gateway erhielt. Fachlich deutet das auf ein Layer-2-Problem, eine falsche Switch-Zuordnung oder eine falsche Router-LAN-IP hin.

Hyper-V-Switch-Zuordnung geprüft

Die Hyper-V-Zuordnungen verbinden CL01 mit dem Firmennetz und den Router mit externem Lab-Switch sowie Firmennetz. Damit ist die Switch-Zuordnung als primäre Fehlerursache unwahrscheinlich.

Ursache: Tippfehler auf dem Router-LAN-Interface

Die Router-Ausgabe zeigte auf eth1 die Adresse 192.169.10.1/24. Erwartet war 192.168.10.1/24. Damit befand sich das Router-LAN-Interface in einem anderen Subnetz als CL01.

CL01:       192.168.10.50/24
Gateway:    192.168.10.1
Router eth1:192.169.10.1/24   falsch

Der frühere Router-Beleg Router-LAN im falschen Subnetz – Fehlerbild wird hier bewusst als Fehlerbild eingebunden, weil er den Router vor der Korrektur mit der falschen LAN-Adresse zeigt. Er ist kein Erfolgsbeleg, sondern der direkte visuelle Beleg für das falsche Subnetz.

Die Ursache wurde zusätzlich in /etc/network/interfaces sichtbar. Dort war die falsche Adresse eingetragen.

Korrektur

Die IP wurde zunächst zur Laufzeit korrigiert und anschließend dauerhaft in /etc/network/interfaces berichtigt.

Test nach der Korrektur: CL01 erreicht 1.1.1.1

Nach der Korrektur konnte CL01 1.1.1.1 erfolgreich pingen. Damit ist IP-basierter Internetzugriff über den Router belegt.

Router, NAT, CL01-Konfiguration, Fehlerdiagnose, Korrektur und der IP-basierte Internettest sind sichtbar. Fachliche Grenzen bleiben:

• Eine separate Abbildung ping 192.168.10.1 nach Korrektur liegt nicht als eigene Prüfung vor. Der erfolgreiche ping 1.1.1.1 setzt jedoch funktionierende Gateway-Erreichbarkeit praktisch voraus.
• Ein externer DNS-Test ist in Cluster 1 nicht separat abgebildet; die interne DNS-Rolle wird erst in Cluster 3 aufgebaut.
• Die korrigierte LAN-Adresse steht in /etc/network/interfaces; ein Router-Neustart oder Networking-Reload wurde danach nicht geprüft.

Die Diagnosekette beginnt mit lokaler IP-Konfiguration, Route, Gateway-Erreichbarkeit und ARP. Erst danach werden Router-Forwarding, NAT und externe Namensauflösung geprüft.

Der zentrale Praxisfall behandelt den Fehler 192.169.10.1 statt 192.168.10.1 und die daraus resultierende ARP- und Gateway-Störung.

Router, IPv4-Forwarding, NAT und die statische CL01-Konfiguration arbeiten nach der Korrektur der LAN-Adresse zusammen; der Ping zu 1.1.1.1 ist erfolgreich. Für den abschließenden Gateway-Ping und den externen DNS-Test liegen keine separaten Abbildungen vor. Ein Router-Neustart oder Networking-Reload wurde nach der persistenten Korrektur nicht geprüft.

In Cluster 2 wurde das LF10-Homelab um einen Nested-Virtualisierungshost auf Basis von Proxmox erweitert. Auf diesem Proxmox-System wurde mit SRV1 der erste Debian-Server für spätere zentrale Dienste vorbereitet. Der Cluster schließt mit der administrativen Erreichbarkeit von SRV1 per SSH von CL01 ab. Für MAC-Spoofing, eine spätere Abfrage von ExposeVirtualizationExtensions und den sudo-Funktionstest liegen keine separaten Prüfungen vor.

Cluster 1 stellte die Netzgrundlage bereit: Firmennetz, Router, NAT, Gateway und CL01. Cluster 2 nutzt diese Grundlage und ergänzt die Serverbereitstellungsschicht. Proxmox übernimmt die Rolle eines verschachtelten Virtualisierungshosts im Hyper-V-basierten Lab. SRV1 ist der erste Server innerhalb dieser Proxmox-Schicht und wird in späteren Clustern für DHCP, DNS und SSH-Härtung weiterverwendet.

Die zentrale Architekturentscheidung lautet: Proxmox läuft als VM in Hyper-V, und SRV1 läuft wiederum als VM innerhalb von Proxmox. Damit entsteht bewusst eine verschachtelte Virtualisierungsumgebung, die im Kurskontext den Aufbau mehrerer Serverdienste mit begrenzten Ressourcen ermöglicht.

Die Arbeitsschritte in Cluster 2 umfassen:

1. Proxmox wurde als Hyper-V-VM für Nested Virtualization vorbereitet.
2. Proxmox ist im internen Netz unter 192.168.10.10 erreichbar.
3. Die Weboberfläche ist über https://192.168.10.10:8006 nutzbar.
4. SRV1 wurde als Debian-VM in Proxmox erstellt.
5. SRV1 wurde als Server ohne grafische Oberfläche installiert.
6. SRV1 ist mit 192.168.10.11/24 ins Firmennetz integriert.
7. sudo wurde für den Benutzer student vorbereitet.
8. Der Zugriff von CL01 auf SRV1 per SSH funktioniert.

Die Aufgaben basieren auf drei Kursunterlagen zu Virtualisierungshost, SRV1-Installation und SSH-Zugriff:

Die SSH-Kursunterlage trennt den Befehl optisch; verwendet wird die korrekte Form ssh student@192.168.10.11.

Proxmox als Nested-Hypervisor

Proxmox läuft als Hyper-V-VM und benötigt dafür Nested Virtualization. Die Hyper-V-Konfiguration umfasst vier vCPU, deaktiviertes Secure Boot und gesetzte ExposeVirtualizationExtensions.

MAC-Spoofing als fachliche Grenze

Die Aufgabenstellung fordert MAC-Spoofing; in den vorhandenen Abbildungen ist diese Hyper-V-Einstellung nicht eindeutig sichtbar und bleibt daher eine fachliche Grenze.

SRV1 als Server ohne GUI

SRV1 soll später zentrale Dienste bereitstellen. Dafür wurde Debian ohne Desktopumgebung, aber mit SSH-Server und Standard-Systemwerkzeugen ausgewählt.

Grenzen der Einzelprüfungen

Nicht separat geprüft wurden MAC-Spoofing, die Auslese von Nested Virtualization, der vollständige SRV1-Systemzustand und die sudo-Funktion.

Hyper-V-Grundkonfiguration für Proxmox

Proxmox wurde im Hyper-V-Manager als Generation-2-VM mit 4096 MB Arbeitsspeicher, VHDX, Proxmox-ISO und Anschluss an den Switch Firmennetz vorbereitet. Zusätzlich wurde Secure Boot deaktiviert und die CPU-Konfiguration auf vier virtuelle Prozessoren gesetzt.

Nested Virtualization

Die verschachtelte Virtualisierung wurde auf dem Hyper-V-Host per PowerShell vorbereitet:

Set-VMProcessor -VMName Proxmox -ExposeVirtualizationExtensions $true

Die Ansicht zeigt die Ausführung des Set-Befehls. Eine spätere Abfrage mit Get-VMProcessor liegt nicht separat vor.

Proxmox Management-Netz und Weboberfläche

Während der Proxmox-Installation wurde das Managementinterface mit 192.168.10.10/24, Gateway 192.168.10.1 und DNS 8.8.8.8 konfiguriert. Der Zugriff über den Browser erzeugte die erwartbare Zertifikatswarnung eines selbstsignierten Zertifikats. Danach war die Loginmaske erreichbar und die Weboberfläche nach Anmeldung sichtbar.

Debian-ISO und SRV1-VM in Proxmox

Die Debian-ISO wurde in Proxmox heruntergeladen und für die neue VM SRV1 verwendet. Die VM wurde als VM-ID 100 angelegt und mit den vorgegebenen Parametern vorbereitet.

SRV1-Systemkonfiguration

Für SRV1 wurden OVMF/UEFI, EFI-Disk und QEMU-Agent gesetzt. Die VM erhielt zwei CPU-Kerne, 2048 MiB RAM mit 1024 MiB Mindestwert, eine Netzwerkkarte und die Autostart-Option. Die Hardwareübersicht nach der Erstellung dient als konsolidierender Beleg.

Manuelle Netzwerkkonfiguration und Identität von SRV1

Im Debian-Installer wurde SRV1 mit der Adresse 192.168.10.11/24, Gateway 192.168.10.1, DNS 8.8.8.8, Hostname srv1 und Domain gfn.internal konfiguriert. Der externe DNS ist in diesem Cluster noch temporär; die interne DNS-Rolle folgt später in Cluster 3.

Serverinstallation ohne GUI und sudo-Vorbereitung

Die Softwareauswahl zeigt, dass keine Desktopumgebung, sondern die serverrelevanten Komponenten einschließlich SSH-Server und Standard-Systemwerkzeuge installiert wurden. Nach der Installation wurde sudo installiert und der Benutzer student zur sudo-Gruppe hinzugefügt.

SSH-Verbindung von CL01 zu SRV1

Die administrative Erreichbarkeit von SRV1 wird mit einer SSH-Verbindung von CL01 geprüft:

ssh student@192.168.10.11

Sichtbar sind die Hostkey-Abfrage, die Anmeldung als student und den Prompt student@srv1. Damit ist die administrative Erreichbarkeit von SRV1 aus dem Clientnetz belegt.

Nicht separat geprüft wurden MAC-Spoofing, die Auslese von Nested Virtualization, der vollständige SRV1-Systemzustand und die sudo-Funktion. Für Installation und SSH-Zugriff liegen dagegen direkte Funktionsprüfungen vor.

1. Nested Virtualization benötigt eine gesetzte und ausgelesene Hyper-V-Konfiguration.

Der Set-Befehl setzt den Wert; eine spätere Ausgabe von Get-VMProcessor liegt nicht vor.

1. MAC-Spoofing ist für Proxmox in Hyper-V erforderlich; eine sichtbare Ausleseprüfung fehlt.

Wenn Proxmox später eigene VMs betreibt, muss der Hyper-V-Adapter mehrere MAC-Adressen zulassen.

1. Die SSH-Verbindung von CL01 bestätigt die administrative Erreichbarkeit von SRV1.

Der erfolgreiche Login von CL01 auf SRV1 zeigt praktische Administrierbarkeit.

1. Temporärer externer DNS ist für Cluster 2 akzeptabel.

Der interne DNS wird erst im nächsten Cluster aufgebaut; bis dahin ist 8.8.8.8 ein Übergangswert.

1. Serverrolle ohne Desktopumgebung umsetzen.

Die Softwareauswahl ohne Desktopumgebung ist fachlich relevant, weil SRV1 als Serverrolle vorbereitet wird.

Nicht separat geprüft wurden:

• MAC-Spoofing als separate sichtbare Abbildung,
• ExposeVirtualizationExtensions=True per Ausleseprüfung,
• abschließender Linux-Systemcheck auf SRV1 nach dem ersten Login,
• ein eigenständiger Proxmox-Shell-Betriebscheck,
• interne DNS-Auflösung über gfn.internal; diese folgt erst in Cluster 3.

In Cluster 3 wurde SRV1 zum zentralen Basisdienstserver im LF10-Homelab ausgebaut. KEA stellt DHCP für CL01 bereit, BIND9 die interne Zone gfn.internal, und SSH wurde von Passwortlogin auf Public-Key-Authentifizierung mit Port 6464 und Client-Alias srv1 umgestellt. Fehlende sudo-Rechte auf CL01, die NetworkManager-Reihenfolgekorrektur und ein SSH-Test im falschen Kontext werden jeweils mit Ursache, Korrektur und Ergebnis beschrieben. Präventionsregeln ergänzen die Funktionsprüfungen für DHCP, DNS und SSH.

Cluster 1 stellte Router, Firmennetz und CL01 bereit. Cluster 2 stellte Proxmox und SRV1 bereit. Cluster 3 macht SRV1 nun zum zentralen Basisdienstserver:

SRV1
├── KEA DHCP für 192.168.10.0/24
├── BIND9 DNS für gfn.internal
└── SSH-Härtung und administrativer Komfort

CL01
├── bezieht IP/Gateway/DNS per DHCP
├── löst interne Namen über 192.168.10.11 auf
└── verbindet sich per ssh srv1 auf Port 6464

Für den stabilen Betrieb gelten fünf Präventionsregeln: Whitespace in der KEA-Konfiguration vermeiden, BIND-Zonen prüfen, CL01 nicht mit externem DNS testen, den SSH-Port in sshd_config setzen und SSH-Tests im richtigen Clientkontext ausführen.

DHCP mit KEA

SRV1 war mit 192.168.10.11/24 und Gateway 192.168.10.1 vorbereitet. KEA wurde auf ens18 konfiguriert. Der DHCP-Pool umfasst 192.168.10.100–192.168.10.200; als Router wird 192.168.10.1, als DNS 192.168.10.11 und als Domain gfn.internal verteilt.

Bei der Client-Umstellung traten zwei relevante Zwischenzustände auf: student auf CL01 hatte keine sudo-Rechte und ein erster NetworkManager-Befehl scheiterte wegen der Reihenfolge beim Entfernen statischer Werte. Beide Zustände wurden korrigiert; anschließend erhielt CL01 per DHCP die Adresse 192.168.10.100/24, Route proto dhcp, DNS 192.168.10.11 und erfolgreiche Konnektivität zu Router, SRV1 und 1.1.1.1.

DNS mit BIND9

BIND9 wurde installiert, named.conf bindet die interne Zonendatei ein, und named.conf.options enthält ACL, Forwarder, Query-/Transfer-Regeln, Rekursion, deaktivierte DNSSEC-Prüfung für das Lab sowie IPv6-Deaktivierung. Forward- und Reverse-Zonen wurden für gfn.internal und 10.168.192.in-addr.arpa angelegt.

Die Konfiguration wurde mit named-checkconf und named-checkzone geprüft. Der Dienst läuft, und direkte Abfragen gegen 192.168.10.11 sowie lokale Abfragen über 127.0.0.1 funktionieren.

Auf CL01 wird 192.168.10.11 als DNS-Server verwendet. Die internen Namen router.gfn.internal, proxmox.gfn.internal und srv1.gfn.internal lösen korrekt auf. Die Proxmox-Weboberfläche ist per FQDN erreichbar; die Zertifikatswarnung ist wegen des selbstsignierten Proxmox-Zertifikats erwartbar.

SSH Public-Key Authentication

Der SSH-Server auf SRV1 war vorhanden. PubkeyAuthentication wurde geprüft und aktiviert. Auf CL01 wurde ein RSA-4096-Schlüsselpaar erzeugt und der öffentliche Schlüssel mit ssh-copy-id auf SRV1 übertragen. Der Login per Key funktionierte, bevor die Passwortauthentifizierung deaktiviert wurde.

SSH-Portänderung auf 6464

Ausgangszustand war Port 22. In /etc/ssh/sshd_config wurde Port 6464 gesetzt, die Konfiguration wurde mit sshd -t geprüft, der Dienst neu gestartet, und sshd -T sowie ss bestätigten den neuen Listener. Ein Test wurde versehentlich von SRV1 gegen SRV1 ausgeführt und endete wegen fehlendem passendem Private Key mit Permission denied (publickey). Der korrekte Test von CL01 aus war erfolgreich. Der Test ohne Portangabe scheiterte erwartungsgemäß mit Connection refused auf Port 22.

SSH-Client-Config

Auf CL01 wurde ~/.ssh/config mit Host-Alias srv1 angelegt. Die Datei hat Rechte 600, enthält HostName 192.168.10.11, User student, IdentityFile ~/.ssh/id_rsa, Port 6464 und IdentitiesOnly yes. Der Alias ssh srv1 verbindet erfolgreich zu SRV1.

CL01 erhält seine Adresse und DNS-Parameter per KEA, interne Namen werden über BIND9 aufgelöst, und der SSH-Zugang zu SRV1 funktioniert mit Schlüsselanmeldung, Port 6464 und Client-Alias. Die beschriebenen Zwischenzustände halten Ursache, Korrektur und Ergebnis auseinander.

Die Fehleranalyse umfasst:

• KEA-Testbefehl mit unerwarteter Ausgabe: nicht als Blocker gewertet, weil Dienststatus, Logs und CL01-Lease die Funktion belegen.
• CL01 ohne sudo und nmcli-Reihenfolgefehler: Korrektur über root-Kontext und kontrolliertes Entfernen statischer Werte.
• Resolverlogik SRV1/CL01: SRV1 nutzt 127.0.0.1, CL01 nutzt 192.168.10.11.
• SSH-Port-Test im falschen Kontext: SRV1→SRV1 prüft nicht den Clientweg; CL01→SRV1 funktioniert auf Port 6464.

Entscheidend sind: Dienstfunktion immer Ende-zu-Ende prüfen, bekannte Fehlermuster präventiv berücksichtigen, Konfigurationsdateien nicht blind aus Kursunterlagen übernehmen und SSH-Härtung nur mit offenem Rückweg durchführen.

Die SSH-Portänderung auf 6464 reduziert vor allem Standard-Port-Scan-Rauschen und ersetzt keine echte Härtung wie Updates, starke Authentifizierung, restriktive Zugriffskontrolle oder Monitoring.

SSH-Tunneling, ProxyJump/Jump Hosts, SCP/SFTP/rsync und Endlessh/Honeypot-Konzepte wurden fachlich betrachtet, aber nicht praktisch umgesetzt. Sie gehören daher nicht zum belegten Cluster-3-Umfang.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Umsetzung und Prüfung gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

In Cluster 4 wurde das LF10-Homelab um einen dedizierten Storage-Baustein erweitert. Eine TrueNAS-VM wurde in Hyper-V erstellt, mit drei Datenfestplatten ausgestattet, trotz RemoteLab-RAM-Limit erfolgreich installiert und statisch unter 192.168.10.12 in das Firmennetz integriert. Aus den Datenplatten wurde ein ZFS-Pool erstellt, darauf ein iSCSI-Target bereitgestellt und dieses Target anschließend in Proxmox als iscsi-storage sichtbar angebunden. Der zunächst sichtbare Proxmox-ID-Tippfehler isci-storage wurde real korrigiert und durch neue Belege ersetzt.

Cluster 4 folgt auf Router/Client, Proxmox/SRV1 und DHCP/DNS/SSH. Der Cluster erweitert das Lab von Serverdiensten zu zentralem Netzwerk-Storage.

Hyper-V RemoteLab
├── Storage / TrueNAS
│   ├── Storage.vhdx als Systemdisk
│   ├── Pool01.vhdx / Pool02.vhdx / Pool03.vhdx
│   ├── ZFS-Pool Pool1
│   └── iSCSI Target target01
└── Proxmox
    └── iscsi-storage über Portal 192.168.10.12

Bei TrueNAS und iSCSI werden IP-Persistenz, Target-Sichtbarkeit, Dienstzustand, Portal- und Initiatorzugriff sowie stabile Gerätenamen getrennt geprüft.

Ziel

Eine eigenständige TrueNAS-VM wird als Storage-System im internen Firmennetz bereitgestellt.

Rolle von System- und Datenplatten

TrueNAS übernimmt die Rolle des dedizierten Storage-Servers. Die drei zusätzlichen VHDX-Dateien sind Rohdatenträger für den späteren ZFS-Pool, nicht Systemplatten.

TrueNAS-VM und Hyper-V-Unterbau

Ziel

TrueNAS soll trotz knapper RemoteLab-Ressourcen installiert und von der Systemdisk gestartet werden.

Lab-Ressourcen und Prüfkette

Für die Laborinstallation wurde die Storage-VM auf 1024 MB reduziert; TrueNAS empfiehlt mindestens 8 GB RAM. RAM-Warnung, Swap-Auswahl, UEFI-Auswahl und korrigierte Bootreihenfolge bilden die technische Prüfkette.

Ressourcenproblem, Installation und Bootkorrektur

Ziel

TrueNAS soll unter fester IP und DNS-Name erreichbar sein.

Stabile Adressierung und DNS-Prüfung

Storage-Dienste brauchen stabile Adressierung. Test Changes, Save Changes, DNS-Zone und FQDN-Browserzugriff werden getrennt bewertet.

Netzwerkintegration und DNS

Ziel

Drei Datenplatten werden zu einem ZFS-Pool zusammengefasst.

ZFS-Aufbau und Kapazität

Der Pool bildet die Grundlage für das iSCSI-Device. RAID-Z liefert bei drei 1-TB-Datenträgern plausibel rund 2 TB Nutzkapazität.

Speicherpool

Ziel

TrueNAS stellt Blockspeicher als iSCSI Target bereit.

Erforderliche iSCSI-Komponenten

Entscheidend sind Target, Device/Extent, Portal, Zugriffskontext und aktiver iSCSI-Dienst mit Autostart.

iSCSI Target und Dienst

Ziel

Proxmox bindet das TrueNAS-iSCSI-Target als Storage ein.

Korrigierte Storage-ID

Der anfängliche Storage-ID-Tippfehler isci-storage wurde real korrigiert. abschließend geprüft ist die korrekte ID iscsi-storage.

Proxmox-iSCSI-Anbindung

Für Cluster 4 sind folgende Zustände belegt: TrueNAS wurde bereitgestellt, statisch adressiert, per DNS eingebunden, mit einem Pool versehen, als iSCSI-Target konfiguriert und in Proxmox sichtbar mit korrekter ID iscsi-storage angebunden.

Die relevanten Praxisfälle betreffen das RAM-Limit, einen erneuten Installer-Boot, die TrueNAS-IP-Persistenz, Risiken bei der iSCSI-Erkennung und die Korrektur der Proxmox-Storage-ID.

In Cluster 5 wurde das Homelab um den Debian-Server SRV2 und eine automatisierte Backup-Strecke erweitert. SRV2 wurde in Proxmox bereitgestellt, statisch ins interne Netz integriert, per DNS erreichbar gemacht und über SSH mit Schlüsselanmeldung administriert. Auf TrueNAS entstand das separate iSCSI-Target target02; SRV2 bindet es ein, partitioniert und formatiert es und nutzt es zeitlich begrenzt als Backup-Ziel. Der manuelle rsync-Lauf war erfolgreich, der tägliche Cronjob wurde eingerichtet. NXDOMAIN, die doppelte SRV2-IP durch dhcpcd, das zunächst unsichtbare target02 und der kurzzeitige SSH-Ausfall werden mit Ursache, Korrektur und Ergebnis beschrieben.

Cluster 5 baut auf dem Netzwerk, DNS, SSH und TrueNAS-/iSCSI-Fundament aus den vorherigen Clustern auf. Während Cluster 4 den Storage technisch bereitgestellt hat, verwendet Cluster 5 diesen Storage für einen Backup-Anwendungsfall. Der Cluster verbindet damit Infrastrukturaufbau, Namensauflösung, Zugriffshärtung, iSCSI-Blockstorage und Automatisierung.

Für die Backup-Strecke sind iSCSI-Target-Sichtbarkeit, passende Authorized Networks, stabile by-path-Gerätenamen und ein eigener Wiederherstellungstest entscheidend. Die Wiederherstellung wurde in diesem Aufbau nicht geprüft.

Ziel war nicht nur die Installation von SRV2, sondern der Aufbau einer nachvollziehbaren Backup-Strecke: target02 soll nur während des Backups eingebunden werden, Daten aufnehmen und anschließend wieder sauber getrennt werden. Zusätzlich sollte die Automatisierung über Cron vorbereitet werden.

Ziel

SRV2 sollte als neue Debian-13-VM in Proxmox angelegt werden.

Rolle und Systemdisk von SRV2

SRV2 bildet den Backup-Client beziehungsweise iSCSI-Initiator. Die Systemdisk gehört laut Aufgabenstellung auf local-lvm; das iSCSI-Storage aus Cluster 4 darf nicht als Systemdisk verwendet werden. Im Erstellungsdialog ist die Proxmox-Firewall-Option an der VM-NIC sichtbar aktiviert. Ein separater aktueller Beleg für eine spätere Deaktivierung liegt in diesem Paket nicht vor; deshalb wird keine deaktivierte Firewall als belegter Zielzustand behauptet. Die tatsächliche Erreichbarkeit für DNS, SSH und iSCSI wird stattdessen über Funktionsnachweise belegt.

Umsetzung und Ergebnis

Die VM wurde mit OVMF/UEFI, EFI-Disk, QEMU-Agent, 2 CPU-Kernen, 2048 MiB RAM mit Ballooning-Minimum 1024 MiB, 50 GB Disk auf local-lvm und Bridge vmbr0 erstellt. Ein Zwischenstand mit falscher Disk-Auswahl auf iscsi-storage wurde korrigiert und nicht als geprüfter Zustand verwendet.

Ziel

Debian 13 sollte auf SRV2 installiert und für administrative Arbeiten vorbereitet werden.

Administrationsgrundlage

SSH-Server und Standard-Systemwerkzeuge sind die Grundlage für die spätere Administration. sudo wurde nachinstalliert, damit der Benutzer student erhöhte Rechte verwenden kann.

Umsetzung und Ergebnis

Die Installation wurde abgeschlossen, SRV2 startete ins installierte System und die Postinstallationsschritte wurden durchgeführt.

Ziel

SRV2 sollte statisch unter 192.168.10.13/24 erreichbar sein, per srv2.gfn.internal aufgelöst werden und per SSH administrierbar sein.

DNS-Diagnose und SSH-Voraussetzung

DNS und SSH sind Voraussetzung für die spätere Backup-Automation, weil die weitere Arbeit remote und dienstbasiert erfolgt. Der initiale NXDOMAIN-Fehler war kein Netzwerkfehler: CL01 fragte den richtigen DNS-Server, aber die Zone kannte srv2 noch nicht aktiv.

Umsetzung und Ergebnis

Die BIND-Zone wurde um srv2 IN A 192.168.10.13 ergänzt, die Serial erhöht, die Zone geprüft und named neu geladen. Danach funktionierten dig, Ping und SSH. Der vorhandene SSH-Key von CL01 wurde auf SRV2 übertragen und ein Client-Alias srv2 eingerichtet.

Ziel

Auf TrueNAS sollte ein separates Backup-Target target02 mit 200 GiB für SRV2 bereitgestellt werden.

Trennung der iSCSI-Targets

target02 ist strikt von target01 zu trennen. target01 wurde zuvor für Proxmox verwendet; target02 dient ausschließlich dem Backup-Szenario von SRV2. Durch Authorized Network 192.168.10.13/32 wurde der Zugriff bewusst auf SRV2 eingeschränkt.

Umsetzung und Ergebnis

Das Target wurde im TrueNAS-iSCSI-Wizard im Pool Pool1 angelegt, über das bestehende Portal 0.0.0.0:3260 bereitgestellt und auf SRV2 autorisiert.

Ziel

SRV2 sollte das neue target02 per iSCSI-Discovery finden.

Bedeutung der Target-Sichtbarkeit

Die Target-Sichtbarkeit ist der erste echte Funktionsnachweis. Dass zunächst nur target01 sichtbar war, zeigte: Netzwerk und Portal funktionierten, aber die SRV2-spezifische Freigabe für target02 griff noch nicht.

Umsetzung und Ergebnis

Die Diagnose ergab eine doppelte IP-Konfiguration auf SRV2: neben 192.168.10.13 war noch eine DHCP-Adresse 192.168.10.103 aktiv. Ursache war ein laufender dhcpcd-Prozess. Nach Bereinigung der DHCP-Adresse und Wiederherstellung der statischen Netzkonfiguration zeigte die Discovery sowohl target01 als auch target02.

Ziel

Das iSCSI-Target sollte als Blockdevice auf SRV2 nutzbar gemacht werden.

Blockdevice, Dateisystem und stabiler Gerätepfad

Ein iSCSI-Target erscheint unter Linux als Blockdevice. Erst Partitionierung, Dateisystem und Mount machen es als Datei-Backupziel verwendbar. /dev/sdb war hier nur der aktuelle Laufzeitname; für das Skript wurde ein stabilerer by-path-Pfad verwendet.

Umsetzung und Ergebnis

Nach dem Login zu target02 erschien sdb mit 200G. Mit fdisk wurde sdb1 erstellt, mit ext4 formatiert, nach /mnt/backup gemountet und anschließend wieder sauber ausgehängt und ausgeloggt.

Ziel

Das Backup sollte automatisierbar werden: iSCSI-Login, Mount, rsync, Unmount und Logout sollten in einem Skript zusammengeführt werden.

Zeitlich begrenzte iSCSI-Einbindung

Das Target soll nicht dauerhaft eingebunden bleiben. Das reduziert die dauerhafte Angriffs-/Fehlerfläche und entspricht der technischen Vorgabe, Backup-Storage nur während des Backups zu verbinden. Das fehlende /var/www wurde als erwartbare Warnung behandelt, während /etc gesichert wurde.

Umsetzung und Ergebnis

Das Skript /usr/local/bin/backup.sh verwendet den stabilen by-path-Pfad, ist ausführbar und endet im manuellen Test mit [OK] Backup completed. Bei einem rsync-Teilfehler kann set -euo pipefail ohne trap verhindern, dass umount und iSCSI-Logout ausgeführt werden.

Ziel

Das Backup sollte täglich um 01:00 Uhr per Cron geplant werden und die vorhandenen Backupdaten sollten kontrolliert werden.

Cron-Ausführung und Wiederherstellung nicht geprüft

crontab -l zeigt den gespeicherten Zeitplan, aber keinen ausgeführten Lauf um 01:00 Uhr. Ein Wiederherstellungstest wurde nicht durchgeführt.

Umsetzung und Ergebnis

Nach erneuter Einbindung des Targets wurde das Backup-Verzeichnis 2026-06-14 mit dem gesicherten etc-Ordner geprüft. Danach wurde der Cronjob eingetragen: 0 1 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1.

SRV2 ist im DNS eingetragen, über den SSH-Alias erreichbar und bindet das getrennte TrueNAS-Target target02 zeitlich begrenzt als Backup-Ziel ein. Der manuelle rsync-Lauf und die Kontrolle der Backupdaten funktionieren; der tägliche Cronjob ist eingetragen. Eine Ausführung um 01:00 Uhr wurde nicht beobachtet, und die Wiederherstellung wurde nicht geprüft.

• Es wurde kein Restore-Test durchgeführt.
• Der Cronjob ist konfiguriert, aber ein späterer automatischer Lauf ist nicht gesondert belegt.
• Für SRV2 liegt keine abschließende sshd -T-Ausgabe mit PasswordAuthentication no vor.
• Das Backup-Skript wurde erfolgreich getestet. Ohne trap-Cleanup können umount und iSCSI-Logout bei einem rsync-Teilfehler ausbleiben.
• /dev/sdb ist nur der aktuelle Laufzeitname; die robuste Referenz ist der by-path-Pfad.
• Für das Backup bleiben ein Wiederherstellungstest und die Prüfung stabiler Gerätepfade erforderlich.

SRV2 betreibt Apache2 mit namensbasierten VirtualHosts sowie Nextcloud mit PHP 8.4 und MariaDB. Nextcloud ist über HTTPS mit einem selbstsignierten Zertifikat erreichbar; HTTP wird zusätzlich auf HTTPS umgeleitet. Die Fehleranalyse behandelt fehlende vHost-Dateien, falschen DNS-Kontext, NXDOMAIN, getrennte PHP-Konfigurationen, doppelt geladenes OPcache, ein Platzhalterpasswort, Dateirechte und die erwartete Zertifikatswarnung.

CL01 Browser / Terminal
   │
   ├── DNS-Anfragen → SRV1 / BIND9 → gfn.internal-Zone
   │
   └── HTTP/HTTPS → SRV2 / Apache2
          ├── lf10b.gfn.internal      → /var/www/lf10b
          ├── website1.gfn.internal   → /var/www/website1
          ├── website2.gfn.internal   → /var/www/website2
          └── nextcloud.gfn.internal  → /var/www/nextcloud + PHP + MariaDB

SRV2 übernimmt aus Cluster 5 die statische Adresse 192.168.10.13, DNS-Integration und SSH-Erreichbarkeit. Darauf bauen Apache, die VirtualHosts, Nextcloud und TLS auf.

Ziel

Die Apache-Prüfung verbindet aktiven Dienst, Port-80-Listener und Browsererreichbarkeit; erst diese drei Zustände zeigen den nutzbaren Webserver.

Umsetzung und Prüfung

• Apache2 läuft auf SRV2 und ist als Dienst aktiv.
• Apache ist über HTTP-Port 80 netzwerkseitig erreichbar.
• CL01 erreicht Apache auf SRV2 im Browser.

Ergebnis und Einordnung

Der erreichte Zustand zeigt, dass SRV2 als HTTP-Webserver funktionsfähig ist. Damit war die Basis für die folgenden namensbasierten vHosts gegeben.

Apache-Basis

Ziel

Der erste eigene vHost trennt erstmals Apache-Standardseite und kursbezogene Dummyseite. Entscheidend ist das Zusammenspiel aus DocumentRoot, vHost-Datei, Aktivierung in Apache und DNS-Eintrag auf SRV1.

Umsetzung und Prüfung

• DocumentRoot-Inhalt für lf10b ist gespeichert.
• Fehlerbild: vHost-Datei fehlte zunächst in sites-available.
• Bestätigt Ursache des a2ensite-Fehlers.
• Korrigierte vHost-Datei mit ServerName und DocumentRoot existiert.
• lf10b-vHost wurde aktiviert und Apache neu geladen.
• Fehlerbild: DNS-Datei wurde zunächst auf SRV2 statt SRV1 bearbeitet.
• DNS-Record für lf10b wurde gesetzt.
• SRV1 löst lf10b.gfn.internal korrekt auf SRV2 auf.
• Clientseitiger Zugriffspfad für lf10b funktioniert.
• lf10b.gfn.internal liefert die richtige Seite im Browser.

Ergebnis und Einordnung

Nach dem fehlenden-Datei-Fehler wird der vHost auf SRV2 korrekt angelegt und aktiviert; SRV1 liefert anschließend den passenden DNS-Eintrag.

vHost lf10b.gfn.internal

Ziel

Die Vertiefung zeigt hostbasiertes Virtual Hosting: gleiche IP, gleicher Port, aber verschiedene Hostnamen und DocumentRoots. Der End-to-End-Beleg sind getrennte Browseransichten für beide Websites.

Umsetzung und Prüfung

• website2-vHost ist konfiguriert.
• website1 fehlte zunächst; website2 war bereits aktiv.
• Ursache für a2ensite-Fehler website1 wurde bestätigt.
• website1-vHost wurde nachträglich korrekt angelegt und aktiviert.
• Zwischenzustand vor vollständiger DNS-Ergänzung.
• DNS-Problem bei website2 eindeutig belegt.
• website2-DNS wurde korrigiert.
• website1.gfn.internal liefert den korrekten Inhalt.
• Clientseitiges Symptom des fehlenden DNS-Records.
• DNS-Einträge für beide Zusatz-vHosts sind gesetzt.
• SRV1 löst beide Zusatz-vHosts korrekt auf.
• website2.gfn.internal liefert den korrekten Inhalt.

Ergebnis und Einordnung

Website1 und website2 sind nach den DNS- und vHost-Korrekturen auf SRV2 erreichbar. Die Zwischenzustände zeigen jeweils den fehlenden vHost beziehungsweise DNS-Eintrag.

vHosts website1 und website2

Ziel

Nextcloud benötigt PHP 8.x, passende Module und Apache-spezifische PHP-Werte. PHP-CLI und Apache-PHP verwenden getrennte Konfigurationskontexte und werden daher getrennt geprüft.

Umsetzung und Prüfung

• PHP-Basis für Nextcloud ist installiert.
• Die Unterlagen-php.ini wurde auf SRV2 übertragen.
• Apache-PHP-Konfigurationsdatei wurde ersetzt und save_comments aktiviert.
• Apache läuft nach PHP-Konfigurationsänderung.
• Unterschied zwischen Dateiinhalt und CLI-Konfiguration wurde erkannt.
• Apache-php.ini enthält die Nextcloud-relevanten Werte; derselbe Beleg zeigt zusätzlich die CLI-/Apache-Abgrenzung.
• php --ini zeigt die geladene CLI-Konfiguration und wird nicht als abschließende Prüfung verwendet.
• OPcache wurde zunächst doppelt geladen.
• Doppelte OPcache-Ladezeile wurde bereinigt.

Ergebnis und Einordnung

Die Apache-PHP-Konfiguration wurde mit der Kursdatei übernommen und um die doppelte OPcache-Ladezeile bereinigt. Die Prüfung zeigt danach die für Nextcloud gesetzten Apache-PHP-Werte.

PHP-Konfiguration für Nextcloud

Ziel

MariaDB stellt die Datenbank für Nextcloud bereit. Entscheidend sind nicht nur Datenbank und Benutzer, sondern ein tatsächlicher Login-/Zugriffsbeleg mit dem Nextcloud-Benutzer.

Umsetzung und Prüfung

• MariaDB läuft als Datenbankdienst.
• Platzhalterpasswort wurde versehentlich gesetzt.
• Nextclouduser besitzt Rechte auf nextcloud_db nach Korrektur.
• Nextcloud-DB-Benutzer kann sich anmelden und Datenbank sehen.

Ergebnis und Einordnung

Nach Korrektur des Platzhalterpassworts besitzt nextclouduser Zugriff auf nextcloud_db. Dabei werden keine Passwort-, Hash- oder Administrationsfelder gezeigt; MariaDB-Dienstzustand, Benutzerlogin und Sichtbarkeit der Datenbank bilden die technische Prüfkette.

MariaDB und Nextcloud-Datenbank

Ziel

Die Nextcloud-Dateien müssen nicht nur vorhanden sein, sondern im Apache-Kontext nutzbar sein. Falsche Besitzrechte können später zu schwer interpretierbaren Webfehlern führen.

Umsetzung und Prüfung

• Es existierte bereits ein Nextcloud-Verzeichnis.
• Dateirechte waren zunächst nicht passend für Apache/Nextcloud.
• Nextcloud-Dateien gehören www-data.

Ergebnis und Einordnung

Der anfängliche root:root-Zustand wurde erkannt und auf www-data:www-data korrigiert.

Nextcloud-Dateien und Rechte

Ziel

Der Nextcloud-vHost verbindet Apache, PHP-Anwendung und DNS. Browser-Dashboard und occ status mit installed: true prüfen den Installationszustand aus zwei Perspektiven.

Umsetzung und Prüfung

• Nextcloud-vHost ist konfiguriert.
• Apache läuft nach Nextcloud-vHost-Aktivierung.
• DNS-Alias nextcloud wurde in BIND eingetragen.
• SRV1 löst nextcloud.gfn.internal korrekt auf.
• Client kann nextcloud.gfn.internal intern auflösen.
• Nextcloud-Webinstaller ist über nextcloud.gfn.internal erreichbar.
• App-Store-Empfehlungen wurden nicht geladen.
• Nextcloud ist im Browser nach Installation nutzbar.
• www-data ist kein normaler Login-Benutzer; occ muss per sudo/root ausgeführt werden.
• SRV2 erreicht apps.nextcloud.com grundsätzlich.
• OpenSSL-Vorbereitung; nicht als App-Store- oder occ-Beleg verwenden.
• Nextcloud ist serverseitig installiert; Apache läuft, die Konfiguration ist gültig und Port 443 lauscht.

Ergebnis und Einordnung

Nextcloud wurde installiert und ist im Browser nutzbar. Die empfohlenen Apps ließen sich in diesem Zustand nicht abrufen; occ status bestätigt installed: true. Das Installationsformular wird ohne Admin- und Datenbankfelder ausgeliefert.

Nextcloud-vHost, DNS und Installation

Ziel

HTTPS verwendet im Labor ein selbstsigniertes Zertifikat; die Firefox-Warnung ist daher erwartbar. Die zusätzliche HTTP→HTTPS-Weiterleitung reduziert versehentliche HTTP-Aufrufe.

Umsetzung und Prüfung

• OpenSSL war installiert bzw. wurde als aktuell bestätigt.
• SSL-Modul wurde aktiviert und das selbstsignierte Zertifikat wurde erzeugt.
• vHost-Konfiguration enthält HTTPS-Block.
• Self-Signed-Zertifikatswarnung erscheint wie erwartet.
• HTTP wird auf HTTPS umgeleitet und HTTPS antwortet erfolgreich.
• Apache-Konfiguration ist gültig und Port 443 lauscht.
• Nextcloud-Dashboard ist über HTTPS sichtbar erreichbar.

Ergebnis und Einordnung

Nextcloud ist über HTTPS erreichbar, Apache lauscht auf 443 und HTTP-Anfragen werden auf HTTPS umgeleitet. Das Zertifikat ist bewusst nicht öffentlich vertrauenswürdig.

HTTPS, Self-Signed und Redirect

Der unter Nextcloud-vHost, DNS und Installation gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Die relevanten Fehlerbilder zeigen insbesondere die Unterscheidung von Systemrollen, die Bedeutung der DNS-Prüfung, die Trennung von PHP-CLI und Apache-PHP sowie die Grenzen selbstsignierter Zertifikate.

Datenbank- und Installationsschritte werden ohne Passwort-, Hash- oder Administrationsfelder dargestellt. MariaDB-Dienstzustand, Datenbanklogin und Sichtbarkeit von nextcloud_db sowie DNS, vHost, Nextcloud-Dashboard und occ status zeigen die technische Funktion.

• Über den beschriebenen HTTPS-vHost hinaus wurden keine zusätzlichen Härtungsmaßnahmen umgesetzt.
• Kein öffentlich vertrauenswürdiges TLS-Zertifikat wurde eingerichtet; das Zertifikat ist selbstsigniert.
• Nextcloud-Backup und Wiederherstellung wurden in diesem Cluster nicht geprüft.
• Empfohlene Nextcloud-Apps wurden nicht sicher als installiert belegt; der App-Store-Abruf zeigte eine Abweichung.
• HSTS und mod_rewrite wurden nur als alternative Methoden recherchiert, nicht umgesetzt.

Aktiviertes IP-Forwarding und gesetzte DNAT-Regeln zeigen zunächst die Routerkonfiguration. Der tatsächliche Zugriff über den Laborweg wird durch die anschließenden Namensauflösungs- und Browserprüfungen am Windows-Testclient bestätigt.

Cluster 7 erweitert SRV2 um Docker Engine, Chrony/NTP, Compose, Portainer und Heimdall. Apache stellt Portainer intern über HTTP und HTTPS bereit; Router-DNAT und die korrigierte Windows-hosts-Datei ergänzen den Zugriff vom Windows-Testclient. Die Fehleranalyse behandelt den KEA-Testaufruf, fehlende sudo-Rechte auf CL01, den Port-/Protokollkontext von Heimdall und einen veralteten hosts-Eintrag.

RemoteLab / externer Client
  -> hosts: portainer.gfn.internal = 10.100.20.38
  -> Router eth0/WAN 10.100.20.38
  -> DNAT 80/443
  -> SRV2 192.168.10.13
     -> Apache Reverse Proxy
        -> Portainer localhost:9000
     -> Docker Engine
        -> chrony, portainer, heimdall

CL01 im Firmennetz
  -> DNS SRV1 192.168.10.11
  -> KEA-DHCP verteilt ntp-servers=192.168.10.13

Ziel: Docker Engine und Docker Compose Plugin als Grundlage für containerisierte Dienste auf SRV2 bereitstellen.

Rolle der Containerlaufzeit: Docker ist die Laufzeitbasis für Chrony/NTP, Portainer und Heimdall. Da die Kursumgebung Debian Trixie nutzt, wurde das offizielle Docker-Repository eingebunden statt nur Pakete aus dem Standard-Repository zu verwenden.

Vorgehen: Repository und GPG-Key wurden eingerichtet, die Docker-Pakete installiert, der Docker-Dienst geprüft, die Engine mit hello-world geprüft und student in die Gruppe docker aufgenommen. Eine neue SSH-Sitzung bestätigte die wirksame Gruppenmitgliedschaft; anschließend funktionierte Docker ohne sudo.

Ergebnis: Docker Engine läuft auf SRV2; hello-world, Dienstzustand und eine neue Sitzung des Benutzers student prüfen Installation, Laufzeit und Gruppenberechtigung getrennt.

Docker-Grundinstallation auf SRV2

Ziel: Einen NTP-Dienst als ersten praktischen Containerdienst bereitstellen.

Prüfanforderung für UDP und NTP: Chrony/NTP ist ein netzwerkrelevanter Infrastrukturserver. Der Dienst nutzt UDP-Port 123, daher reicht ein reiner Containerstatus nicht aus; Host-Port und Client-Abfrage müssen geprüft werden.

Vorgehen: Der Container cturra/ntp wurde manuell mit docker run gestartet, Port 123/udp veröffentlicht, mit docker ps und ss geprüft und von CL01 mit ntpdate -q 192.168.10.13 abgefragt.

Ergebnis / Interpretation: Der NTP-Dienst war im LAN erreichbar. Der spätere Compose-Betrieb baut auf diesem funktionierenden Diensttest auf.

Chrony/NTP per Docker

Ziel: Die IP-Adresse des NTP-Servers automatisch per DHCP an Clients verteilen.

KEA statt ISC-DHCP: Die Aufgabenstellung nennt allgemein DHCP-Optionen. Die aktuelle Homelab-Umgebung nutzt jedoch KEA, weshalb die NTP-Option in /etc/kea/kea-dhcp4.conf und nicht in einer ISC-dhcpd.conf umgesetzt wurde.

Vorgehen: Die Option ntp-servers mit 192.168.10.13 wurde im KEA-Subnetz ergänzt. Der klassische Testaufruf zeigte versionsabhängige bzw. umgebungsspezifische Probleme; daher wurden JSON-Syntax, systemd-ExecStart, Dienststart und die tatsächlich empfangene NetworkManager-Lease auf CL01 als direkte Funktionsprüfung genutzt.

Ergebnis / Interpretation: CL01 erhielt dhcp4.ntp_servers=192.168.10.13. Damit ist die DHCP-Verteilung der Zeitserveradresse belegt.

NTP-Verteilung über KEA-DHCP

Ziel: Den manuell gestarteten NTP-Container in einen reproduzierbaren Compose-Stack überführen.

Nutzen der Compose-Definition: Compose macht Containerdefinitionen nachvollziehbarer und wartbarer. Da YAML einrückungssensitiv ist, wurde docker compose config als zusätzlicher Kontrollschritt verwendet.

Vorgehen: Der alte ntp-Container wurde gestoppt und entfernt. Anschließend wurde /home/student/docker/chrony/docker-compose.yml erstellt, mit docker compose config geprüft, gestartet und über Containerstatus, Health-Status, UDP-Port 123 und ntpdate geprüft.

Ergebnis / Interpretation: Der Dienst läuft als Compose-Service chrony und bleibt für CL01 erreichbar.

Chrony/NTP per Docker Compose

Ziel: Portainer als Weboberfläche zur Docker-Verwaltung bereitstellen.

Rolle von Portainer: Portainer macht Docker-Stacks, Container, Images und lokale Docker-Umgebungen sichtbar und bedienbar. Es dient im Cluster als administrativer Zugriffspunkt auf den Docker-Host SRV2.

Vorgehen: Ein Compose-Stack unter /home/student/docker/portainer wurde erstellt, die Konfiguration gerendert, der Stack gestartet, Ports 9000/9443 geprüft und die lokale Docker-Umgebung in Portainer geöffnet.

Ergebnis / Interpretation: Portainer verwaltet die lokale Docker-Umgebung auf SRV2. Die Portainer-Ansichten zeigen die lokale Docker-Umgebung ohne Passwortfelder.

Portainer per Docker Compose

Ziel: Ein zusätzliches Containerprojekt über Portainer bereitstellen und praktisch nutzen.

Rolle von Heimdall: Als zusätzlicher Containerdienst wurde ein kleines Homelab-Dashboard mit Heimdall umgesetzt.

Vorgehen: Heimdall wurde als Portainer-Stack mit Ports 8081/8444 bereitgestellt. Ein erster Zugriff auf 8444 zeigte einen Verbindungs-/Protokollkontext, anschließend wurde HTTP 8081 und HTTPS 8444 geprüft. Das Dashboard wurde mit Links zu Portainer, Nextcloud, Proxmox und TrueNAS eingerichtet.

Ergebnis: Heimdall läuft als zusätzlicher Containerdienst und stellt die Homelab-Links über die geprüften Ports bereit; der erste fehlgeschlagene Zugriff gehört zur Port- und Protokolldiagnose.

Zusätzlicher Containerdienst: Heimdall

Ziel: Portainer über den internen FQDN portainer.gfn.internal statt über IP und Port erreichbar machen.

Interner Proxyweg: Apache agiert auf SRV2 als Reverse Proxy. Die Anfrage erreicht Apache auf Port 80 und wird intern an Portainer auf localhost:9000 weitergeleitet. Port 9000 ist bewusst gewählt, weil Portainer dort HTTP bereitstellt.

Vorgehen: Auf SRV1 wurde portainer IN A 192.168.10.13 gesetzt und per named-checkzone/dig geprüft. Auf SRV2 wurden proxy/proxy_http aktiviert, ein vHost mit ProxyPass auf http://localhost:9000/ angelegt, Apache geprüft, aktiviert und neugestartet.

Ergebnis / Interpretation: Portainer ist intern unter http://portainer.gfn.internal erreichbar.

Interner Reverse Proxy für Portainer per HTTP

Ziel: Portainer verschlüsselt über https://portainer.gfn.internal bereitstellen.

TLS-Terminierung: Apache terminiert TLS mit einem selbstsignierten Zertifikat und proxyt intern weiterhin auf Portainer HTTP-Port 9000. Dadurch wird der SSL-Handshake mit Portainer-Port 9443 vermieden.

Vorgehen: Ein Zertifikat und Key für portainer.gfn.internal wurden erstellt, Rechte gesetzt, ssl/proxy-Module aktiviert, ein 443-vHost mit SSLCertificateFile/KeyFile und ProxyPass auf localhost:9000 erstellt, Apache mit configtest geprüft und Browser-/curl-Tests durchgeführt.

Ergebnis / Interpretation: Der HTTPS-Reverse-Proxy antwortet mit HTTP/1.1 200 OK. Browserwarnungen sind erwartbar, weil das Zertifikat selbstsigniert ist.

HTTPS-Reverse-Proxy für Portainer

Ziel: Portainer vom RemoteLab aus über portainer.gfn.internal erreichbar machen.

Externer Zugriffspfad: Im externen Kontext kann der interne DNS nicht genutzt werden. Der Router leitet externe Anfragen auf 10.100.20.38:80/443 per DNAT an SRV2 weiter; die Windows-hosts-Datei sorgt für Namensauflösung.

Vorgehen: Die Router-WAN-IP 10.100.20.38 wurde ermittelt, IP-Forwarding geprüft und DNAT-Regeln für Port 80/443 auf SRV2 gesetzt. Auf dem RemoteLab wurde ein alter falscher hosts-Eintrag auf 10.100.20.60 erkannt und durch 10.100.20.38 ersetzt; danach funktionierten HTTP und HTTPS im Browser.

Ergebnis / Interpretation: Portainer ist über den externen Weg erreichbar. Die iptables-Regeln sind nicht persistent konfiguriert; ihre Funktion nach einem Router-Neustart wurde nicht geprüft.

Externe Anbindung über Router-Portforwarding

CL01: student nicht in sudoers

KEA-Testsyntax und Unable-to-open-file

Docker Compose YAML

Heimdall-Port/Protokoll-Kontext

Portainer Reverse Proxy: 9000 vs. 9443

Self-Signed-Zertifikatswarnungen

Router-Minimalsystem ohne sudo/sysctl im PATH

Windows-hosts-Altlast 10.100.20.60

Docker Engine, der containerisierte NTP-Dienst, die DHCP-NTP-Option, Compose, Portainer, Heimdall und die Apache-Reverse-Proxys laufen auf den vorgesehenen Systemen. Interne HTTP-/HTTPS-Prüfungen und der Windows-Testclient bestätigen die beiden Zugriffspfade; die DNAT-Persistenz nach Router-Neustart wurde nicht geprüft.

• Die iptables-DNAT-Regeln wurden gesetzt; die Persistenz nach Router-Neustart wurde nicht geprüft.
• Der RemoteLab-Zugriff belegt Erreichbarkeit im gegebenen Lab-Kontext, nicht zwingend öffentliche Internet-Erreichbarkeit.
• Die verwendeten TLS-Zertifikate sind selbstsigniert und nicht öffentlich vertrauenswürdig.
• Der Windows-Testclient belegt den Weiterleitungsweg innerhalb der Laborumgebung, nicht eine öffentliche Internet-Erreichbarkeit. Passwort- oder Administrationsfelder sind für diese Funktionsprüfung nicht erforderlich.
• Heimdall wurde als zusätzlicher Containerdienst umgesetzt; für die Kernfunktion mit Docker, Portainer und Reverse Proxy ist es nicht erforderlich.

Der Mailserver wird in drei Zuständen geprüft: erster Stackstart, Betrieb nach der Zertifikatspfadkorrektur und erneuter Start nach der Ressourcenanpassung. Die SMTP-Portkorrektur ergänzt diesen Fehleranalyseweg.

Der Debian-12-LXC srv3 betreibt docker-mailserver und ist über die internen A- und MX-Records in gfn.internal eingebunden. Thunderbird auf CL01 nutzt ein Admin- und ein Student-Konto; die Testmail von admin@gfn.internal erreicht student@gfn.internal. Korrigiert wurden Zertifikatspfad, SRV3-Ressourcen, Zertifikatsvertrauen im Client und ein Student-Passwortfehler. Die Webmail-Optionen wurden nur recherchiert und nicht installiert.

CL01 / Thunderbird -> mail.gfn.internal -> SRV3 192.168.10.14 -> docker-mailserver
CL01 -> SRV1 DNS 192.168.10.11 -> A/MX-Records für gfn.internal
Proxmox/pve -> LXC 102 srv3 mit 4 GiB RAM / 2 GiB Swap nach Korrektur

Nach DNS-/MX-Integration und Postfix-Deaktivierung wird der Docker-Mailserver über Ports, Containerzustand und Konten geprüft. Die Abfolge umfasst Erststart, Zertifikatspfadkorrektur und erneuten Betrieb nach der Ressourcenanpassung.

Der unter Mailserver-Betrieb, Ports und Konten gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Der unter Mailserver-Betrieb, Ports und Konten gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Fall 5 – SMTP-Port-Korrektur

Symptom: Thunderbird legte den Admin-Account zwischenzeitlich mit SMTP Port 465/SSL-TLS an. Kontext: Der Mailserver stellt 465 und 587 bereit; für die vorgegebene Clientkonfiguration wurde jedoch SMTP Submission über Port 587 mit STARTTLS verwendet. Korrektur: Der Ausgangsserver wurde in Thunderbird auf mail.gfn.internal:587 mit STARTTLS und normalem Passwort gesetzt. Ergebnisprüfung: Die Testmail von Admin an Student wurde erfolgreich versendet und empfangen.

Der unter Thunderbird-Konten gezeigte Systemzustand wird in diesem Arbeitsschritt weiterverwendet.

Vier Webmail-Clients wurden für den vorhandenen internen Maildienst verglichen. Die Recherche wurde abgeschlossen, aber nicht als Webmail-Lösung umgesetzt:

Für einen getrennten Webclient passt Roundcube am besten zum vorhandenen IMAP-/SMTP-Aufbau. Diese Aussage ist eine Rechercheentscheidung; keine der vier Lösungen wurde installiert.

SRV3 stellt den internen Docker-Mailserver bereit, DNS und MX zeigen auf mail.gfn.internal, Thunderbird nutzt beide Konten und die Testmail wird empfangen. Die Ressourcenerhöhung und die Lab-CA sind die durchgeführten Korrekturen für stabilen Dienstbetrieb und Clientvertrauen.

Der Mailserver wurde ausschließlich intern geprüft. Externe Zustellung und DKIM/DMARC/SPF für externe Empfänger wurden nicht konfiguriert; Webmail wurde nur recherchiert und nicht installiert.