====== 🔀 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]:

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

===== 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 <code>service named restart</code> 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].