1台のホームサーバーで、2つのリバースプロキシがポート80と443を共有できますか？

同じIPとプロトコルを同時に共有することはできません。ただし、一方のプロキシを単一のフロントドアとして、選択したトラフィックをもう一方へ転送する場合、またはそれぞれが異なるIPにバインドする場合を除きます。

1台のマシン上で、2つのプロキシコンテナが別々のアプリスタック用にホストの80番ポートと443番ポートを公開すると、これは実際の互換性の問題になります。まずは使い捨て可能なパスまたはアカウントから始め、以前の動作状態を利用できるようにしておき、単発の接続テストではなく、元のワークロードに基づいて設計を評価してください。

共有リソースの所有者を特定する

サポートされる構成は、IPとポートの組み合わせごとに1つのリスナーを置き、その背後でルーティングする構成です。競合する構成は、同じソケットをめぐって2つの独立したリスナーが競合する構成です。いずれかを変更する前に、バージョン、識別情報、アドレス、マウントパス、権限、現在確認できる状態を記録してください。

関連するソケットのバインド規則が、最初の互換性の境界を定めます。これを使って主張の範囲を限定し、文書化された機能が設計全体の動作を証明するものと見なすのではなく、この特定のホームサーバーで同じ動作を検証してください。

テスト前に判定基準を書いておきます。成功とは、意図したフロントプロキシだけが各パブリックソケットを所有し、すべてのホスト名が期待どおりの証明書で正しいアップストリームに到達することです。失敗には、起動時にアドレス使用中と報告されること、トラフィックが誤ったプロキシに到達すること、TLSが別サイトの証明書で終端されることが含まれます。これにより、部分的な接続やコマンドの正常終了をエンドツーエンドの互換性と誤解するのを防げます。

一度に1つのリスナーまたはルートだけを変更する

制御された識別要因を1つだけ使います。現在のリスナーを一覧表示し、各プロキシを異なるテストIPにバインドするか、一方をもう一方の背後に移動してから、Host、SNI、WebSocket、証明書のルーティングをテストします。変更したコンポーネントだけが考えられる原因になるよう、クライアント、ワークロード、ファイルセット、アカウント、タイミングを一定に保ってください。

公開ポートの動作を使って、この経路で重要となる2つ目の観測結果を選びます。トランザクションの両側を記録してください。リゾルバーまたはルート、ネゴシエートされたプロトコル、プロセスID、終了ステータス、遅延、転送バイト数、復旧イベントなどです。

タイトルに示されたライフサイクルイベント（再作成、再接続、再マウント、再起動、フェイルオーバー、またはクライアント変更）の後にテストを繰り返してください。古いソケット、キャッシュ、または認証情報が有効な間だけ動作する設計は、合格していません。

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

観測可能なルーティングの証拠で判断する

合格: 意図したフロントプロキシだけが各パブリックソケットを所有し、すべてのホスト名が期待どおりの証明書で正しいアップストリームに到達する。この状態を生み出した正確なバージョンとトポロジーを保存してください。結論はプロトコルのあらゆる実装ではなく、その条件に適用されるためです。

失敗: 起動時にアドレス使用中と報告される、トラフィックが誤ったプロキシに到達する、またはTLSが別サイトの証明書で終端される。どちらか一方の主要な分岐に原因があると断定する前に、DNS、MTU、識別情報、ファイアウォールの状態、ストレージ遅延、キャッシュされたセッションなどの共有依存関係を確認してください。

例外: 2つ目のパブリックバインドを停止し、最後に動作していたリスナーを復元して、1つのフロントドアまたは個別のホストアドレスを選択してください。どの境界が失敗したのかを再現可能な観測で特定するまでは、権限を拡大したり、ソースデータを削除したり、通信のセキュリティを弱めたり、動作中のストレージを置き換えたりしないでください。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

本番トラフィックが戻る前に分離を再確認する

観測された分岐に対応するアクションだけを適用し、その後、元のワークロードを再実行します。2回の関連するライフサイクルサイクルと想定される同時負荷の下で、意図したフロントプロキシだけが各パブリックソケットを所有し、すべてのホスト名が期待どおりの証明書で正しいアップストリームに到達する場合にのみ、その設計を採用してください。

専用プロキシネットワークを使って、最も近い依存ワークフローを検証します。新しい設計が有効な間も、そのアクセス、タイミング、復旧動作が変わらないことが必要です。

起動時にアドレス使用中と報告される、トラフィックが誤ったプロキシに到達する、またはTLSが別サイトの証明書で終端される場合は、停止して保存済みの状態に戻してください。別の回避策を追加するのではなく、タイムスタンプ、正確なバージョン、ルートまたはマウントの証拠、最小限の再現手順を添えてエスカレーションしてください。

リバースプロキシのDNSオーバーライドと結果を照合し、リスクが別のネットワーク、識別情報、バックアップ、またはストレージ層へ単に移されていないことを確認してください。

2つのリバースプロキシによるポート所有について、条件付きの答えは冒頭の判断であり、無条件の「はい」ではありません。観測可能な合格状態が受け入れの基準線であり、失敗状態がロールバックの基準線です。

FAQ

SO_REUSEPORTで、無関係なプロキシが443番ポートを共有できますか？

独立したプロキシによる安全なホスト名ルーティング設計にはなりません。1つのTLSフロントドアを使うか、別々のIPを使用してください。

一方のプロキシから2つ目のプロキシへTLSパススルーできますか？

SNIに基づいてルーティングし、下流のプロキシがそのホスト名の証明書終端を担当する場合は可能です。

IPv4とIPv6のリスナーは競合しますか？

デュアルスタックソケットの動作とバインドアドレスによっては競合する可能性があります。両方のプロトコルファミリーを明示的に確認してください。