単一のポートを介して暗号化および非暗号化http接続を処理する方法
次の図をご覧ください。
これはどのように機能する必要がありますか？
リモートがhttp：// myhost.com：8080/*を要求する場合、要求はループバックインターフェイスのポート8008でリッスンするhttpサーバーに転送される必要があります。これは簡単な部分です。
リモートユーザーがhttp：// myhost.com：8080/specialurl ..を要求したとき.
アプリケーションレベルゲートウェイとして機能するプログラムは、暗号化されたセッションへの接続をアップグレードできる必要があります（ポートを変更せずに）
リモートブラウザとの暗号化されたセッションを確立した後、ループバックインターフェイスのポート8000でリッスンするCプログラムに要求を転送する必要があります
私の質問は：
- このようなソリューションを実稼働環境にデプロイしたことがありますか？あなたが持っている場合...
- アプリケーションゲートウェイとして機能するためにどの製品を使用しましたか？
- 構成例を教えてください。
厳しい制限：
- 私はファイアウォールを制御できず、外部トラフィックを内部サーバーに取り込むことができる唯一のポートは8080です。ポート番号は関係ありません。 、重要なのは、ファイアウォールレベルで開いているポートが1つだけで、着信トラフィックを内部サーバーに転送することです。
- 内部サーバーはLinuxを実行している必要があります（現在はDebian Lennyを実行しています）
- リモートユーザーは、このサーバーにアクセスするために、現在のWebブラウザーとインターネット接続だけを必要とします。これは、SSHを介した逆ポート転送はここではオプションではないことを意味します。
- 実稼働環境でテストされ、簡単に展開できる製品が必要です。 私は自分のアプリケーションゲートウェイを開発するつもりはありません（もしそうなら、私は尋ねるのではなく、StackOverflowでこの質問をするでしょうサーバー障害時）。
ソフト制限：
- Apacheをアプリケーションゲートウェイとして配置することは避けたいと思います（ただし、それが唯一の可能な選択肢である場合は、そうするつもりです）。
- 可能であれば、アプリケーションゲートウェイは成熟したオープンソースソフトウェア製品である必要があります。
製品はアプリケーションゲートウェイまで試行されました（成功しませんでした）
- nginx
- lighttpd
- ポンド
関連するRFC
- RFC2817（...は、HTTP/1.1のアップグレードメカニズムを使用して、既存のTCP接続を介してトランスポート層セキュリティ（TLS）を開始する方法を説明しています。これにより、同じ既知のポートを共有するためのセキュリティで保護されていないHTTPトラフィック...）
- RFC2818（...は、TLSを使用してインターネット経由のHTTP接続を保護する方法を説明しています。現在の慣行では、HTTP over SSL（TLSの前身）を階層化して、保護されたトラフィックと安全でないトラフィックを区別しています。別のサーバーポートの使用...）
すべてを支配する1つのポート は、誰かが少なくともJavaの世界でそれを実装したことを示しています。
このようなソリューションを実稼働環境に展開したことがありますか？
私はしていません-また、それを行うことをお勧めしません。コンサルタントとして、私はクライアントに標準化された実績のあるテクノロジーを使用するように勧めています。 Edgeの場合を除いて、これらのRFCを適切に実装しているシステムはないようです。これは、私が提案またはサポートしたいことではありません。
Apacheはここでは役に立ちません。特定のポートでHTTPまたはHTTPS接続（両方ではない）のみをリッスンできます。
私の知る限り、この機能を実装する「成熟した製品」はありません。ネットワーク管理者にファイアウォールに別の穴を開けてもらうか、複数のリスニングポートを設定できる外部エンドポイントへのVPNまたはSSHトンネルを設定してください。