Windows コンテナと VPN: ローカルネットワークが切れる理由
Windows コンテナはホストのルートテーブルを借りるため、ローカルサブネットを遮断する VPN はコンテナのプレフィックスも巻き込みます。Linux モードは別の経路をたどります。
ノート PC 一台で VPN クライアントを一本接続した状態では、Linux コンテナ同士は通信を続け、Windows コンテナは止まります。変数はイメージではなく、パケットがホストへ入る経路です。既定のネットワーク上の Windows コンテナはホストのルートテーブルと変換を借りるため、ホストのルーティングを変えるポリシーはコンテナにも及びます。何かを再インストールする前に、ルート検索でそれを確認してください。
Windows コンテナのパケットがホストへ入る場所
既定の nat ネットワーク上のコンテナは、Host Networking Service のプレフィックスからアドレスを取得し、通常は 172.16.0.0/12 の内側のどこかになり、仮想アダプターを通じてホストに到達します。ホストがそのプレフィックスのルートを所有し、現在有効なアダプターに向けてトラフィックを変換します。この経路の途中に別の仮想マシンはありません。
この設計が障害を機械的にしています。コンテナがパケットを送ると、ホストはコンテナのプレフィックスについてルート検索を行います。勝ったルートがパケットの行き先になり、コンテナ側に選択の余地はありません。
VPN クライアントがその経路に加える変更
企業向けクライアントは多くの場合、広い範囲のルートと、トンネルが有効な間はローカルサブネットへのアクセスを拒否するフィルターをインストールします。意図は防御的で、侵害されたローカルネットワークが保護されたマシンに届いてはならないというものです。副作用として、ホストからコンテナのプレフィックスへのルートはローカル NAT ネットワークではなくなります。
代わりに、検索はトンネルに一致し、パケットはそのコンテナアドレスを聞いたことのないゲートウェイに渡されます。Ping は失敗し、アプリケーションはタイムアウトし、VPN アイコンが光っているのにコンテナは壊れて見えます。接続中にホストのテーブルを見れば、競合するルートを確認できます。
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux コンテナの挙動が異なる理由
Linux エンジンはコンテナを軽量な仮想マシンの内側で実行し、そのマシンからの外向き接続はコンテナの代理としてホスト側のプロキシが開きます。ソケットを開始するのはホストなので、コンテナのプレフィックスに関する VPN のルールは同じようには適用されず、ワークロードはネットワークに届き続けます。
この違いは、Linux のレシピがそのまま持ち込めない理由でもあります。独自のトンネルが必要な Linux コンテナには TUN デバイスと NET_ADMIN 権限が与えられます。Windows コンテナはインターフェースをデバイスとして公開しないため、その手法に対応するものはこちら側にありません。
ルートを証明してから設計を選ぶ
証拠はコンテナからではなくホストから集めます（検索を行うのはホストだからです）：
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN が接続する前に一度、接続後に一度、ルート出力を実行します。二度目の出力でコンテナのプレフィックスがトンネルアダプターを指していれば、診断は完了しており、コンテナを再起動しても解決しません。
最初の選択肢はポリシーの判断です。ネットワークの所有者に、このデバイスでローカル LAN へのアクセスを許可できるか尋ねてください。多くの企業向けクライアントはそれを設定として公開していますが、意図的に引いた境界を弱めます。所有者と見直し日を記した文書化された例外として求めてください。誰も見直さないデバイスごとのトグルは、防御的なポリシーが静かに消えていく道です。
ポリシーを維持しなければならない場合は、ルートと戦うのではなくワークロードを移します。明示的なサブネットとゲートウェイを持つ透過ネットワークはコンテナをローカルリンクに置き、Linux のワークロードは仮想マシンのプロキシの背後で動き、独自のクライアントを持つ別の仮想マシン は独自のポリシーを保ちます。どれか一つを意図的に選び、コンテナの内側から検証してください。ユーザーの要求はそこで生まれるからです。