コンテナネットワーク（5種類）設定コマンドと使い方

Docker/LXDなどのコンテナ技術には、コンテナをネットワーク上にどう見せるかによって複数の接続方式があります。方式ごとに「独立したIPを持てるか」「ホストOSのMACアドレスを使うか」「LAN内の他機器から直接見えるか」が異なり、用途に応じた使い分けが必要です。本ページでは代表的な5種類を、設定コマンドと合わせて整理します。

本ページの位置づけについて

本ページはコンテナネットワークの技術リファレンス（学習ノート）です。特定のサーバー上で常時稼働している構成を記録したものではなく、必要に応じて選択・構築するための手順集としてご活用ください。なお、自宅ラボの内部管理基盤（AlmaLinux 9）ではDockerではなくPodmanを使用しているため、末尾に簡単な対応関係も補足しています。

1. 5方式の全体比較

まず全体像として、5つの方式がどのレイヤーで動作し、どんな特徴を持つかを一覧にします。詳細な設定コマンドは次章以降で解説します。

方式	レイヤー	独立IP	ホストと同一LAN	主な用途
1. NAT型ブリッジ	L3（NAT）	○（コンテナ専用の仮想セグメント）	×（ポート転送経由）	最も標準的。単一ホストでの一般的なWebサーバー運用等
2. 物理共有ブリッジ（br0）	L2	○（LANと同一セグメント）	○	LXD/KVMの仮想マシンをLANに直接参加させたい場合
3. Macvlan	L2	○（LANと同一セグメント）	○	br0を作らずに複数コンテナへLAN内IPを直接付与したい場合
4. IPvlan（L2モード）	L2/L3	○（LANと同一セグメント）	○	スイッチのMACアドレス制限や無線LAN環境でMacvlanが使えない場合
5. ホストネットワーク	なし（共有）	×（ホストと同一IP）	○	NATのオーバーヘッドを避けたい高速通信・監視系ツール等

前ページのSoftEther L2ブリッジ VPN全構築で解説した「L2ブリッジ」と「L3（NAT）」の考え方は、コンテナのネットワーク方式にもそのまま当てはまります。方式2〜4は自宅LANと同一セグメントに参加する「L2的」な方式、方式1は独立したセグメントとNATで繋がる「L3的」な方式です。

2. NAT型ブリッジ（Default/User-Defined Bridge）

コンテナ用に独立したプライベートIPを割り当て、ホストOSを介して外部と通信（NAT）する、最も標準的な方法です。Dockerのデフォルトのネットワーク方式でもあります。

1. 独自のブリッジネットワーク作成

# 独自のブリッジネットワーク「my_bridge」を作成
docker network create --driver bridge my_bridge

2. コンテナの起動（ポートフォワーディング指定）

外部のPCからアクセスできるよう、ホストのポート（例: 8080）とコンテナのポート（例: 80）を紐付けます。

docker run -d \
  --name web-nat \
  --network my_bridge \
  -p 8080:80 \
  nginx

3. 確認コマンド

コンテナにホストとは異なるプライベートIP（172.18.0.x 等、Docker既定のブリッジセグメント）が割り当てられていることを確認します。

docker inspect web-nat | grep IPAddress

3. 物理共有ブリッジ（L2ブリッジ型：br0）

ホストOSの物理NICを仮想スイッチ（ブリッジ）化し、コンテナや仮想マシンを物理LANに直接接続します。LXDやKVMで一般的な方式です。

1. ホスト側（Ubuntu/Netplan）でのブリッジ作成例

/etc/netplan/01-netcfg.yaml などの設定ファイルを編集します。

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
  bridges:
    br0:
      interfaces: [eth0]
      dhcp4: yes  # ホストOS自身のIPアドレス取得用

# 設定の反映
sudo netplan apply

2. LXDコンテナをこのブリッジに接続して起動する場合

lxc launch images:ubuntu/22.04 my-container
# コンテナのネットワークを br0 にバインド
lxc config device add my-container eth0 nic nictype=bridged parent=br0

br0の仕組みは前ページのVPN構築と同じ

SoftEther L2ブリッジ VPN全構築で構築したbr0も、考え方はここと同一です。物理NICと仮想インターフェース（VPNではtapデバイス、コンテナではLXDのvethペア）を同じ仮想スイッチbr0に参加させることで、LANと同一セグメントとして振る舞わせています。

4. Macvlan

物理ブリッジ（br0）を作らずに、物理NICから直接MACアドレスの異なる仮想NIC（サブインターフェース）を切り出し、LAN内の独立したIPを持たせる方式です。

1. DockerでのMacvlanネットワーク作成

docker network create -d macvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  --ip-range=192.168.1.192/27 \
  -o parent=eth0 \
  macvlan_net

2. コンテナの起動

docker run -d \
  --name web-macvlan \
  --network macvlan_net \
  --ip 192.168.1.200 \
  nginx

3. ホスト・コンテナ間通信の許可（ホスト側でのコマンド実行）

Macvlanはデフォルトで「ホストOS自身」と「Macvlanコンテナ」の間の通信ができない制約があります。ホスト側に専用のmacvlanインターフェースを追加することで通信できるようにします。

sudo ip link add macv-host link eth0 type macvlan mode bridge
sudo ip addr add 192.168.1.220/24 dev macv-host
sudo ip link set macv-host up
sudo ip route add 192.168.1.200 dev macv-host

5. IPvlan（L2モード）

Macvlanに似ていますが、物理NICのMACアドレスを共有しながら、異なるIPアドレスをコンテナに割り当てます。スイッチのMACアドレス制限対策や無線LAN環境で使われます。

1. DockerでのIPvlan（L2モード）作成

docker network create -d ipvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  ipvlan_net

2. コンテナの起動

docker run -d \
  --name web-ipvlan \
  --network ipvlan_net \
  --ip 192.168.1.201 \
  nginx

※IPvlanもMacvlanと同様、デフォルトではホスト・コンテナ間の通信制限があるため、同様のルート追加等の対策が必要です。

MacvlanとIPvlanの使い分け

見た目上の設定はほぼ同じですが、決定的な違いは「MACアドレスをコンテナごとに新しく作るか（Macvlan）、物理NICのMACアドレスを共有するか（IPvlan）」です。多くのスイッチ・無線LANアダプタは1つの物理ポートに大量のMACアドレスがぶら下がることを想定しておらず、MACアドレステーブル溢れや、無線LANのプロミスキャスモード非対応（SoftEther GUI設定のローカルブリッジでも同様の制約に触れています）により、Macvlanが使えないケースがあります。そのような環境ではMACアドレスを増やさないIPvlanを検討してください。

6. ホストネットワーク（Host Mode）

仮想化やアドレス変換を一切行わず、ホストOSのネットワークスタックを直接共有する方式です。設定がシンプルで、NATによるオーバーヘッドがないのが特長です。

1. コンテナの起動

docker run -d \
  --name web-host \
  --network host \
  nginx

2. 動作確認コマンド

ホストOSのポートが直接解放されていることを確認します（ポート指定 -p をしていなくても、ホストのIP:80でアクセス可能になります）。

ss -tulpn | grep :80

ポート競合に注意

Host Modeはホストとポート空間を完全に共有するため、ホストOS自身やほかのサービスがすでに同じポートを使っていると起動に失敗します。また、複数のHost Modeコンテナで同じポートを使うこともできません。1ホストに複数の同種サービスを立てる場合は、方式1（NAT型ブリッジ）で個別のポートに割り当てる方が安全です。

7. トラブルシューティング

症状	原因と対処
Macvlan/IPvlanコンテナへ、ホストOS自身から ping が通らない	仕様上の制約です。方式4・5の手順にある通り、ホスト側に専用のmacvlan/ipvlanインターフェースを追加し、ルートを通す必要があります。
Macvlanコンテナが作成したLAN内IPに、他の機器からアクセスできない	ルーターやスイッチのAPスキャン防止・MACアドレスフィルタリング機能が有効な場合、新しいMACアドレスの通信が弾かれることがあります。IPvlanへの切り替えを検討してください。
br0作成後、ホストOS自身がネットワークから切断される	netplanの設定でブリッジ化した物理NIC（`eth0`等）に直接IPを持たせたままにしていないか確認してください。IPは`br0`側に付与し、物理NIC側は`dhcp4: no`にする必要があります。
NAT型ブリッジ（方式1）でポートを公開したのに外部から繋がらない	ホストOS側のファイアウォール（ufw/firewalld）で、指定したホスト側ポート（例：8080/tcp）が許可されているか確認してください。

8. Podmanでの対応関係

自宅ラボの内部管理基盤（AlmaLinux 9）ではDockerではなくPodmanを使用しています。Podmanのコマンド体系はDockerとほぼ互換なので、本ページの方式1（NAT型ブリッジ）は次のように読み替えられます。

# Podmanでのブリッジネットワーク作成（Dockerとほぼ同じ書式）
podman network create my_bridge

# コンテナの起動
podman run -d --name web-nat --network my_bridge -p 8080:80 nginx

Macvlan/IPvlanについてもPodmanは同様のドライバーオプションをサポートしていますが、rootless（非root）で実行する場合はslirp4netnsやpastaといった別方式のネットワークスタックが使われ、Macvlan/IPvlanのようなホストNIC直結の方式はroot権限での実行（またはネットワーク管理の委譲設定）が前提になる点がDockerと異なります。Quadlet（systemd連携）で運用する場合も、ネットワークの考え方自体は本ページの5分類がそのまま基礎になります。

Ubuntu 24.04 LTS 一覧へ戻る

コンテナを「どう見せるか」の5つの選択肢