Umgang mit verschlüsselten und unverschlüsselten http-Verbindungen über einen einzigen Port

Bitte schauen Sie sich das folgende Diagramm an.

Wie soll das funktionieren?

• Wenn eine Fernbedienung http: // myhost.com:8080/* anfordert, sollte die Anforderung an den http-Server weitergeleitet werden, der Port 8008 der Loopback-Schnittstelle überwacht. Dies ist der einfache Teil.

• Wenn ein Remote-Benutzer http: // myhost.com:8080/specialurl anfordert ...

  • Das Programm, das als Gateway auf Anwendungsebene fungiert, sollte in der Lage sein, die Verbindung zu einer verschlüsselten Sitzung zu aktualisieren ( ohne die Ports zu ändern ).

  • Nach dem Einrichten einer verschlüsselten Sitzung mit dem Remote-Browser sollte die Anforderung an das C-Programm weitergeleitet werden, das Port 8000 der Loopback-Schnittstelle überwacht

Meine Fragen sind :

1. Haben Sie jemals eine solche Lösung in einer Produktionsumgebung bereitgestellt? Wenn Sie haben...
2. Welches Produkt haben Sie als Anwendungsgateway verwendet?
3. Könnten Sie ein Konfigurationsbeispiel angeben?

Harte Einschränkungen :

• Ich habe keine Kontrolle über die Firewall und der einzige Port, über den ich externen Datenverkehr in den internen Server leiten kann, ist 8080. Die Portnummer ist irrelevant. Die Sache ist, dass auf Firewall-Ebene nur ein Port offen ist, der eingehende Daten weiterleitet Datenverkehr zum internen Server.
• Auf dem internen Server muss Linux ausgeführt werden (derzeit wird Debian Lenny ausgeführt).
• Remotebenutzer sollten lediglich einen aktuellen Webbrowser und eine Internetverbindung benötigen, um auf diesen Server zugreifen zu können. Dies bedeutet, dass die Weiterleitung von Reverse-Ports über SSH hier keine Option ist.
• Ich benötige ein Produkt, das in der Produktion getestet wurde und problemlos bereitgestellt werden kann. Ich möchte kein eigenes Anwendungsgateway entwickeln (wenn dies der Fall wäre, würde ich diese Frage wahrscheinlich bei Stack Overflow stellen, anstatt sie bei Server Fault zu stellen).

Weiche Einschränkungen :

• Ich möchte vermeiden, Apache als Anwendungsgateway zu verwenden (obwohl ich dazu bereit bin, wenn dies die einzig mögliche Wahl ist).
• Wenn möglich, sollte das Anwendungsgateway ein ausgereiftes Open-Source-Softwareprodukt sein.

Bisher getestete Produkte als Anwendungsgateways (ohne Erfolg)

• Nginx
• lighttpd
• Pfund

Relevante RFCs

• RFC2817 (... erklärt, wie der Upgrade-Mechanismus in HTTP / 1.1 verwendet wird, um Transport Layer Security (TLS) über eine vorhandene TCP-Verbindung zu initiieren. Dadurch kann ungesicherter und gesicherter HTTP-Verkehr denselben bekannten Port gemeinsam nutzen ...)
• RFC2818 (... beschreibt die Verwendung von TLS zum Sichern von HTTP-Verbindungen über das Internet. Derzeit wird HTTP über SSL (der Vorgänger von TLS) geschichtet, wobei gesicherter Verkehr von unsicherem Verkehr durch die Verwendung eines anderen Server-Ports unterschieden wird ... )

Ein Port, der sie alle regiert, zeigt, dass jemand ihn zumindest in der Java-Welt implementiert hat.

Haben Sie jemals eine solche Lösung in einer Produktionsumgebung bereitgestellt?

Ich habe es nicht - und ich würde es auch niemals empfehlen. Als Berater versuche ich meine Kunden zu ermutigen, standardisierte und bewährte Technologien einzusetzen. Kein System scheint diese RFCs richtig zu implementieren, außer in Randfällen - und das würde ich nicht vorschlagen oder unterstützen wollen.

Apache wird dir hier nicht helfen. Es kann nur auf HTTP- oder HTTPS-Verbindungen (nicht auf beide) an einem bestimmten Port warten.

Soweit ich weiß, gibt es kein "ausgereiftes Produkt", das diese Funktionalität implementiert. Lassen Sie sich von Ihrem Netzwerkadministrator ein weiteres Loch in die Firewall schlagen oder richten Sie einen VPN- oder SSH-Tunnel zu einem externen Endpunkt ein, an dem Sie mehrere Überwachungsports einrichten können.