Zentralisiertes SSL-Gateway & IPv4-zu-IPv6 Bridge für ISPConfig

E

etron770

Member
Konzept Dieses System ist ein spezialisierter Nginx-Edge-Proxy für ISPConfig-Umgebungen. Es dient als zentraler Einstiegspunkt für den gesamten öffentlichen Traffic und reicht diesen transparent an dedizierte Backend-vServer weiter. Die Konfiguration erfolgt dabei vollautomatisch durch Abgleich mit der ISPConfig-Master-Datenbank.

Lösung der IPv4-Knappheit (Dual-Stack Gateway) Ein wesentlicher technischer Vorteil dieses Setups ist die Funktion als Protokoll-Gateway. In Zeiten knapper und teurer IPv4-Adressen ermöglicht das System ein hochgradig effizientes Ressourcen-Management:

  • Der Edge-Node (Proxy): Dieser verfügt über eine öffentliche IPv4- und IPv6-Anbindung (Dual-Stack).
  • Die Backend-Server (vServer): Diese können als reine IPv6-only Instanzen betrieben werden. Der Proxy nimmt Anfragen aus dem IPv4-Internet entgegen und leitet sie über das interne Netzwerk per IPv6 an die Backends weiter. Damit werden Dienste auf Servern ohne eigene öffentliche IPv4-Adresse weltweit erreichbar.
Funktionsweise

  1. Automatisierte Synchronisation: Ein Hintergrundprozess auf dem Proxy-Server liest die Web-Konfigurationen des ISPConfig-Masters aus. Er erkennt neue oder geänderte Webseiten und generiert daraus automatisch die passenden Nginx-Vhost-Konfigurationen auf dem Edge-Node.
  2. Zentrales SSL-Management: Die Verwaltung und Erneuerung von SSL-Zertifikaten (z. B. Let's Encrypt) erfolgt ausschließlich auf dem Proxy. Die Backend-vServer werden vollständig von der SSL-Validierungslogik und der damit verbundenen Rechenlast befreit.
  3. Transparenter Datenfluss: Anfragen werden unter Beibehaltung aller relevanten Header (Host, Real-IP, Protokoll) an die Backends weitergereicht. Die vServer verarbeiten die Anfragen so, als kämen sie direkt vom Client.
  4. Panel-Konformität: Die Steuerung der Backend-Dienste erfolgt weiterhin direkt über das ISPConfig-Panel. Spezifische Anforderungen wie Port-Weiterleitungen an lokale Dienste (z. B. Gitea oder Docker-Container) werden standardkonform über das Feld der Apache-Direktiven gelöst.
Vorteile

  • Kosteneffizienz: Reduktion der IPv4-Adresskosten, da nur noch der zentrale Proxy-Einstieg eine IPv4-Adresse benötigt.
  • Erhöhte Sicherheit: Die Backend-Infrastruktur ist nicht direkt über das öffentliche IPv4-Netz erreichbar und bleibt hinter dem Proxy maskiert.
  • Zentralisierung: Nur ein System muss für ACME-Challenges (Port 80) offen sein, was die Fehleranfälligkeit bei Zertifikats-Erneuerungen minimiert.
  • SSL-Offloading: Die Verschlüsselung wird am Rand des Netzwerks terminiert, was die Performance der Backend-Applikationen verbessert.
Fazit Dieses Gateway bietet eine Architektur, um ISPConfig-Umgebungen trotz IPv4-Mangels mit IPV4 zu versorgen, ohne den administrativen Aufwand für die Erreichbarkeit und Verschlüsselung der einzelnen Instanzen zu erhöhen.

(Im Gegensatz zu meinem ersten Setup ist kein ISPCONFIG-Patch auf den Clients mehr nötig.)

Aktuelle Scripte und Anleitungen dazu: https://git.sargas.org/public/IPV4-proxyserver-zu-IPV6-only-servern

git.sargas.org wird auch über diesen hier beschriebenen Proxyserver betrieben und hat keine eigene IPV4 Adresse mehr.
 
Zuletzt bearbeitet:
E

etron770

Member

>Aktuelle README.md hier<​


Rich (BBCode): 
============================================================
Dokumentation: ISPConfig & Proxy Inventar (proxy-inventory.sh)
============================================================

BESCHREIBUNG
Dieses Skript dient der automatisierten Statusprüfung aller in
ISPConfig (Version 3.3.0p3) verwalteten Web-Domains.

Es gleicht den Datenbankbestand mit der tatsächlichen
Nginx-Konfiguration auf dem Proxy-Server ab und validiert den
aktuellen DNS-Status.


KERNFUNKTIONEN



FunktionAufgabe
Datenbank-AbgleichExtrahiert aktive Domains (vhost, alias, subdomain)
Proxy-ValidierungPrüft Vorhandensein der Nginx-Konfigurationen
Routing-AnalyseLiest Ziel-IP (proxy_pass) aus den Configs
DNS-Live-CheckPrüft AAAA-Record per dig
Automatischer ExportErstellt /var/www/html/proxy_inventory.txt




VORAUSSETZUNGEN

    

  • System: Linux (getestet auf Debian 12, Proxmox Hostserver mit LCX und VM als Client.
    • 

  • Proxysever VM).
    • 

  • Abhängigkeiten: mysql-client, bind9-host (dig), grep, sed
    • 


Konfigurationsdateien:

    

  • /usr/local/bin/sync-ispconfig-proxy.conf
    • 

  • /usr/local/bin/proxy_based_server.conf
    • 



INSTALLATION

    

  1. proxy-inventory.sh nach /usr/local/bin/ kopieren
    2. 

  2. chmod +x /usr/local/bin/proxy-inventory.sh
    3. 

  3. DB-Zugangsdaten in sync-ispconfig-proxy.conf setzen
    4. 



NUTZUNG



ParameterBeschreibungBeispiel
DOMAINDomain-Filter (Wildcard *)./proxy-inventory.sh knut*
ID <n>ISPConfig Server-ID./proxy-inventory.sh ID 17
PROXY OK/FEHLTProxy-Status filtern./proxy-inventory.sh PROXY FEHLT
DNS OK/N/ADNS-Status filtern./proxy-inventory.sh DNS N/A
MODUSNORMAL oder DUMMY./proxy-inventory.sh MODUS DUMMY




STATUS-DEFINITIONEN

    

  • PROXY OK – Konfigurationsdatei vorhanden
    • 

  • PROXY FEHLT – Domain aktiv, aber keine Proxy-Config
    • 

  • DNS OK – AAAA-Record korrekt
    • 

  • DNS N/A – Keine oder falsche IPv6
    • 



============================================================
ISPConfig Proxy Sync Script (sync-ispconfig-proxy.sh)
============================================================

BESCHREIBUNG
Synchronisiert Web-Domains zwischen ISPConfig-Master und
Nginx-Proxy-Server und erzeugt automatisch Nginx-VHosts
inklusive SSL-Zertifikaten via acme.sh.


KERNFUNKTIONEN



FunktionAufgabe
LockfileVerhindert parallele Ausführung
Datalog-SyncÄnderungen via sys_datalog
Auto-SubdomainAutomatische www-Subdomains
SSL/TLSLet's Encrypt ECC via acme.sh
IPv6 RoutingInterne Netze (z.B. ::113)
Hybrid-ServingLokal + Backend-Proxy




PARAMETER



ParameterBeschreibung
[DOMAIN]Nur eine Domain verarbeiten
testDry-Run, keine Änderungen
forceGesamten Bestand neu verarbeiten
renew / repairSSL-Zertifikate neu ausstellen
-debugDebug-Ausgaben




PRIORITÄTEN

    

  • test – verhindert Änderungen
    • 

  • [DOMAIN] – beschränkt Scope
    • 

  • force – verarbeitet alles
    • 



============================================================
ISPConfig Proxy Cleanup Script (sync-ispconfig-cleanup.sh)
============================================================

BESCHREIBUNG
Entfernt verwaiste Nginx-Proxy-Konfigurationen, die nicht mehr
in der ISPConfig-Datenbank existieren.


KERNFUNKTIONEN



FunktionAufgabe
Verwaisten-CheckFindet nicht mehr genutzte .conf-Dateien
Blocklist-SchutzSchützt manuelle Spezialkonfigurationen
LockfileVerhindert parallele Ausführung
nginx -tSyntax-Check vor Reload




PARAMETER



ParameterBeschreibung
-e / --executeLöschen + nginx Reload
-h / --helpHilfe anzeigen




HINWEIS
Ohne -e läuft das Cleanup-Skript immer im Dry-Run-Modus.
Es werden keine Dateien gelöscht.
 
Zuletzt bearbeitet:
E

etron770

Member
Version < 3.4 von sync-ispconfig-proxy.sh

Update:
Nextcloud iOS Fehler 1005 hinter Reverse-Proxy – Ursachenanalyse und Lösung

Fehlerbild​

Nextcloud-App (iOS) → Fehler 1005

• tritt nur in der iPhone/iPad-App auf

• Browser meldet keine verbindung

Serverseitig wirkt alles korrekt: Zertifikat gültig, HTTPS erreichbar, Webinterface normal nutzbar.

Betroffene Architektur​

Client (iOS App)
↓ HTTPS
Reverse Proxy (TLS Terminierung, nginx)
↓ HTTP
Apache + Nextcloud Backend

Technische Ursache​

Der Fehler hat nichts mit Nextcloud selbst zu tun.

Er entsteht durch eine Protokollinkonsistenz im WebDAV-Authentifizierungs-Handshake, ausgelöst durch:

1. HTTP/2 am TLS-Gateway aktiv

2. Apache-Backend mit mod_http2

3. Reverse-Proxy reicht Backend-Header weiter

Beim Login sendet die App:

PROPFIND /remote.php/dav

Die korrekte Antwort eines WebDAV-Servers:

401 Unauthorized
WWW-Authenticate: Basic realm="Nextcloud"

Der Apache-Backendserver liefert zusätzlich:

Upgrade: h2c

Der Reverse-Proxy reicht diesen Header an den Client weiter.

Die iOS-App interpretiert dies als unzulässigen Protokollwechsel während der Authentifizierung und beendet die Verbindung → Fehler 1005.

Lösung​

es werden vom Git-Repository
https://git.sargas.org/public/IPV4-proxyserver-zu-IPV6-only-servern
benötigt: sync-ispconfig-proxy.sh und nginx.conf
1. Nginx mit neuer Config starten
2. sync-ispconfig-proxy.sh force aufrufen.




Ergebnis​

Der WebDAV-Handshake funktioniert wieder korrekt:

PROPFIND → 401 → Authorization → 207 Multi-Status

Die iOS-App verbindet sich sofort wieder.
 
E

etron770

Member
Version < 3.5 von sync-ispconfig-proxy.sh
iOS / Safari & Nextcloud Sync-Probleme hinter Nginx IPv4-to-IPv6 Proxy

Problembeschreibung: Beim Betrieb eines Nginx-Reverse-Proxys, der IPv4-Anfragen an IPv6-only Backends (z.B. über ISPConfig verwaltet) weiterleitet, kommt es bei iOS-Geräten zu Verbindungsabbrüchen.

  • WebDAV / Nextcloud App: Authentifizierungsversuche (PROPFIND) schlagen fehl oder die Synchronisation bricht ab.
  • Safari: Bestimmte URLs laden nicht oder laufen in einen Timeout. WebSockets werden blockiert.
Technische Ursache:

  1. Header-Stripping (WebDAV): Nginx reicht den Authorization- und Destination-Header standardmäßig nicht an das Backend durch. iOS/Nextcloud benötigt diese zwingend für Dateifreigaben und Authentifizierung.
  2. Protokollinkonsistenz (WebSockets): Ein hart codiertes Blockieren (proxy_hide_header Upgrade) oder fehlerhaftes Erzwingen (Connection "upgrade") bricht reguläre HTTP/2-Keep-Alive-Verbindungen für Safari ab.
  3. Timeouts & Buffering: Aktives Proxy-Buffering führt bei "Chunked Transfers" (Upload großer Dateien aus dem Mobilfunknetz) zu Abbrüchen, da der Proxy auf das vollständige Paket wartet.
  4. Bash-Escaping: Die direkte Generierung der Nginx-Direktiven (wie $host oder $http_upgrade) aus einem Bash-Skript heraus ist fehleranfällig, wenn Variablen vorzeitig aufgelöst werden.
Lösung & Implementierung: Die Erstellung der Nginx-Konfiguration wurde aus dem Haupt-Sync-Skript in eine separate Template-Datei (sync-ispconfig-nginx.tpl) ausgelagert. Dies verhindert Syntaxfehler.

folgende Proxy-Parameter wurden zur transparenten Durchreichung implementiert:
Code: 
# Proxy Einstellungen für iOS, WebDAV und WebSockets
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Dynamischer WebSocket Support (greift nur, wenn vom Client angefordert)
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;

# Transparente Header-Weitergabe für WebDAV (Nextcloud/ownCloud)
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
proxy_set_header Destination $http_destination;

# Anpassungen für große Uploads und fehlerfreies Routing
proxy_read_timeout 3600;
proxy_send_timeout 3600;
proxy_redirect off;
proxy_buffering off;



Gemini hat gesagt​

Modus: Thinking aktiv
Hier ist ein Entwurf für einen technischen Forenbeitrag, der das Problem, die Ursache und die implementierte Lösung sachlich und präzise dokumentiert.
Titel: Fix: iOS / Safari & Nextcloud Sync-Probleme hinter Nginx IPv4-to-IPv6 Proxy
Problembeschreibung: Beim Betrieb eines Nginx-Reverse-Proxys, der IPv4-Anfragen an IPv6-only Backends (z.B. über ISPConfig verwaltet) weiterleitet, kommt es bei iOS-Geräten zu Verbindungsabbrüchen.
  • WebDAV / Nextcloud App: Authentifizierungsversuche (PROPFIND) schlagen fehl oder die Synchronisation bricht ab.
  • Safari: Bestimmte URLs laden nicht oder laufen in einen Timeout. WebSockets werden blockiert.
Technische Ursache:
  1. Header-Stripping (WebDAV): Nginx reicht den Authorization- und Destination-Header standardmäßig nicht an das Backend durch. iOS/Nextcloud benötigt diese zwingend für Dateifreigaben und Authentifizierung.
  2. Protokollinkonsistenz (WebSockets): Ein hart codiertes Blockieren (proxy_hide_header Upgrade) oder fehlerhaftes Erzwingen (Connection "upgrade") bricht reguläre HTTP/2-Keep-Alive-Verbindungen für Safari ab.
  3. Timeouts & Buffering: Aktives Proxy-Buffering führt bei "Chunked Transfers" (Upload großer Dateien aus dem Mobilfunknetz) zu Abbrüchen, da der Proxy auf das vollständige Paket wartet.
  4. Bash-Escaping: Die direkte Generierung der Nginx-Direktiven (wie $host oder $http_upgrade) aus einem Bash-Skript heraus ist fehleranfällig, wenn Variablen vorzeitig aufgelöst werden.
Lösung & Implementierung: Die Erstellung der Nginx-Konfiguration wurde aus dem Haupt-Sync-Skript in eine separate Template-Datei (sync-ispconfig-nginx.tpl) ausgelagert. Dies verhindert Syntaxfehler.
Folgende Proxy-Parameter wurden zur transparenten Durchreichung implementiert:
Nginx

# Proxy Einstellungen für iOS, WebDAV und WebSockets
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

# Dynamischer WebSocket Support (greift nur, wenn vom Client angefordert)
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;

# Transparente Header-Weitergabe für WebDAV (Nextcloud/ownCloud)
proxy_set_header Authorization $http_authorization;
proxy_pass_header Authorization;
proxy_set_header Destination $http_destination;

# Anpassungen für große Uploads und fehlerfreies Routing
proxy_read_timeout 3600;
proxy_send_timeout 3600;
proxy_redirect off;
proxy_buffering off;

Validierung: Ein Test via curl -I -X PROPFIND gegen die Nextcloud-URL mit simuliertem iOS-User-Agent und Dummy-Zugangsdaten liefert nun korrekt den Statuscode 401 Unauthorized inklusive dem WWW-Authenticate: Basic realm="Nextcloud" Header vom IPv6-Backend zurück. Die Proxy-Schicht ist damit transparent.
 
E

etron770

Member

Fail2Ban: Layer-Trennung (L7 Detection / L3 Enforcement)​

Das Problem​

In dieser Reverse-Proxy-Architektur (z. B. Nginx/Proxy vor Apache/client) scheitert klassisches Fail2Ban-Blocking auf dem Backend für IPV4:

  1. L7-Ebene: Das Backend sieht zwar die echte Client-IP (via Header), kann sie aber nur lokal blocken.
  2. L3-Ebene: Da die Verbindung technisch vom Proxy kommt, akzeptiert dieser weiterhin Pakete des Angreifers und leitet sie weiter.
  3. Folge: Das Backend wird trotz "Ban" weiterhin mit Traffic geflutet, was CPU und RAM belastet.

Die Lösung​

Die Trennung von Erkennung und Durchsetzung:

  • Backend (Layer 7): Analysiert Applikations-Logs und erkennt Angriffsmuster (SQLi, Scans, Bots), da hier der Kontext vorliegt.
  • Proxy (Layer 3): Übernimmt das eigentliche Blocking via nftables.

Der Workflow​

  1. Detection: Fail2Ban auf dem Backend erkennt den Angriff.
  2. Trigger: Über eine SSH-Action wird die IP sofort an den Proxy gemeldet.
  3. Enforcement: Der Proxy schreibt die IP in ein zentrales recidive-Jail und blockt sie direkt am Netzwerkeintrittspunkt.

Vorteile​

  • Effizienz: Bösartiger Traffic wird verworfen, bevor er das interne Netzwerk oder den Webserver-Stack belastet.
  • Sauberkeit: Keine "Geister-Last" auf den Backend-Systemen durch bereits gebannte IPs.
  • Zentralisierung: Ein einziger Ort für die Verwaltung aller aktiven IP-Sperren.
Ausführlich siehe im Git-Repository
git.sargas.org

IPV4-proxyserver-zu-IPV6-only-servern/README-Fail2ban.md at main

IPV4-proxyserver-zu-IPV6-only-servern - Automated ISPConfig Edge Proxy ist ein automatisiertes Nginx-Gateway zur zentralen SSL-Terminierung und transparenten Weiterleitung von Web-Traffic an verteilte ISPConfig-Backends. Kurz-Charakteristik Zweck: Zentraler SSL-Endpunkt (Edge) für...
git.sargas.org git.sargas.org
 
N

nowayback

Well-Known Member
Macht aus meiner Sicht keinen Sinn. Ich würde eher so viel wie möglich, soweit vorne wie möglich erkennen und blocken. Dafür gibts genug Tools wie Crowdsec, Cloudflare, Azure Frontdoor, etc., eben alle, die das CoreRuleSet unterstützen. Für Defense in Depth würde ich dann nur noch auf nftables setzen und das blocken, was noch durchgekommen ist. Das sollte aber im Idealfall nicht mehr viel sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Werbung

Top