2.7 KiB
Proxyserver: Edge-Proxy & Backend Dokumentation
Stand: Januar 2026
Fokus: Routed IPv6 Setup & Internes IPv4-VPN/Bridge für isolierte Backends (Root-Server / LXC)
Konzept-Hinweis
Dieses Setup ist für Root-Server optimiert, auf denen Proxyserver und die Backends (VMs/LXCs) über interne Bridges (z. B. vmbr1) kommunizieren.
Dies umgeht MTU-Probleme, wie sie bei WireGuard im mobilen Bereich auftreten.
1. Netzwerk-Architektur (IPv4-VPN)
Für IPv4-only Backends ohne öffentliche IP wird ein isoliertes Segment genutzt:
- Proxyserver (Gateway):
10.8.1.x - Clients (Backends):
10.8.1.y - Interface:
vmbr1(Bridge) oder Tinc-Tunnel
Proxyserver übernimmt das NAT (Masquerading), damit Clients Updates ziehen können, und dient als Standard-Gateway für die Backends.
2. Proxyserver Setup (Der Proxy-Dienst)
Installiere Nginx und ACME.sh auf Proxyserver.
Die Synchronisation erfolgt über ein zentrales Bash-Skript.
ACME Zertifikatserneuerung wie gewohnt über crontab
2.1 Konfigurationsdatei
Pfad: /usr/local/bin/sync-ispconfig-proxy.conf
2.2 Server-Liste
Pfad: /usr/local/bin/proxy_based_server.conf
2.3 Das Sync-Skript
Pfad: /usr/local/bin/sync-ispconfig-proxy.sh
3. Client Setup (vServer / Apache)
Die Backends müssen den Proxy als vertrauenswürdig einstufen.
3.1 Remote-IP Konfiguration
Pfad: /etc/apache2/conf-available/remoteip.conf
a2enmod remoteip proxy_http rewrite headers
a2enconf remoteip
systemctl restart apache2
4. ISPConfig Integration (Apache Direktiven Beispiel Gitea)
Eintragen unter Webseite → Optionen → Apache Direktiven für den vServer:
# Gitea / Backend Proxy
RequestHeader set X-Forwarded-Proto "https"
ProxyPreserveHost On
<Proxy *>
Order allow,deny
Allow from all
</Proxy>
# Lokale Weiterleitung an den Dienst-Port (z. B. Gitea)
ProxyPass / http://[::1]:3000/
ProxyPassReverse / http://[::1]:3000/
# WebSocket Upgrade Support
RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) ws://[::1]:3000/$1 [P,L]
Achtung:
Deaktiviere SSL und Let's Encrypt innerhalb von ISPConfig für diese Webseite, da Proxyserver die Zertifikatsverwaltung übernimmt.
Deaktivere Zertifikatserneuerung auf den Clients
Werden doppelte Domains eingetragen um auf weiteren Servern Subdomains zu nutzen, muss
- der Weiterleitungspfad /urldummy/ auf den Servern bei denen die Hauptdomin nungenutzt ist lauten
- auf dem Server bei dem die Hauptdomain genutzt wird darf der Weiterleitungspfad nicht /urldummy/ lauten nur so wird sichergestellt, dass das sync-ispconfig-proxy.sh script die Zertifikatserstellung für diese Dummy Hauptdomains auslässt