Apache の AllowCONNECT と HTTPS の宛先ポート

Apache プロキシはポート 3128 で待ち受けています。クライアントは正常に到達しますが、ポート 8443 の HTTPS サービスは失敗します。プロキシの待ち受けポートを変えても、その違いはおそらく解決しません。

クライアントはまずプロキシのリスナーに接続します。次に、その CONNECT リクエスト が別の宛先ホストとポートを指定します。Apache は最初の接続を受け入れ、2 番目の操作を拒否することがあります。

AllowCONNECT を宛先ポリシーとして読む

Apache 2.4 では、mod_proxy_connect が受信した CONNECT リクエストを処理します。その AllowCONNECT ディレクティブが、それらのリクエストで利用できる宛先ポートを制御します。文書化されている既定値は 443 と 563 です。

AllowCONNECT 443 8443

この例はその 2 つの宛先ポートを選択します。既定の選択を置き換えるものであり、既定のポートをすべて黙って残したまま 8443 を追加するわけではありません。ディレクティブは該当するサーバーまたはバーチャルホストの設定で使用してください。

そのままにしておき、プロキシのクライアント認可ルール を維持します。許可された宛先ポートは、どのクライアントがサービスを使えるかを示すものではなく、必要とされる場合の宛先ホスト制限の代わりにもなりません。

リバースプロキシの例は別の問いに答える

Apache と HTTPS の検索結果は、固定のバックエンドへ転送する公開ウェブサイトをよく示します。その設定は、ブラウザーがフォワードプロキシに選択したウェブサイトへの CONNECT トンネルを開くよう求める方法ではありません。そのルーティングディレクティブをコピーしても、元のプロキシの問題は手つかずのまま残ることがあります。

障害を診断するときは、クライアントが到達したリスナー、要求された CONNECT の authority、プロキシの応答を記録します。CONNECT が成功し、その後に TLS が失敗するなら、宛先ポートの許可はすでに役割を果たしています。AllowCONNECT を何度も広げるのではなく、TLS の失敗 に進んでください。