Linux環境でのネットワークブリッジの設定と確認方法について詳しく解説します。ネットワークブリッジは、複数のネットワークセグメントを一つのネットワークとして扱うための重要な技術です。特に仮想化環境やネットワークの高度な管理を行う際に必須の知識となります。本記事では、ネットワークブリッジの基本概念から、実際の設定手順、そして設定後の確認方法までを丁寧に説明します。Linuxを使用したネットワーク管理に興味がある方や、実際に環境を構築する予定のある方にとって、実践的なガイドとなることでしょう。
ネットワークブリッジの基本概念
Linuxブリッジは、MACアドレスを学習してEthernetフレームを転送するLayer 2の仮想スイッチです。物理NICや仮想マシンのTAPインターフェースをポートとして接続し、同じLANに参加させられます。異なるIPサブネット間をルーティングしたり、NATやDHCPサーバーを自動的に提供したりする機能ではありません。
単純なブリッジは接続先を同じブロードキャストドメインにまとめます。分離したいネットワークを不用意に接続しないでください。VLANを使う場合はVLANごとの所属・タグ設定が別途必要で、複数経路を接続する場合はL2ループとSTPの設計も重要です。
作業前の確認：管理接続を切断しないために
稼働中のNICをブリッジに組み込むとSSHが切れ、サーバーに戻れなくなることがあります。 本番・遠隔環境では、ローカルコンソールや管理用の別NIC、クラウド／ハイパーバイザーのコンソールなど、ネットワーク設定に依存しない復旧手段を先に確保します。既存の設定、IPアドレス、経路、DNS、接続プロファイルを保存し、復旧手順と保守時間を決めてください。
- 以下の
enp1s0は例です。eth0など実機の名前に読み替え、管理通信に使っていない検証用有線NICから始めます。 - ホスト自身がLANに参加する場合、通常はIPアドレス・DHCP・既定経路・DNSの設定を物理ポートではなく
br0側へ移します。IPv6のアドレスやRA/SLAACも含め、同じ設定を両方に残さないでください。単なるL2転送専用ブリッジにはホスト用IPアドレスが必須ではありません。 - NetworkManager、systemd-networkd、ifupdown、NetplanのどれがそのNICを管理しているかを確認します。Netplanは設定を生成する仕組みで、実際の管理は指定されたrendererが行います。同じNICを複数方式で二重管理しません。
- 一般的なWi-Fiクライアント接続は、有線NICと同じ方法では透明なブリッジにできません。クラウドや仮想基盤でも複数MACアドレスの転送が制限される場合があります。事前に環境の対応を確認します。
ip -br link
ip -br address
ip route
ip -6 route
# NetworkManagerを使っている場合
nmcli device status
nmcli connection show
# systemd-networkdを使っている場合
networkctl statusコマンドが存在しない場合は、その管理方式が未導入の可能性があります。インストールするだけで既存ネットワーク管理を切り替えず、OSの構成を確認してください。
必要なツール：現在はiproute2を基本にする
一時的な作成・確認には ip と bridge を使います。これらはiproute2系のツールであり、brctl を含む bridge-utils は必須ではありません。brctl は旧来の方式として残る環境がありますが、新しい設定では現在の管理ツールを優先します。
# Debian/Ubuntu系でip/bridgeが未導入の場合
sudo apt update
sudo apt install iproute2
# RHEL/Fedora系で未導入の場合
sudo dnf install iproute永続化には、すでに利用しているNetplan、NetworkManager等を使います。後述の手順は選択肢であり、すべてを続けて実行するものではありません。
一時的にブリッジを作成する（検証用）
次の例は、ネットワーク管理ソフトに管理されておらず、IP設定や管理接続にも使われていない専用の有線NICを使う検証向けです。既存の稼働NICのIP移行手順ではありません。ip による変更は通常、再起動後には残らず、管理ソフトの再適用で変更されることもあります。
ブリッジの作成とNICの追加
sudo ip link add name br0 type bridge
sudo ip link set dev br0 type bridge stp_state 1
sudo ip link set dev enp1s0 master br0
sudo ip link set dev enp1s0 up
sudo ip link set dev br0 upmaster br0 がNICをブリッジポートにする指定です。この例ではループ対策としてSTPを有効にしており、転送可能になるまで待ち時間が発生します。STPだけに頼って意図しない配線を接続しないでください。
作成結果の確認
ip -d link show br0
ip link show master br0
bridge link show
bridge fdb show br br0この段階ではホスト用IPアドレスを設定しておらず、DHCPも開始していません。ip link set ... up は管理上の有効化であり、ケーブル接続、IP取得、外部への疎通を保証しません。
検証用設定の片付け
次は、上の例で自分が作成した検証用br0だけを片付ける操作です。稼働中のブリッジには実行しません。もともとのNIC状態やIP設定は自動復元されないため、記録した状態に戻して確認します。
sudo ip link set dev enp1s0 nomaster
sudo ip link set dev br0 down
sudo ip link delete dev br0 type bridge永続化する方法を選ぶ
Ubuntu等：Netplanを使っている場合
Netplan環境では /etc/netplan/*.yaml の既存設定をバックアップし、対象NICの定義を整理してからブリッジを設定します。新しいファイルを追加するだけだと、既存ファイルのDHCPや静的アドレスが残って競合する場合があります。cloud-initや管理基盤が生成する設定も確認してください。
以下は renderer: networkd を使用中の環境で、DHCPv4をbr0に移す例です。IPv6はこの検証例では自動設定しない方針です。IPv6を利用する環境では、既存のRA・DHCPv6・静的アドレスと経路をbr0側に引き継ぐ設計に変更します。
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
dhcp4: false
dhcp6: false
accept-ra: false
link-local: []
bridges:
br0:
interfaces: [enp1s0]
dhcp4: true
dhcp6: false
accept-ra: false
link-local: []
parameters:
stp: trueYAMLはスペースでインデントし、既存のrendererを理由なく変更しません。設定ファイルは管理者のみが読み書きできる権限で保存します。IPアドレスがMACアドレスに紐付くDHCP予約では、ブリッジ化後に同じIPが得られるとは限りません。
sudo netplan generate
# 生成が成功し、復旧手段を確保している場合だけ試行
sudo netplan try --timeout 120generate はバックエンド用設定を生成・検査しますが、このコマンドだけで通信状態を切り替えるものではありません。try は確認されなければ戻す仕組みですが、仮想デバイス等に既知の制約があるため、完全な復旧保証ではありません。疎通を確認できないまま承認せず、取消・タイムアウト後は実際の状態とディスク上の設定を確認してください。対応しない構成ではコンソールから計画的に適用します。
RHEL/Fedora等：NetworkManagerを使っている場合
NetworkManager環境では nmcli で永続的な接続プロファイルを作成できます。以下はRHEL 9.4以降など、controller、port-type、connection.autoconnect-ports に対応する版の例です。旧版では master、slave-type、connection.autoconnect-slaves という名称を使うため、その版のマニュアルを確認します。
これは未使用の検証用NICで作る例です。既存の接続プロファイルを持つ稼働NICにそのまま追加せず、まず競合するプロファイルとIP移行方針を整理します。作成中に自動起動しないよう、一旦自動接続を無効にします。
sudo nmcli connection add type bridge con-name br0 ifname br0 connection.autoconnect no
sudo nmcli connection modify br0 ipv4.method auto ipv6.method disabled bridge.stp yes
sudo nmcli connection add type ethernet con-name br0-port1 ifname enp1s0 port-type bridge controller br0 connection.autoconnect no
sudo nmcli connection modify br0 connection.autoconnect-ports 1
# 保存した内容を確認（ここまでは意図的に起動していない）
nmcli connection show br0
nmcli connection show br0-port1この例もDHCPv4のみでIPv6を使わない検証構成です。IPv6が必要ならbr0に適切な方式を設定します。確認後、コンソール等から次を実行して対象接続を起動します。
sudo nmcli connection up br0
nmcli device status
ip -br address show br0疎通を検証できてから、起動時の自動接続を必要に応じて有効にします。同じNICを利用する旧プロファイルが自動接続しないよう、正しいプロファイルを特定して整理してください。
sudo nmcli connection modify br0 connection.autoconnect yes
sudo nmcli connection modify br0-port1 connection.autoconnect yesNetworkManagerを再起動して一括反映する必要はありません。RHEL 9では従来のifcfg形式は非推奨で、現在の新規プロファイルは通常keyfile形式になります。古い /etc/sysconfig/network-scripts/ifcfg-* と systemctl restart network を全環境共通の手順にしないでください。
Debianのifupdown等、別方式を使っている場合
/etc/network/interfaces はifupdownを使用中の環境の設定であり、Debian/Ubuntuすべてに共通するものではありません。既存のifupdown環境では、導入済みのブリッジ用拡張とその版の手順に従います。systemd-networkdを直接管理している環境では .netdev と .network の組み合わせを使います。Netplanが生成した /run/systemd/network/ のファイルを直接編集しても永続化になりません。
いずれの方法でも、物理ポートのIP設定をbr0へ移すこと、管理方式を一つにそろえること、変更前の状態へ戻せることが重要です。
既存のifupdownとbridge-utils拡張を使用している場合、元の記事のDHCP例は次のようにその環境に限定して使えます。対象NICの独立したDHCP・固定IP設定を残さず、IPv6の方針も別途確認します。これはNetplanやNetworkManagerの設定ファイルには記述しません。
auto br0
iface br0 inet dhcp
bridge_ports enp1s0
bridge_stp on既存のlo設定など、関係のない定義は残します。未起動のブリッジならifupで起動できますが、稼働NICの移行はコンソールから停止・再構成・確認を計画して行い、ネットワーク全体の再起動を一律の解決策にしません。
設定の適用後に確認すること
ip -d link show br0
ip link show master br0
bridge link show
bridge fdb show br br0
ip -br address show br0
ip -br address show enp1s0
ip route
ip -6 routeenp1s0にmaster br0があり、リンクのcarrierが上がっているか。STPの状態がforwardingになるまで待つ必要がないか。- ホスト用アドレスがbr0側にあり、物理ポート側に同じアドレスや不要なDHCP設定が残っていないか。L2専用ならIP未設定でも問題ありません。
- デフォルトルート、DNS、必要なIPv6経路が意図どおりか。systemd-resolvedを利用する場合は
resolvectl statusでも確認します。 - 同じLANの別端末やゲートウェイへの疎通、必要な名前解決、実際のアプリケーションへの接続を分けて確認する。ICMPが許可される宛先ならpingも使えますが、外部サイト1つへのping成功だけでブリッジ全体の正しさは証明できません。
- 仮想マシンを接続した場合はゲストからも確認し、保守時間に再起動後の永続化を確認する。再起動を唯一の復旧策にはしません。
トラブルシューティング
ブリッジやポートが見えない
インターフェース名、対象プロファイル、設定を読み込んでいる管理方式を確認します。br0を作っただけではNICは自動的に参加しません。誤ったサービスの再起動や、複数方式による重ねがけは避けます。
リンクは上がるがIPアドレスを取得できない
DHCPクライアントがbr0で動く設定か、DHCPサーバーに届くか、VLAN、MACアドレス制限、DHCP予約、スイッチのポート設定が一致するかを確認します。割り当てられていない静的IPを適当に追加すると重複の原因になります。固定IPが必要なら、管理者が指定した未使用アドレス・プレフィックス・ゲートウェイ・DNSをbr0に設定します。
通信が不安定、SSHが切れる
IPをポート側に残していないか、重複アドレス、L2ループ、STPの状態、MTU、物理リンクを確認します。接続不能なら確保したコンソールで、記録したプロファイルや設定ファイルを戻します。別セッションから到達できることを確認するまでは、唯一の管理セッションを閉じないでください。
ログを調べる
# 利用中の管理サービスに対応する方を確認
journalctl -u NetworkManager -b --no-pager
journalctl -u systemd-networkd -b --no-pager権限で読めない場合は管理者権限で確認します。ログを共有する際はIPアドレス、ホスト名などの必要のない環境情報を伏せます。ファイアウォールを無効にするのではなく、必要な通信と実際に拒否されている箇所を切り分けます。
応用例
仮想マシンを物理LANに接続する
仮想マシンの仮想NICを、ハイパーバイザー側で作成済みのbr0へ接続します。物理LANへつながるブリッジポートがあれば、ゲストをそのLANに直接参加させられます。ゲストにも固有のIP設定が必要で、ホストにIPを付けただけでゲストへのDHCP配布が始まるわけではありません。
コンテナ間の通信：Dockerのbridgeは別物として管理
Dockerのユーザー定義bridgeネットワークは、Dockerが管理する同一ホスト内のコンテナ用ネットワークです。次の例は前述のbr0に直接接続する操作ではなく、通常は物理LANと別サブネットで、外向き通信にはマスカレードが使われます。公開ポートやアクセス制御は別途確認します。
docker network create --driver bridge my_bridge
docker run -d --name my_container --network my_bridge my_imagemy_image は利用するイメージ名に置き換えます。コンテナを同じ my_bridge に接続すると通信できますが、Dockerが作成したブリッジを手作業で物理NICに結合しないでください。
VLANとネットワーク分離
VLANで分離する場合は、VLANごとに専用のブリッジを用意する方式か、VLAN filteringを有効にしたVLAN-aware bridge方式などを設計します。物理NIC enp1s0 と、そのVLANサブインターフェースを、説明なく同じbr0へ追加する手順は避けてください。タグ付き／タグなし通信、PVID、許可するVLAN、接続先スイッチを一致させます。
ブリッジを作るだけでネットワーク分離やファイアウォールが完成するわけではありません。ルーティングやNATが必要な構成とは目的を区別し、検証環境で設計してから展開します。
まとめ
Linuxブリッジは物理NICや仮想NICをLayer 2で接続する仕組みです。一時的な検証には ip・bridge、永続化には既存のNetplanやNetworkManager等を使い、管理方式を混在させないことが基本です。
最も重要なのは、IP・経路・DNSの設定先を整理し、SSH切断に備えて復旧手段を確保することです。作成コマンドの成功だけで終わらず、ポートの所属、アドレス、経路、DNS、ゲストと別端末からの疎通、再起動後の状態まで段階的に確認してください。
コメント