VPNコンテナのネットワークを共有する：DNSはどうなるのか

VPNコンテナのネットワークネームスペースを共有すると、アプリケーションにトンネルのインターフェースとルートが渡されます。ただし トンネルのリゾルバーは渡されず、ホスト上の何かと統合されたコピーも渡されません。このずれは、公開名は解決できて内部名は解決できず、失敗するアプリは実際にそうであるように間違ったDNSサーバーを使っているように見える、非常に具体的な障害を生みます。修復は通常、診断が示すより小さく済みます。

ステップ 1: ホストではなくアプリからテストする

問題のあるコンテナの中で、ホストでもブラウザでもなく検索を実行します。 docker exec app-container getent hosts db.internal が、このプロセスのリゾルバーが何を返すかという、重要な唯一の問いに答えます。

ホストが名前を解決できてコンテナができないなら、障害を見つけたことになります。この後のすべては、サポートされた修正方法を選ぶことです。

ステップ 2: ランタイムがサポートするモデルを読む

Dockerのネットワークドキュメント には、別のコンテナのネットワークモードを共有するコンテナのDNSフラグに関する制限が記されています。Composeでは network_mode: service:vpn がアプリをVPNコンテナのネームスペースに結びつけ、サービスごとの dns 設定は通常のサービスのようには動作しません。 得られる解決結果は、共有ネームスペースが持っているものです。

ユーザー定義のブリッジネットワークも、Dockerの組み込みDNSをデフォルトのブリッジとは違う形で使います。そのため、動作するブリッジの例からコピーした dns 節が、共有スタックではまったく何もしないことがあります。節をコピーする前に構成を確認してください。

ループバックアドレスは常に該当するネットワークコンテキストを指します。共有ネームスペースの中では、127.0.0.1 はホストのリゾルバーではありません。

ステップ 3: 問い合わせをその受け手まで追う

独自のリゾルバーを動かすアプリは編集したファイルを無視するため、アプリのリゾルバー設定を読み、次にアプリが同梱するアプリ固有の暗号化DNSを読みます。次に、選んだリゾルバーがVPNのルートとファイアウォールポリシーの下で到達可能かを確認します。トンネルの向こう側にあるリゾルバーアドレスは、ネームスペースにそこへのルートがなければ役に立ちません。ファイルを編集する前に受け手を確認してください。

ブラウザのIP確認ページでは、名前の問い合わせがどこへ行ったかはわかりません。HTTP接続がどこへ行ったかを示すだけです。

ステップ 4: 二つの障害クラスを別々に直す

公開名は動くのにサービス名が失敗するなら、問題はコンテナネットワーク内部のサービス検出であり、公開リゾルバーの一覧ではありません。公開DNSアドレスをすべて変えても、ネットワークの検出機構が求められたことのないレコードは作られません。

両方のクラスが失敗するなら、リゾルバーへの到達性から始めます。片方だけなら、検出機構から始めます。二つは所有者が異なるため、一つの修復で両方を覆うことはありません。

ステップ 5: 再作成後に再テストする

ランタイムがサポートする仕組みで構成を変え、実行中のコンテナ内のファイルを編集するのではなくコンテナを再作成します。新しいプライベート名、新しい公開名、検索に続くアプリのリクエストをテストします。/etc/resolv.conf コンテナ内の編集は再作成で消え、直っていないのに直ったと錯覚させます。

共有ネットワーク定義のそばに、リゾルバーの所有者と想定されるネームスペースを記録します。次の人が両方を必要とします。