ホストは IPsec ピアに届くが、Docker コンテナは届かない

Linux マシンからリモートホストへ ping を打つと応答があり、トンネルは動いている。隣のコンテナは相変わらずタイムアウトし、次に取る自然な行動は Docker の再起動だ。ブリッジネットワークのコンテナは通常、別の送信元アドレスで始まり、ホスト側アプリ自身の出口経路ではなく転送によってホストに入ってくるため、成功した試験が測っていたのは別のパケットだ。ポリシーベースの strongSwan トンネルでは、転送されたパケットが導入済みの IPsec ポリシーに一致しないとき、リモートサブネットへの普通のルートでは足りない。

以下の手順は一つの宛先と二つの送信元をたどり、まず状態を読み、それから手を入れる。

一つの宛先と二つの送信元から始める

まず IP で分かるサービスを選ぶ。DNS の切り分けと同時進行にしないためだ。三つの事実、つまりコンテナのブリッジプレフィックス、成功したホスト側リクエストの送信元アドレス、トンネルで折衝済みのローカルとリモートのトラフィックセレクタを記録する。

次に、失敗したリクエストをコンテナの中から再現し、実際に使われている送信元を捕まえる。そのアドレスがローカルセレクタで覆われていないなら結果はもう分かっており、コンテナを作り直しても変わらない。

Docker に触る前にポリシーを読む

読み取り専用のホスト側チェックは、ルーティングの判断、ポリシーデータベース、そして両者の間で選択を行うルールを対象にする。

ip rule show
ip route show table all
ip xfrm policy

ポリシー一覧はセレクタと方向を示し、鍵素材で埋まった IPsec 状態のダンプは要らないので、チケットに貼っても安全だ。ホストのアドレスを覆い、ブリッジプレフィックスは覆わないローカルセレクタを探し、重なりも確認する。リモートの宛先をローカル扱いするコンテナルートは、期待する転送パケットを決して生み出さず、トンネルが濡れ衣を着せられる。この一覧はコンテナの送信元アドレスの隣に残しておき、二つそろって初めて比較になる。

コンテナのプレフィックスが無いなら、他の何かを編集する前にいったん止めてアーキテクチャを決める。以降の手順は、どの送信元アドレスを線路上に出すか合意済みだという前提で進む。

フィルタと変換を順に確認する

Docker の Linux ブリッジファイアウォールは、IPsec とは独立に転送を止めうる。iptables バックエンドなら FORWARD チェーンと DOCKER-USER の判定を見るが、先に結論があると後から足したルールが一度も実行されないことがある点に注意する。nftables バックエンドは統合のされ方が違うので、iptables の例がそう名付けたからという理由だけで DOCKER-USER チェーンを作らず、デーモンが実際にどちらのバックエンドを使っているかを確認する。

次に送信元の変換を確認する。広い MASQUERADE ルールは、以前 IPsec セレクタに一致していたパケットを、もう一致しないパケットに変えてしまい、故障はルーティング問題そっくりに見える。strongSwan の転送ガイドが、すでにポリシーに一致している通信に対して、そうした変換の前に必要な NAT 除外を説明している。

その除外は、覆われていないコンテナの送信元をトンネルに足すためのものではない。設計にすでに収まっている通信だけを守るので、セレクタと戻り経路の論点を先に片づけ、そのうえで NAT とフィルタを答えに合わせる。除外のほうを広げ始めたなら、変えるべきはセレクタであって NAT ルールではない。

そのうえで、経路か変換かを決める

経路で通すコンテナサブネットは、両側のピアがそのサブネットを受け入れ、リモート側にそこへの戻り経路があることを要求するので、多くの場合で両端のセレクタ変更と、遠い側の所有者との会話が必要になる。意図して変換する設計なら、代わりに、関連するルックアップ段階でポリシーが覆うアドレスを提示しなければならず、多くの場合それは既定の MASQUERADE ではなく狭く文書化されたルールを意味する。

どちらの配置も、ホストの動いているトンネルから自動的に導けるものではなく、どちらを選ぶかは所有者のいる設計判断だ。選んだ方を書き残さないと、次のエンジニアがファイアウォールのカウンタから再導出する。

ハイブリッドな故障、つまりルール集合の半分だけが変換された状態では、成功が目的ポートに左右され、ネットワークの性質とは無関係に断続することにも注意する。

新しい接続で検証し、再起動では検証しない

新しいアプリケーション接続を使い、範囲の狭いファイアウォールカウンタとリモートの受信側を同時に見るので、観察のたびに出所がある。Docker の再起動はルール状態を変えうるしワークロードも乱すので、得ようとしていたきれいな信号を自分で捨てることになる。

長く残る成果は、示せる四つの文だ。コンテナの送信元、一致する保護経路、許可された転送、そして戻ってくる応答の四つがそろえば、コンテナはホストと同じ理由でピアに届いている。