IPv4/IPv6 Proxyserver -> to IPV6 only Server Unterstützung (Nice-to-Have)

[etron770]

Hallo Til,
die IPv4 sind alle vergeben, die User, die immer noch ihre Router auf IPv4 haben, sinken viel langsamer.
Immer wieder gibt es Beschwerden, dass Webseiten auf IPv6-Only-Servern nicht erreichbar sind.

Ich habe mir einen Proxyserver eingerichtet, der je nach Domain die IPv4-/IPv6-Zugriffe dann auf die reinen IPv6-Server weiterleitet.
Eventuell gibt es bessere Lösungen, meine funktioniert für mich aber.
Es wäre schön, wenn man den Proxyserver mit ispconfig verwalten könnte. Viel braucht man nicht:
1. Feld bei der Domain zum Anklicken: IPv4/IPv6-Proxy aktiv
2. Eintrag, welcher der Proxyserver ist.
Auf dem Proxy:
1. Eintrag der Domains mit den ipv6 Adressen in die Datei: /etc/nginx/stream-enabled/443-sni-map.conf

• Ohne diesen automatischen Eintrag, können ISPConfig-Nutzer keine weiteren Domains oder Subdomains über den Proxyserver weiterleiten lassen.
• Wenn alle Subdomains auf denselben Server gehen, ist das wenig problematisch.
• Der Admin muss die DNS Einträge für die Hauptdomain einrichten.
• Dabei kann er gleich die Wildcard auf dem Proxyserver einrichten

Ein verbessertes System: https://forum.howtoforge.de/threads...way-ipv4-zu-ipv6-bridge-fuer-ispconfig.13974/​

 

[etron770]

Achtung: Diese Config hat Probleme bei Smartphones:

Kurzerklärung: Warum ich dieses Proxy-Setup nicht weiter verfolge​

Ich habe das Setup eines zentralen Nginx-Gateways (Proxyserver) zur Weiterleitung von IPv4-Traffic an IPv6-only Backends (LXC) via SNI-Preread und PROXY-Protokoll eingestellt. Trotz intensiver Optimierung traten bei Zugriffen über Smartphones (Mobilfunk/LTE) reproduzierbare Timeouts und Blockaden auf.

Die Gründe sind technischer Natur und liegen in der Interferenz mehrerer Ebenen:

1. MTU-Black-Holes (Layer 3): Mobilfunknetze nutzen oft kleinere MTUs (ca. 1280 Byte). Durch Hardware-Offloading (GRO/LRO) auf dem Host und in der VM wurden Pakete zu „Jumbo-Frames“ (über 3000 Byte) zusammengefügt. Diese konnten den Tunnel zum Smartphone nicht passieren. Selbst MSS-Clamping löste das Problem nicht für alle Endgeräte zuverlässig.
2. Socket-Exhaustion (App-Ebene): Moderne Smartphone-Browser öffnen beim Start extrem viele parallele Verbindungen. In Kombination mit den hängenden Sockets durch MTU-Fehler und den Timeouts bei ausgeschalteten Backends (Mary) liefen die worker_connections des Proxys voll. Dies führte dazu, dass der Proxy keine neuen Anfragen (z.B. von Firefox) mehr annahm, was wie eine totale Blockade wirkte.

Fazit: Die Komplexität, die Layer-2-Konflikte der Bridge-Virtualisierung mit den MTU-Beschränkungen mobiler Netze und der Aggressivität mobiler Browser in Einklang zu bringen, steht in keinem Verhältnis zum Nutzen. Ich werde auf ein weniger fehleranfälliges Routing-Modell umsteigen.

Ich bin gerade am Testen, die Konfig ist wesentlich einfacher und benötigt keine Patches für ISPConfig.

 

[etron770]

Die neue Version die auf zwei Vservern mit funktioniert:
Hier ist die kurze technische Zusammenfassung der Umstellung von Fury (Layer 4) auf Hidalgo (Layer 7):

1. Architektur & TLS-Terminierung​

Der wesentliche Wechsel erfolgt von einer Layer-4-Weiterleitung (TCP) zu einer Layer-7-Terminierung (HTTP/HTTPS). Hidalgo übernimmt nun die gesamte Verschlüsselung. Dadurch entfällt die Notwendigkeit, dass die Backend-Server eigene Let's Encrypt-Zertifikate verwalten oder das komplexe PROXY-Protokoll unterstützen müssen.

2. IP-Identifikation via Layer 7​

Anstatt die IP-Informationen im TCP-Header (Fury) zu verstecken, nutzt das neue System den HTTP-Standard.

• Hidalgo setzt den Header X-Forwarded-For.
• Das Backend nutzt mod_remoteip, um diesen Header auszulesen und die echte Client-IP in die Applikations-Logs zu schreiben.
• Durch das Setzen des Headers X-Forwarded-Proto "https" "glauben" die Backend-Anwendungen weiterhin, sie würden über eine verschlüsselte Verbindung kommunizieren, obwohl der interne Transport über HTTP (Port 80) läuft.

3. Unterstützung für Spezial-Anwendungen (Redmine, RStudio)​

Ein großer Vorteil dieses Umbaus ist die volle Kompatibilität mit Anwendungen, die einen eigenen internen Proxy-Pass erfordern:

• Applikations-Server: Anwendungen wie Redmine (Ruby/Puma) oder RStudio, die auf eigenen Ports (z.B. 3000 oder 8787) lauschen, werden am Backend-Server lokal via Apache-Proxy angebunden.
• Transparente Weiterleitung: Da Hidalgo den Host-Header und die Forwarded-Header korrekt an den Apache des Backends liefert, kann dieser den Traffic lokal an die App weiterreichen.
• WebSockets: Das Setup auf Hidalgo ist so ausgelegt, dass auch Protokoll-Upgrades (wichtig für die interaktiven Konsolen in RStudio) unterstützt werden,

4. Automatisierung & Skalierbarkeit​

Die Verwaltung erfolgt zentral über das Sync-Skript auf Hidalgo:

• Zentraler Sync: Das Skript liest die ISPConfig-Master-Datenbank aus und erstellt für alle Server, die in der proxy_based_server.conf gelistet sind, automatisch die passenden Nginx-Vhosts.
• Standardisierung: Alle Backends (auch zukünftige Server) folgen demselben einfachen Konfigurationsmuster, was die Wartung auch bei ISPconfig-Updates massiv vereinfacht.