Reverse Proxy im Homelab: Dienste per HTTPS freigeben

Irgendwann laufen im Homelab fünf Dienste mit fünf Weboberflächen: die Fotoverwaltung auf Port 2283, die Cloud auf 8080, Home Assistant im Container auf 8123, dazu Proxmox und der Backup-Server mit eigenem, selbst signiertem Zertifikat. Jeder Aufruf beginnt mit einer Browserwarnung, und wer einen davon unterwegs erreichen will, legt am Router eine Portweiterleitung an – eine je Dienst.

Ein Reverse Proxy räumt das auf. Er ist der eine Eingang, über den alle Webdienste erreichbar sind: ein Port, gültige Zertifikate, sprechende Namen statt Portnummern. Dieser Artikel klärt, was ein Reverse Proxy leistet und was nicht, wo er im Netz steht, welcher der drei verbreiteten zu welchem Aufbau passt – und warum die Verwaltung trotzdem nie durch ihn hindurch erreichbar sein sollte.

Die kurze Antwort

• Ein Reverse Proxy nimmt alle HTTPS-Anfragen an und verteilt sie nach Namen. fotos.example.com geht zur Fotoverwaltung, wolke.example.com zur Cloud – beide über Port 443.
• Er bündelt, was sonst jeder Dienst selbst erledigt: Zertifikate, die Umleitung von HTTP auf HTTPS, Zugriffsregeln und ein gemeinsames Zugriffsprotokoll.
• Er macht einen Dienst nicht sicher. Was er durchlässt, kommt beim Dienst an. Dessen Anmeldung bleibt die eigentliche Grenze.
• Nach außen nur, was andere brauchen. Proxmox, Backup-Server, Router und die Oberfläche des Proxys selbst gehören hinter ein VPN, nicht hinter den Proxy.
• Für den Einstieg: Caddy, wenn eine Textdatei genügt; Traefik, wenn ohnehin alles in Docker läuft; Nginx Proxy Manager, wenn eine Oberfläche gewünscht ist.

Was ein Reverse Proxy macht

Der Browser fragt nicht nach einer IP-Adresse und einem Port, sondern nach einem Namen. Den schickt er beim Verbindungsaufbau mit – im TLS-Handshake als Server Name Indication, in der Anfrage selbst als Host-Kopfzeile. Der Reverse Proxy liest ihn und entscheidet danach, an welchen Dienst er die Anfrage weiterreicht.

Dabei übernimmt er vier Aufgaben, die sonst jeder Dienst einzeln lösen müsste:

Aufgabe	Ohne Proxy	Mit Proxy
Zertifikat	eines je Dienst, meist selbst signiert	automatisch ausgestellt und erneuert, für alle Dienste an einer Stelle
Erreichbarkeit	eine Portweiterleitung je Dienst	eine einzige, auf Port 443
Zugriffsregeln	in jedem Dienst anders oder gar nicht	an einer Stelle: Namen, Quelladressen, vorgeschaltete Anmeldung
Protokoll	verteilt auf die Dienste	ein Zugriffsprotokoll für alle

Mit dem Dienst dahinter spricht der Proxy oft unverschlüsseltes HTTP. Das ist in Ordnung, solange diese Strecke im eigenen Segment bleibt – und genau deshalb ist die Frage, wo der Proxy steht, wichtiger als die, welcher es ist.

Intern oder öffentlich – zwei Betriebsarten

Ein Reverse Proxy heißt nicht automatisch „von außen erreichbar“. Es gibt zwei Betriebsarten, und die erste lohnt sich für jedes Homelab.

Nur intern. Am Router ist kein Port offen. Der Proxy versorgt die Dienste im eigenen Netz mit Namen und gültigen Zertifikaten; von unterwegs geht es über das VPN. Die Zertifikate kommen über die DNS-Challenge (siehe unten), die keinen offenen Port braucht. Die Browserwarnungen sind weg, das Risiko ist dasselbe wie vorher.

Öffentlich. Der Router leitet Port 443 an den Proxy weiter. Ab diesem Moment ist alles, was der Proxy ausliefert, Teil des Internets – mit allem, was Was Bots auf einem neuen Server suchen über die ersten Stunden eines neuen Namens zeigt.

Welche Betriebsart ein Dienst bekommt, entscheidet eine Frage: Muss jemand ohne VPN-Zugang darauf zugreifen?

Dienst	Erreichbar	Warum
Fotoverwaltung mit Freigabelinks	öffentlich	Wer einen Link bekommt, hat kein VPN
Cloud-Synchronisation	öffentlich oder VPN	Öffentlich nur, wenn Geräte ohne VPN synchronisieren müssen
Passwortmanager (Vaultwarden)	VPN, öffentlich nur wenn nötig	Der Web-Tresor läuft nur über HTTPS; die Admin-Seite /admin nie öffentlich
Hausautomation	VPN	Die App funktioniert auch über den Tunnel
Medienserver	VPN, außer Fremde streamen mit	Selten nötig, oft ungepflegt
Proxmox, Backup-Server, Router, Switch	nur VPN	Wer sie übernimmt, hat das ganze Labor
Oberfläche des Proxys	nur VPN	Sie entscheidet über alle anderen

Dass der Medienserver auf der Liste steht, hat einen bekannten Grund: Beim Einbruch bei LastPass 2022 kamen die Angreifer über eine seit Jahren ungepatchte Medienserver-Software auf dem Heimrechner eines Mitarbeiters an dessen Master-Passwort – ein Keylogger schnitt es mit. Ein Dienst, den man selten anschaut, wird auch selten aktualisiert.

Die letzten beiden Zeilen lassen keine Wahl, und das ist Absicht. Eine Verwaltungsoberfläche „nur mit Passwort“ ins Internet zu stellen, ist der häufigste Fehler in diesem Thema – mehr dazu unten.

Wo der Proxy steht

Hier zahlt sich die Segmentierung aus VLANs im Homelab aus. Dort ist das Segment 70 „Von außen erreichbar“ vorgesehen: Hinein kommt das Internet, nur über den Proxy; hinaus führt nichts nach innen.

Daraus folgt der Aufbau:

1. Der öffentliche Proxy steht in VLAN 70 – zusammen mit den Diensten, die er veröffentlicht. Im Beispiel hat er 10.20.70.10, Fotoverwaltung und Cloud liegen auf .21 und .22.
2. Die Firewall leitet Port 443 an 10.20.70.10 weiter, sonst nichts. Port 80 nur, wenn die Zertifikate über die HTTP-Challenge kommen.
3. Vom Proxy führt keine Regel in die anderen Segmente. Er erreicht seine Dienste, weil sie im selben Segment stehen. Proxmox, Backup und die internen Dienste sieht er nicht.

Punkt 3 ist der eigentliche Gewinn. Ein Reverse Proxy ist ein Programm, das Anfragen aus dem Internet verarbeitet, und kann wie jedes andere eine Lücke haben. Steht er im Dienste-Netz, steht ein Angreifer nach einem Einbruch neben allem anderen. Steht er in VLAN 70, steht er neben zwei Diensten, die ohnehin öffentlich sind.

Für die internen Dienste ein zweiter Proxy. Wer auch im Dienste-Segment Namen und gültige Zertifikate will, betreibt dort eine zweite Instanz, etwa auf 10.20.20.10, ohne Portweiterleitung. Ein einziger Proxy mit je einem Bein in beiden Segmenten ist bequemer – und genau die Brücke, die die Segmentierung verhindern soll.

Als Container oder VM. Ein Reverse Proxy braucht wenig: Ein unprivilegierter LXC-Container auf Proxmox genügt. Wer den öffentlichen Proxy strenger vom Host trennen will, nimmt eine kleine VM – die Abwägung steht in VM oder LXC-Container. Am Netzwerkgerät bekommt er das VLAN-Tag 70.

Von innen: interner DNS statt Umweg über den Router. Ruft ein Gerät zu Hause fotos.example.com auf, zeigt der öffentliche DNS-Eintrag auf die eigene öffentliche Adresse. Die Anfrage müsste am Router umkehren (NAT-Reflexion), was nicht jeder Router kann. Sauberer ist es, wenn der interne DNS-Server den Namen direkt mit 10.20.70.10 beantwortet und eine Regel Clients → 10.20.70.10, Port 443, erlaubt. Manche Router verwerfen DNS-Antworten, die für einen öffentlichen Namen eine private Adresse liefern (DNS-Rebind-Schutz); dort die eigene Domain als Ausnahme eintragen. Wo die Adressen im Gesamtplan liegen, zeigt IP-Adressplan fürs Homelab.

Caddy, Traefik oder Nginx Proxy Manager

	Caddy	Traefik	Nginx Proxy Manager
Konfiguration	eine Textdatei (Caddyfile)	Labels an den Docker-Containern, dazu eine Grunddatei	Weboberfläche
Zertifikate	automatisch, ohne eine Zeile Konfiguration	automatisch, sobald ein Zertifikatsanbieter hinterlegt ist	per Klick je Proxy-Host
DNS-Challenge	nur mit Zusatzmodul für den DNS-Anbieter	eingebaut, viele Anbieter	eingebaut, viele Anbieter
Stärke	kürzeste Konfiguration, gute Standardwerte	erkennt neue Container von selbst	ohne Konfigurationsdatei bedienbar
Schwäche	eigener Build für die DNS-Challenge	eigene Begriffswelt: Router, Services, Middlewares	Sonderwünsche nur als rohes nginx im Reiter Advanced
Passt, wenn	VMs, Container und Hardware gemischt sind	alles als Docker-Compose-Projekt läuft	eine Oberfläche gewünscht ist

Alle drei sind ausgereift und im Homelab-Maßstab schnell genug. Die Wahl entscheidet sich an der Frage, wo die Konfiguration leben soll: in einer Datei, an den Containern oder in einer Datenbank hinter einer Oberfläche. Wer nginx oder HAProxy schon kennt, kann auch direkt diese nehmen, holt die Zertifikate dann aber meist über ein zusätzliches Werkzeug.

Bei Nginx Proxy Manager auf eines achten: Seine Oberfläche läuft auf Port 81. Dieser Port gehört nicht in die Portweiterleitung und ist nur vom Admin-Gerät oder über das VPN erreichbar. Dasselbe gilt für das Dashboard von Traefik.

Einrichten am Beispiel Caddy

Caddy steht hier, weil die Konfiguration kurz genug ist, um sie vollständig abzudrucken. Die Begriffe übertragen sich auf die anderen beiden.

Die ganze Konfiguration für zwei öffentliche Dienste:

fotos.example.com {
	reverse_proxy 10.20.70.21:2283
}

wolke.example.com {
	reverse_proxy 10.20.70.22:80
}

Mehr ist für den Anfang nicht nötig. Caddy holt für beide Namen beim Start ein Zertifikat, erneuert es selbstständig, leitet HTTP auf HTTPS um und reicht WebSocket-Verbindungen durch. Die Kopfzeilen, an denen der Dienst die echte Adresse des Besuchers erkennt (X-Forwarded-For, X-Forwarded-Proto), setzt Caddy ebenfalls von selbst. Voraussetzung: Beide Namen zeigen im öffentlichen DNS auf die eigene Adresse, und Port 443 ist an den Proxy weitergeleitet.

Punktdateien sperren – mit einer Ausnahme

Die Regel aus dem Bots-Artikel, Dateien mit führendem Punkt nie auszuliefern, gehört an den Proxy, weil sie dort für alle Dienste zugleich gilt. Mit einem Haken: Unter /.well-known/ liegen Adressen, die gebraucht werden – über sie finden Kalender- und Kontakt-Apps den Zugang zur Cloud. Eine pauschale Sperre bricht deren automatische Einrichtung. Deshalb ein Baustein mit Ausnahme, der in jeden Block eingebunden wird:

(punktdateien) {
	@punkt {
		path */.*
		not path /.well-known/*
	}
	respond @punkt 404
}

wolke.example.com {
	import punktdateien
	redir /.well-known/carddav /remote.php/dav/ 301
	redir /.well-known/caldav /remote.php/dav/ 301
	reverse_proxy 10.20.70.22:80
}

path */.* trifft jeden Pfad, der irgendwo /. enthält – also /.env ebenso wie /backup/.git/config. Die beiden redir-Zeilen braucht Nextcloud hinter einem Proxy: Ihre eigene Weiterleitung für Kalender und Kontakte funktioniert dort laut Dokumentation nicht, deshalb übernimmt sie der Proxy.

Die echte Besucheradresse

Hinter dem Proxy sieht jeder Dienst zunächst nur eine Adresse: die des Proxys. Die echte steht in der Kopfzeile X-Forwarded-For – aber ein Dienst glaubt ihr nur, wenn der Proxy bei ihm als vertrauenswürdig eingetragen ist. Zwei Fälle, die fast jeder trifft:

Home Assistant lehnt Anfragen mit dieser Kopfzeile von einem nicht eingetragenen Proxy ab und antwortet mit 400 Bad Request. In der configuration.yaml, hier mit dem internen Proxy:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 10.20.20.10

Nextcloud funktioniert ohne Eintrag scheinbar normal. Der Schutz gegen Passwort-Rateversuche zählt dann aber alle Fehlversuche der Proxy-Adresse zu – und bremst irgendwann jeden Besucher zugleich. In der config.php:

'trusted_proxies' => ['10.20.70.10'],
'overwriteprotocol' => 'https',

Die zweite Zeile sorgt dafür, dass Nextcloud seine eigenen Links mit https erzeugt, obwohl es vom Proxy über HTTP angesprochen wird.

Zertifikate: drei Wege, ein Unterschied

Let’s Encrypt prüft bei jeder Ausstellung, ob der Antragsteller den Namen kontrolliert. Dafür gibt es drei Wege:

Challenge	Braucht	Wildcard	Gut für
HTTP-01	Port 80 von außen erreichbar	nein	öffentliche Dienste, einfachster Weg
TLS-ALPN-01	Port 443 von außen erreichbar	nein	öffentliche Dienste ohne offenen Port 80
DNS-01	Zugang zur Schnittstelle des DNS-Anbieters	ja	interne Dienste, Wildcard-Zertifikate

Bei den ersten beiden fragt Let’s Encrypt den Server selbst ab – er muss also aus dem Internet erreichbar sein. Bei DNS-01 legt der Proxy einen TXT-Eintrag in der Zone an, und der Server muss für niemanden erreichbar sein. Deshalb ist die DNS-Challenge der Weg für den internen Proxy.

Was die Zertifikate verraten

Jedes öffentlich vertrauenswürdige Zertifikat wird in öffentliche Protokolle eingetragen (Certificate Transparency), und Scanner lesen sie laufend mit. Ein Zertifikat für pve.example.com teilt der Welt mit, dass es diesen Namen gibt und was dahinter vermutlich läuft – auch dann, wenn der Name nur im eigenen Netz auflöst. Mit einer Zertifikatssuche wie crt.sh lässt sich das für die eigene Domain nachsehen.

Ein Wildcard-Zertifikat für *.example.com verrät nur die Domain. Es gibt sie nur über die DNS-Challenge – ein weiterer Grund für sie, gerade beim internen Proxy. Die Namen verschwinden dadurch allerdings nur aus den Protokollen: Wer fotos oder cloud rät, findet den Dienst trotzdem. Das senkt das Rauschen, es ersetzt keine Absicherung.

Der Schlüssel für den DNS-Anbieter

Für die DNS-Challenge liegt ein API-Schlüssel des DNS-Anbieters auf dem Proxy. Wer den Proxy übernimmt, kann damit die Einträge der Domain ändern – bis hin zur Umleitung der E-Mail. Den Schlüssel deshalb so eng fassen, wie der Anbieter es erlaubt: nur diese eine Zone und, wenn möglich, nur TXT-Einträge. Auf dem öffentlichen Proxy, der über HTTP-01 oder TLS-ALPN-01 auskommt, hat er nichts verloren.

Die Ausstellungsgrenze

Let’s Encrypt stellt für genau dieselben Namen höchstens fünf Zertifikate innerhalb von sieben Tagen aus. Wer beim Ausprobieren den Container immer wieder neu anlegt und dabei den Zertifikatsspeicher verwirft, wartet danach bis zu einer Woche. Abhilfe: Der Speicher liegt auf einem dauerhaften Volume – bei Caddy das Datenverzeichnis, bei Traefik die Datei acme.json, bei Nginx Proxy Manager der Ordner letsencrypt –, und beim Testen kommt die Staging-Umgebung von Let’s Encrypt zum Einsatz. Deren Zertifikate erkennt kein Browser an, dafür liegen die Grenzen weit höher.

Was vor den Proxy gehört

Der Proxy entscheidet, wer bis zum Dienst kommt. Vier Mittel, aufsteigend nach Aufwand:

Unbekannte Namen abweisen. Scanner fragen nicht nur Namen aus den Zertifikatsprotokollen ab, sondern auch ganze Adressbereiche – per IP-Adresse, ohne Namen. Caddy beantwortet eine HTTPS-Anfrage per IP-Adresse gar nicht erst, weil es dafür kein Zertifikat hat. Bei nginx dagegen landet eine Anfrage ohne bekannten Namen beim Standard-Server, und das ist ohne weitere Angabe der erste definierte Dienst. Abhilfe ist ein eigener Standard-Server, der den Verbindungsaufbau ablehnt:

server {
	listen 443 ssl default_server;
	ssl_reject_handshake on;
}

Nginx Proxy Manager stellt dasselbe unter Settings → Default Site ein; „404“ oder „No Response“ sind die richtige Wahl, nicht die Begrüßungsseite.

Vorgeschaltete Anmeldung. Mit Authelia, Authentik oder einem ähnlichen Dienst verlangt der Proxy eine Anmeldung, bevor eine Anfrage den Dienst überhaupt erreicht (Forward Auth). Das schützt Dienste mit schwachem oder fehlendem eigenem Login. Der Haken: Smartphone-Apps und Synchronisationsprogramme sprechen den Dienst direkt über seine Schnittstelle an und kennen diese Anmeldeseite nicht. Für die Cloud-App, den Foto-Upload vom Handy oder die Home-Assistant-App braucht es dann Ausnahmen für deren Pfade – und jede Ausnahme ist wieder ein offener Weg.

Mitlesen. Das Zugriffsprotokoll des Proxys ist die eine Stelle, an der alle Anfragen auf alle Dienste stehen. Caddy schreibt es erst, wenn es im Block mit log eingeschaltet ist, in eine Datei dann als JSON. Die Auswertung aus dem Bots-Artikel sieht dann so aus:

# Die zwanzig häufigsten Pfade, die es nicht gibt
jq -r 'select(.status == 404) | .request.uri' access.log \
  | sort | uniq -c | sort -rn | head -20

Bei nginx und Nginx Proxy Manager funktionieren die Befehle aus dem Bots-Artikel unverändert.

Zuerst aktualisieren. Der Proxy ist das Programm mit dem meisten Kontakt zum Internet. Er bekommt seine Updates als Erster, nicht als Letzter – ob über die Paketquelle oder ein neu gezogenes Container-Image, mit einem festen Termin dafür.

Prüfen, was von außen sichtbar ist

Von außen heißt wirklich von außen: vom Laptop über den Hotspot des Smartphones, nicht aus dem eigenen WLAN. Im eigenen Netz antwortet der interne DNS, und es gelten andere Firewall-Regeln.

# Welche Ports sind offen? Erwartet: nur 443 (und 80 bei HTTP-01)
nmap -Pn -p 22,80,81,443,8006,8007,8080,8123 <öffentliche-adresse>

# Anfrage per IP-Adresse: darf keinen Dienst zeigen
curl -kI https://<öffentliche-adresse>/

# Ein veröffentlichter Name: 200 oder Weiterleitung zur Anmeldung
curl -I https://fotos.example.com/

# Punktdateien: müssen 404 liefern
curl -s -o /dev/null -w '%{http_code}\n' https://fotos.example.com/.env

Bei Caddy endet die zweite Zeile mit einem TLS-Fehler – das ist das gewünschte Ergebnis. Hat die Domain einen AAAA-Eintrag, dieselben Prüfungen über IPv6 wiederholen: curl -6 und nmap -6 gegen die IPv6-Adresse des Proxys.

Häufige Fehler

Die Verwaltung „nur mit Passwort“ veröffentlichen. Proxmox, Backup-Server oder Router-Oberfläche hinter dem Proxy, weil ja ein Login davor ist. Genau diese Oberflächen stehen auf den Listen der Scanner, und eine Lücke in ihnen ist eine Lücke im ganzen Labor. Dafür gibt es das VPN.

Der Proxy im Dienste-Netz. Bequem, weil er alles erreicht – und genau deshalb falsch. Nach einem Einbruch in den Proxy steht der Angreifer neben jedem internen Dienst.

Die Oberfläche des Proxys veröffentlicht. Port 81 von Nginx Proxy Manager oder das Traefik-Dashboard in der Portweiterleitung. Wer sie übernimmt, leitet jeden Dienst um, wohin er will.

Den Proxy bei den Diensten nicht eingetragen. Home Assistant antwortet mit 400, Nextcloud bremst alle Besucher, und die Protokolle der Dienste zeigen nur noch eine einzige Adresse.

Im WLAN geht es, im Mobilfunk nicht. Häufig steckt IPv6 dahinter. Hat der Name einen AAAA-Eintrag, versuchen es Smartphones im Mobilfunk zuerst über IPv6. Zeigt der Eintrag auf ein Gerät, auf dem der Proxy nicht lauscht, oder lässt die Firewall eingehendes IPv6 zum Proxy nicht durch, hängt die Verbindung oder bricht ab – zu Hause im WLAN fällt das nie auf. Entweder IPv6 vollständig einrichten oder den AAAA-Eintrag entfernen.

Uploads scheitern mit 413. Kleine Dateien gehen, große enden mit Request Entity Too Large: nginx begrenzt den Anfrageinhalt ab Werk auf 1 MB (client_max_body_size). Bei einer eigenen nginx-Konfiguration für Cloud und Fotos den Wert anheben. Caddy setzt ab Werk keine solche Grenze.

Der Zertifikatsspeicher liegt im Container. Jedes Neuanlegen holt neue Zertifikate, bis die Ausstellungsgrenze erreicht ist – siehe oben.

Checkliste

• Nach außen ist nur Port 443 offen (und 80, wenn die HTTP-Challenge genutzt wird)
• Der öffentliche Proxy steht im Segment „von außen erreichbar“ und erreicht nichts Internes
• Proxmox, Backup-Server, Router und die Proxy-Oberfläche sind nur per VPN erreichbar
• Anfragen per IP-Adresse oder mit unbekanntem Namen landen bei keinem Dienst
• Punktdateien liefern 404, /.well-known/ funktioniert weiter
• Die Dienste kennen den Proxy als vertrauenswürdig
• Der Zertifikatsspeicher liegt auf einem dauerhaften Volume
• Der Schlüssel für den DNS-Anbieter darf nur, was die Challenge braucht
• IPv6 ist entweder vollständig eingerichtet oder der AAAA-Eintrag fehlt
• Die Prüfung von außen lief über das Mobilfunknetz

Häufige Fragen

Brauche ich einen Reverse Proxy, wenn nichts von außen erreichbar sein soll? Er lohnt sich trotzdem. Intern liefert er über die DNS-Challenge gültige Zertifikate und Namen statt Portnummern – ohne einen einzigen offenen Port am Router.

Caddy, Traefik oder Nginx Proxy Manager – welcher ist der beste? Im Homelab entscheidet nicht die Leistung, sondern wo die Konfiguration leben soll. Caddy für die kürzeste Konfiguration, Traefik, wenn alles in Docker läuft, Nginx Proxy Manager, wenn eine Oberfläche gewünscht ist.

Macht ein Reverse Proxy meine Dienste sicherer? Nur mittelbar. Er bündelt Zertifikate und Regeln und hält nicht veröffentlichte Dienste aus dem Internet heraus. Eine Lücke im Dienst selbst schließt er nicht – was er durchlässt, kommt beim Dienst an.

Geht das ohne öffentliche IPv4-Adresse? Mit einer Portweiterleitung nicht. Hat der Anschluss nur eine geteilte IPv4-Adresse (DS-Lite, Carrier-Grade NAT), bleiben IPv6 – sofern alle Nutzer es haben – oder ein Tunnel zu einem gemieteten Server mit öffentlicher Adresse.

Brauche ich eine eigene Domain? Für öffentlich vertrauenswürdige Zertifikate ja. Let’s Encrypt stellt nur für Namen aus, deren Kontrolle sich nachweisen lässt. Für die DNS-Challenge muss der DNS-Anbieter der Domain zusätzlich eine Schnittstelle anbieten, die der Proxy unterstützt.

Läuft der Proxy besser im Container oder in einer VM? Für den internen Proxy genügt ein unprivilegierter LXC-Container. Für den öffentlichen ist eine kleine VM die strengere Trennung vom Host.

Weiter

• VLANs im Homelab – das Segment „von außen erreichbar“ und die Regeln dazu
• IP-Adressplan fürs Homelab – wo Proxy und Dienste ihre Adressen bekommen
• Was Bots auf einem neuen Server suchen – was an einem veröffentlichten Namen ankommt
• VM oder LXC-Container – wo der Proxy auf Proxmox läuft
• Ransomware-sichere Backups – falls doch einmal etwas durchkommt