Docker の VPN ポートマッピングが OpenVPN に届かない理由

コンテナが UDP 1195 で待ち受け、ホストが 1194 を公開していても、マッピングがそう告げている限り正しい設定です。数値は翻訳表を作ります。クライアントはホスト側ポートに接続し、Docker は宛先をコンテナ側ポートに書き換え、OpenVPN は自身の設定が示すポートで応答します。どれか一つの環でずれていれば、ファイアウォールに見える無言の失敗が起きます。証明書と暗号はその下流にあり、これを修復できません。

認証に関わる変更を行う前に、パケットを一つ、クライアントからプロセスまで追跡してください。

三つの数値、一つの接続

三つの数値とは、クライアントが使うリモートの宛先、ホスト上の公開マッピング、コンテナ内のリスナーです。これらは一致する必要はありませんが、連鎖している必要があります。一致しているのがたまたま一般的なだけの特殊ケースなので、ずれは一度書くと簡単に生まれ、後から見つけるのが難しくなります。

デバッグの前に、連鎖を一行に書いてください。クライアントのアドレスとポート、ホストのマッピング、コンテナのリスナー、トランスポートです。連鎖の欠陥は、異なる値で二度現れる数値として見えます。

短い記法が実際に語ること

短い形式では、左辺がホスト側ポート、右辺がコンテナ側ポートで、スラッシュの接尾辞がトランスポートを選びます。接尾辞を省くと Docker はマッピングを TCP として扱うため、プロトコルなしのマッピングの後ろにいる UDP リスナーには誰も到達できません。この既定値は文書化されていますが、数値を合わせて完了とした人を今も驚かせます。

長い形式はバインドアドレスとプロトコルを明示的に固定するので、ネットワークに面するものでは余分な行の価値があります。公開マッピングを作ったファイルを信用するのではなく、公開マッピングを読み返してください。

ports:
  - 1194:1195/udp

パケットが止まりうる場所

要求は Docker の手前、Docker の中、またはリスナーで落ちます。Docker の手前にはクラウドのファイアウォールや独自に転送するルーターがあり、その機器にはホスト側に向くポートと正しいトランスポートが必要です。Docker の中では、誤ったコンテナ側ポートへのマッピングが閉じたソケットへ転送します。

次にリスナーです。OpenVPN の設定はポートとプロトコルを指定し、コンテナ内の別のポートに来たクライアントは何にも届きません。UDP サービスを TCP で試しても、どの段階でも何も証明できません。クライアントが使うトランスポートを使ってください。

バインドアドレスが到達性を決める

ループバックに束縛した公開マッピングはホストからしか到達できず、全インターフェースに束縛したものはファイアウォールが許す場所から到達できます。アドレスを省いた Compose ファイルでは両者は同じに見え、Docker の既定は広い方です。

配備がどちらの公開を意図するかを決め、明示的に書いてください。ループバック経由で接続する内部テストと、接続できない遠隔クライアントは、同じコンテナの正確な説明になり得ます。

実行中の状態を読む

実行中のコンテナの実際のマッピングと、そのネットワーク名前空間のリスナーを調べます。コンテナ起動後に Compose ファイルが編集されていたり、イメージのメタデータが公開せずにポートを宣言していたり、二つ目のコンテナが既にホスト側ポートを握っていることがあります。イメージでポートを宣言することは公開ではなく、どちらも待ち受けと同じではありません。

三つの異なる状態、三つの異なるコマンド、そして最後だけが OpenVPN に関わります。

マッピングが正しくなった後

パケットが OpenVPN に届いたら、そのログが TLS と認証について読む場所です。決して届かなかったパケットを直すために証明書を再生成するのは、二つ目の変数を増やす無駄な作業です。マッピングのメモをクライアントプロファイルの隣に置き、次の人が三つの数値を再発見するのではなく一行を読むようにしてください。ホスト側で一度パケットを取得すれば、三つの環のどれが誤りかが決まり、証明書の再生成より安く済みます。

ここで述べたのはブリッジ公開の場合です。ホストネットワークやルーティングされたコンテナアドレスは翻訳を飛ばすため、そうした設計では同じ数値が別の意味を持ちます。