🔀 Nginx Proxy Manager (Reverse Proxy)

In diesem Kapitel wird die zentrale Routing- und Proxy-Infrastruktur dokumentiert. Der Nginx Proxy Manager (NPM) fungiert als Gateway, um interne Dienste ohne Port-Angaben über standardisierte Domainnamen (FQDN) erreichbar zu machen [2, 6].

1. Systemarchitektur

Der Reverse Proxy läuft als Docker-Container auf einer dedizierten virtuellen Maschine (Debian 13) und bündelt den gesamten eingehenden Web-Traffic [6].

Server / Rolle	Betriebssystem	Plattform	Dienst
Reverse Proxy	Debian 13	Docker	Nginx Proxy Manager

2. Firewall- & Netzwerk-Konfiguration

Um den reibungslosen Datenverkehr und den Zugriff auf das Admin-Dashboard zu gewährleisten, wurden spezifische Ports in der UFW-Firewall freigegeben [3]:

sudo ufw allow 80/tcp # HTTP-Traffic
sudo ufw allow 443/tcp # HTTPS-Traffic
sudo ufw allow 81/tcp # NPM Admin-Dashboard

3. Dienst-Spezifische Konfigurationen

Die Weiterleitung wurde für verschiedene Dienste (z. B. Webmin, Zammad, Guacamole) eingerichtet [2, 5, 7]. Dabei mussten dienstspezifische Parameter zwingend beachtet werden:

Zammad & Guacamole: Für diese Dienste wurde die Option “Websockets Support” im NPM-Panel aktiviert [2, 5]. Ohne WebSockets brechen Echtzeit-Synchronisationen (Zammad) und Remote-Sitzungen (Guacamole) ab [2, 5].

Webmin (Master Node): Beim Einsatz eines Reverse Proxys für die Server-Verwaltung traten anfänglich SSL-Handshake- und Cookie-Konflikte auf [1, 7].

Lösung: In der Webmin-Konfiguration (/etc/webmin/miniserv.conf) muss der Parameter trust_real_ip=1 gesetzt werden [1]. Zudem zeigte sich, dass direkte IP-Zugriffe mit SSL für interne Management-Tools teilweise stabiler sind als komplexe Proxy-over-Proxy-Setups [1].

4. Fehlerbehebung (Troubleshooting)

Während der Implementierung und DNS-Verknüpfung traten lehrreiche Fehler auf, die analysiert und gelöst wurden:

Fehler 1: DNS-Einträge greifen nicht [3]

Ursache: Die “Serial”-Nummer im BIND9 Zone-File wurde nach dem Hinzufügen der neuen Proxy-Einträge nicht aktualisiert [3].

Lösung: Die Serial-Nummer wurde manuell erhöht und der DNS-Dienst via

service named restart

neu geladen, um den Zonentransfer zu erzwingen [2, 3].

Fehler 2: Falscher Ausführungskontext (Terminal-Verwechslung) [3, 4]

Ursache: Eine aktive SSH-Sitzung war noch auf der falschen VM (Zammad) geöffnet, sodass Netzwerk-Tools versehentlich auf dem falschen Host installiert wurden [3].

Lösung: Die Sitzungen wurden überprüft und die aktive SSH-Verbindung wurde auf den korrekten NPM-Host umgestellt, was die Wichtigkeit eines eindeutigen Hostname-Prompts unterstreicht [4].