fragen stichworte

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

Bitte schauen Sie sich das folgende Diagramm an.

alt text

Wie soll das funktionieren?

  • Wenn eine Remote-Station http://myhost.com:8080/* anfordert, sollte die Anfrage an den http-Server weitergeleitet werden, der an Port 8008 der Loopback-Schnittstelle wartet. Dies ist der einfache Teil.

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

    anfordert
    • Das als Application-Level-Gateway fungierende Programm sollte in der Lage sein, die Verbindung zu einer verschlüsselten Sitzung zu aktualisieren (, ohne die Ports zu ändern)

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

    • überwacht wird

Meine Fragen sind:

  1. Haben Sie jemals eine solche Lösung in einer Produktionsumgebung bereitgestellt? Wenn Sie haben ...
  2. Mit welchem ​​Produkt haben Sie als Application Gateway gearbeitet?
  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 auf dem internen Server erhalten kann, ist 8080. Die Portnummer ist irrelevant, die Sache ist, dass es nur einen gibt Ein Port ist auf der Firewall-Ebene offen, der eingehenden Datenverkehr an den internen Server weiterleitet.
  • Auf dem internen Server muss Linux ausgeführt werden (derzeit wird Debian Lenny ausgeführt)
  • Remote-Benutzer sollten für den Zugriff auf diesen Server nur einen aktuellen Webbrowser und eine Internetverbindung benötigen. Das bedeutet, dass die umgekehrte Portweiterleitung über SSH hier nicht möglich ist.
  • Ich brauche ein Produkt, das in der Produktion getestet wurde und das problemlos bereitgestellt werden kann. Ich bin nicht auf der Suche nach einem eigenen Anwendungs-Gateway. (Wenn dies der Fall wäre, würde ich diese Frage wahrscheinlich bei Stack Overflow stellen, anstatt bei Server Fault).

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 Anwendungs-Gateway ein ausgereiftes Open-Source-Softwareprodukt sein.

Produkte, die bisher als Anwendungs-Gateways (ohne Erfolg)

ausprobiert wurden
  • nginx
  • lighttpd
  • Pfund

Relevante RFCs

  • In RFC2817 (... wird erläutert, wie Sie mithilfe des Upgrade-Mechanismus in HTTP/1.1 Transport Layer Security (TLS) über eine vorhandene TCP-Verbindung initiieren können. Auf diese Weise kann ungesicherter und gesicherter HTTP-Datenverkehr denselben bekannten Port verwenden ...)
  • RFC2818 (... beschreibt, wie TLS zum Sichern von HTTP-Verbindungen über das Internet verwendet wird. Derzeit wird HTTP über SSL geschichtet (der Vorgänger von TLS), wobei gesicherte Datenverkehr von unsicherem Datenverkehr durch die Verwendung von a unterschieden wird anderer Serverport ...)

antworten

Ein Port, um alle zu beherrschen, zeigt, dass jemand sie zumindest in der Java-Welt implementiert hat.

Have you ever deployed such a solution in a production environment?

habe ich nicht - auch würde ich niemals empfehlen, dass es gemacht wird. Als Berater versuche ich meine Kunden zu ermutigen, standardisierte und bewährte Technologien einzusetzen. Kein System scheint diese RFCs mit Ausnahme von Randfällen richtig zu implementieren - und das wäre nichts, was ich vorschlagen oder unterstützen möchte.

Apache hilft dir hier nicht. Es kann nur HTTP- oder HTTPS-Verbindungen (nicht beide) an einem bestimmten Port überwachen.

Meines Wissens gibt es kein "ausgereiftes Produkt", das diese Funktionalität implementiert. Bitten Sie Ihren Netzwerkadministrator, Ihnen eine weitere Lücke in der Firewall zu schlagen, oder richten Sie einen VPN- oder SSH-Tunnel für einen externen Endpunkt ein, an dem Sie mehrere Überwachungsports einrichten können.