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].

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

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

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].

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].