Seminar Zoraxy Grundlagen, Architektur und Web-UI

Inhaltsverzeichnis

• Abstract
• Zielgruppe und Voraussetzungen
• Lernziele
• Agenda
• Praxisübungen
• Ergebnisartefakte

Abstract

Dieses Seminar schafft eine belastbare Grundlage für den Einsatz von Zoraxy als Reverse-Proxy- und Routing-Komponente. Im Fokus stehen Architektur, Web-UI, grundlegende Proxy-Regeln, typische Routing-Patterns und ein erster Sicherheitsbaseline-Check. Der Praxisteil führt durch eine Standard-Umgebung mit mehreren Backend-Services und Validierung per Testfällen. Funktionen wie WebSocket-Proxy und Basic Auth werden anhand klarer Use Cases eingeordnet.

Zielgruppe und Voraussetzungen

• Zielgruppe: Systemadministration, DevOps, Homelab-/Plattformbetrieb, IT-Security (Basis)
• Voraussetzungen:
  • Grundverständnis HTTP, DNS, TLS (Begriffe)
  • Zugriff auf (VM oder Container-Host)
  • Keine Vorkenntnisse in Zoraxy erforderlich

Lernziele

• Zoraxy-Funktionsumfang und Betriebsmodi einordnen
• Web-UI sicher bedienen und Änderungen strukturiert dokumentieren
• Erste Reverse-Proxy-Regel mit Testfällen erstellen
• WebSocket-Weiterleitung und Auth-Basisfall umsetzen
• Minimaler Sicherheitsbaseline-Check für Admin-Interface und Proxy-Regeln

Agenda

• Überblick: Zoraxy als Reverse Proxy und „Toolbox“ (Features, Grenzen)
• Architektur-Bausteine: Management-Interface, Proxy-Regeln, Zertifikatsverwaltung
• Web-UI-Navigation: Struktur, Settings, Prinzip „Änderungen ohne Neustart“
• Praxis 1: Erste Reverse-Proxy-Regel und Testmatrix
• Praxis 2: WebSocket-Weiterleitung und Validierung
• Praxis 3: Basic Auth als Basisschutz
• Ergebnischeck, Artefakte, Übergang 

Praxisübungen

• Topologie und Testfälle aufsetzen
  • Backend-Services definieren:
    • Service A: Web-App (HTTP)
    • Service B: Web-App (HTTP)
    • Service C: WebSocket-fähiger Endpoint
  • Namenskonzept festlegen:
    • Subdomain-Pattern: app-a, app-b, ws
  • Testmatrix erstellen:
    • HTTP 200/302, Header-Check, Hostname-Auflösung, Latenz, Fehlerfall 502/504
  • Baseline-Logging aktivieren (sofern im Lab vorgesehen)
  • Ergebnis: dokumentierte Testmatrix als Seminarartefakt
• Erste Reverse-Proxy-Regel erstellen und verifizieren
  • Ziel-Hostname festlegen (z. B. app-a.beispiel.tld)
  • Proxy-Regel erstellen:
    • Upstream: Service-A-IP/Port
    • Hostname-Mapping: app-a.beispiel.tld
  • Validierung:
    • DNS-Auflösung (Lab-DNS oder Hosts-Datei)
    • Browser- und CLI-Test (Statuscode, Response-Header)
  • Fehlerbilder simulieren:
    • falscher Port
    • nicht erreichbarer Upstream
  • Ergebnis: funktionierende Regel + dokumentierte Prüfungen
• WebSocket-Proxy prüfen
  • WebSocket-Service auswählen (Service C)
  • Regel erstellen oder bestehende Regel erweitern
  • Validierung:
    • Verbindung aufbauen
    • Nachrichten senden/empfangen
  • Ergebnis: dokumentierter Nachweis der WebSocket-Funktion
• Basic Auth als Minimal-Guardrail
  • Credential-Strategie definieren (Demo-User, Rotation im Betrieb)
  • Basic-Auth am passenden Einstiegspunkt aktivieren (Regel oder Pfad, je nach Use Case)
  • Validierung:
    • Zugriff ohne Credentials abgewiesen
    • Zugriff mit Credentials erfolgreich
  • Ergebnis: Basisschutz umgesetzt + Notiz zur Limitierung (kein SSO, keine MFA)

Ergebnisartefakte

• Architektur-Skizze der Zielumgebung
• Testmatrix (HTTP/WS)
• Dokumentierte Proxy-Regel inkl. Upstream-Parameter
• Baseline-Hardening-Checkliste (aus Seminarbausteinen)