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

[etron770]

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.

 

[etron770]

>Aktuelle README.md hier<​

============================================================
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

Funktion
Aufgabe
Datenbank-Abgleich
Extrahiert aktive Domains (vhost, alias, subdomain)
Proxy-Validierung
Prüft Vorhandensein der Nginx-Konfigurationen
Routing-Analyse
Liest Ziel-IP (proxy_pass) aus den Configs
DNS-Live-Check
Prüft AAAA-Record per dig
Automatischer Export
Erstellt /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

proxy-inventory.sh nach /usr/local/bin/ kopieren
chmod +x /usr/local/bin/proxy-inventory.sh
DB-Zugangsdaten in sync-ispconfig-proxy.conf setzen


NUTZUNG

Parameter
Beschreibung
Beispiel
DOMAIN
Domain-Filter (Wildcard *)
./proxy-inventory.sh knut*
ID <n>
ISPConfig Server-ID
./proxy-inventory.sh ID 17
PROXY OK/FEHLT
Proxy-Status filtern
./proxy-inventory.sh PROXY FEHLT
DNS OK/N/A
DNS-Status filtern
./proxy-inventory.sh DNS N/A
MODUS
NORMAL 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

Funktion
Aufgabe
Lockfile
Verhindert parallele Ausführung
Datalog-Sync
Änderungen via sys_datalog
Auto-Subdomain
Automatische www-Subdomains
SSL/TLS
Let's Encrypt ECC via acme.sh
IPv6 Routing
Interne Netze (z.B. ::113)
Hybrid-Serving
Lokal + Backend-Proxy


PARAMETER

Parameter
Beschreibung
[DOMAIN]
Nur eine Domain verarbeiten
test
Dry-Run, keine Änderungen
force
Gesamten Bestand neu verarbeiten
renew / repair
SSL-Zertifikate neu ausstellen
-debug
Debug-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

Funktion
Aufgabe
Verwaisten-Check
Findet nicht mehr genutzte .conf-Dateien
Blocklist-Schutz
Schützt manuelle Spezialkonfigurationen
Lockfile
Verhindert parallele Ausführung
nginx -t
Syntax-Check vor Reload


PARAMETER

Parameter
Beschreibung
-e / --execute
Löschen + nginx Reload
-h / --help
Hilfe anzeigen


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

 

[etron770]

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.

 

[etron770]

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:

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