エンタープライズLinuxサーバーにおいて、安定した通信インフラの構築と迅速なトラブルシューティング能力は、インフラエンジニアに不可欠な基本スキルです。LinuCレベル2（201試験）の主題2.03「ネットワーク構成とトラブルシューティング」では、NetworkManager（nmcli）を用いた恒久的なネットワーク設定から、複数のNICを束ねるボンディングやチーミングによる冗長化、VLANやブリッジの設計、そしてssやtcpdumpを活用した障害解析まで、幅広い領域が出題されます。
特に記述式問題（コマ問）では、従来の非推奨コマンド（ifconfig、netstat、route）から最新のiproute2系ツール（ip、ss）への構文移行や、nmcli特有のオブジェクト指向的なコマンド体系（connectionとdeviceの区別、プロパティ変更構文）が頻出します。本記事では、AlmaLinux 9の実機検証ログに基づき、ネットワーク設定の確実な手順と障害切り分けの論理的アプローチを解説します。
- ホスト名: linuc-node01 (192.168.2.138)
- OS: AlmaLinux 9.8 (x86_64)
- カーネル: 5.14.0-570.el9.x86_64
- 主要ツール: NetworkManager 1.48 (nmcli) / iproute2 6.2 (ip, ss) / tcpdump 4.99
| 公式試験の必須出題範囲 | 主題2.03.1〜2.03.3（基本ネットワーク構成・nmcli・NICボンディング・VLAN・tcpdump・ss・ネットワーク障害切り分け） |
|---|---|
| 現場で役立つ実務拡張 | NetworkManager CLI（nmcli）による非対話型スクリプティング自動化、チーミング（Team）とのアーキテクチャ比較 |
目次
1. NetworkManagerと基本ネットワーク設定（nmcli vs ipコマンド）
RHEL系Linuxにおける標準ネットワーク管理デーモンがNetworkManagerです。CUI環境では、nmcli（NetworkManager Command Line Interface）を用いてすべての設定と状態監視を行います。
1.1 nmcliによる接続（Connection）とデバイス（Device）の概念
nmcliを理解するうえで最も重要なのは、「デバイス（Device）」と「接続（Connection）」の分離設計です。
- デバイス（Device）:
eth0やens192など、カーネルが認識している物理的・仮想的なネットワークインターフェース実体。 - 接続（Connection）: IPアドレス、サブネットマスク、ゲートウェイ、DNS設定などをまとめた設定プロファイル。1つのデバイスに対して複数の接続プロファイルを作成できますが、同時にアクティブにできる接続は1デバイスにつき1つです。
実機でそれぞれの状態を確認します。
# デバイス状態の確認
$ nmcli device status
DEVICE TYPE STATE CONNECTION
eth0 ethernet 接続済み eth0
lo loopback 接続済み (外部) lo
# 接続プロファイル一覧の確認
$ nmcli connection show
NAME UUID TYPE DEVICE
eth0 8ac2d224-7d57-3454-9580-98e907fec0b0 ethernet eth0
lo 31e6a9b2-9706-46a8-91f5-2d5d54dfeb50 loopback lo 1.2 静的IPアドレス・デフォルトゲートウェイ・DNSの設定手順
サーバー用途では、DHCPではなく固定IPアドレス（静的設定）を付与するのが基本です。nmcli connection modifyコマンドを用いて設定プロファイルを書き換えます。
# IPアドレス、サブネット、ゲートウェイの設定
$ sudo nmcli con mod eth0 ipv4.addresses 192.168.2.138/24
$ sudo nmcli con mod eth0 ipv4.gateway 192.168.2.1
# DNSサーバーの設定（複数指定時はスペース区切り）
$ sudo nmcli con mod eth0 ipv4.dns "192.168.2.1 8.8.8.8"
# 割当方式を静的（manual）に変更
$ sudo nmcli con mod eth0 ipv4.method manual
# 設定をインターフェースへ再反映
$ sudo nmcli con up eth0
接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/1)nmcli con modを実行しただけでは、設定ファイル（/etc/NetworkManager/system-connections/*.nmconnection）が更新されるのみで、稼働中のインターフェースには即座に反映されません。変更を即座に適用するには、必ずnmcli con up <接続名>を実行する必要があります。
1.3 ipコマンドによる一時的なインターフェース・ルート操作
一時的な検証やトラブル対応時、設定ファイルに保存せずメモリ上だけで即座にIP変更を行う場合はipコマンド（iproute2スイート）を使用します。再起動やNetworkManagerの再起動でリセットされます。
# IPアドレスの一覧確認（短縮形）
$ ip -br addr show
lo UNKNOWN 127.0.0.1/8
eth0 UP 192.168.2.138/24
# セカンダリIPアドレスの一時追加
$ sudo ip addr add 192.168.2.200/24 dev eth0
# 一時追加したIPアドレスの削除
$ sudo ip addr del 192.168.2.200/24 dev eth0
# インターフェースのリンクダウン / リンクアップ
$ sudo ip link set dev eth0 down
$ sudo ip link set dev eth0 up2. NICボンディング（Bonding）とチーミング（Teaming）による冗長化
サーバーのネットワーク信頼性を高めるために、複数の物理NICを論理的に1本のインターフェースとして集約する技術がボンディング（Bonding）です。高負荷環境での帯域拡張や、LANケーブル・スイッチ障害時のフェイルオーバーを実現します。
2.1 ボンディングモードの特性と選定基準
Linuxのボンディングドライバには、0から6までの7つのモードが存在します。試験対策としては、特に以下のモードの特徴を対比して理解することが重要です。
| モード番号 | モード名 | 動作概要 | 対向スイッチ側の設定 |
|---|---|---|---|
| mode 0 | balance-rr |
ラウンドロビン方式。各パケットを順次異なるNICから送信（帯域拡大・耐障害性） | 静的トランキング（EtherChannel等）が必要 |
| mode 1 | active-backup |
1台のみが稼働し他方は待機。稼働側故障時に瞬時に待機側へ切り替え（耐障害性） | 設定不要（通常のアクセスポートで動作可能） |
| mode 2 | balance-xor |
MACアドレス等のハッシュに基づき送信先ごとにNICを固定分散（帯域拡大・耐障害性） | 静的トランキングが必要 |
| mode 4 | 802.3ad (LACP) |
IEEE 802.3ad動的リンクアグリゲーション。制御プロトコル（LACP）を用いて自動集約 | LACP設定が必須 |
| mode 5 | balance-tlb |
送信負荷分散（Adaptive Transmit Load Balancing）。送信のみ各NICへ分散、受信は特定NIC | 設定不要 |
| mode 6 | balance-alb |
適応負荷分散（Adaptive Load Balancing）。ARPネゴシエーションを用いて送受信双方を分散 | 設定不要 |
2.2 nmcliによるボンディングインターフェースの構築手順
nmcliでボンディングを構築する際は、「ボンディング親（Master）接続の作成」と「子（Slave / Port）接続の追加」という2段階で設定します。
# 1. ボンディング親接続の作成（mode=active-backup, リンク監視周期100ms）
$ sudo nmcli con add type bond con-name bond0 ifname bond0 \
bond.options "mode=active-backup,miimon=100"
接続 'bond0' (98b5a502-88c3-4a55-8b07-3f44ec8f2d45) が正常に追加されました。
# 2. 静的IPアドレスを bond0 に設定
$ sudo nmcli con mod bond0 ipv4.addresses 192.168.2.150/24
$ sudo nmcli con mod bond0 ipv4.method manual
# 3. 物理NIC（eth1, eth2）を bond0 のスレーブとして登録
$ sudo nmcli con add type ethernet con-name bond0-port1 ifname eth1 master bond0
$ sudo nmcli con add type ethernet con-name bond0-port2 ifname eth2 master bond0
# 4. ボンディング親を有効化
$ sudo nmcli con up bond0
$ sudo nmcli con up bond0-port1
$ sudo nmcli con up bond0-port22.3 /proc/net/bonding/bond0 による稼働状態とフェイルオーバー監視
ボンディングが正常に動作しているか確認するには、カーネルが提供する/proc/net/bonding/<アレイ名>を直接参照します。
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v5.14.0-687.42.1.el9_8.x86_64
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Slave Interface: eth2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0Currently Active Slaveに現在パケット送受信を担っている物理NIC名（eth1）が表示され、MII Status: upでリンクが確立していることが分かります。eth1のリンクが切断されると、即座にeth2がActiveへと昇格します。
2.4 チーミング（teamd）との違いと runner 設定
ボンディングドライバがすべてカーネル空間で動作するのに対し、チーミング（Teaming）はユーザ空間の管理デーモンteamdとカーネルのteamドライバが協調して動作する後発アーキテクチャです。
動作モードは「runner」と呼ばれ、JSON形式のテキストで柔軟にポリシーを記述できる点が特徴です。主要なrunner名として、roundrobin、activebackup、loadbalance、lacpがあります。
# team0 の作成（runner に activebackup を指定）
$ sudo nmcli con add type team con-name team0 ifname team0 \
team.runner activebackup
# ポートの追加
$ sudo nmcli con add type ethernet con-name team0-port1 ifname eth1 master team0
$ sudo nmcli con add type ethernet con-name team0-port2 ifname eth2 master team0
# チーム状態の確認コマンド
$ sudo teamdctl team0 state3. VLAN（仮想LAN）とネットワークブリッジの構築
仮想化基盤や物理インフラのマルチテナント化において、ネットワークを論理的に分離・結合する技術がVLANとブリッジです。
3.1 IEEE 802.1Q VLANの仕組みとnmcliでのVLAN作成
IEEE 802.1Q規格に基づく**タグVLAN（Tagging VLAN）**では、イーサネットフレームヘッダ内に12ビットの「VLAN ID（VID: 1〜4094）」を付与することで、同一の物理スイッチ・ケーブル上で複数の論理ネットワークを混在通信させます。
# eth0 上に VLAN ID 100 のインターフェースを作成
$ sudo nmcli con add type vlan con-name vlan100 dev eth0 id 100 \
ipv4.addresses 10.0.100.10/24 ipv4.method manual
# 作成されたデバイスの確認（eth0.100 という名称で登録される）
$ ip -br link show eth0.100
eth0.100@eth0 UP 52:54:00:12:34:56 <BROADCAST,MULTICAST,UP,LOWER_UP> 3.2 Linuxブリッジ（bridge）の役割と仮想化環境での用途
Linuxブリッジ（Bridge）は、ホスト内部に構築される仮想的なレイヤー2スイッチです。KVM仮想マシンの仮想NIC（vnet）やコンテナの仮想イーサネット（veth）を物理NICと橋渡しし、外部ネットワークと直接L2通信させるために多用されます。
# ブリッジ親 br0 の作成
$ sudo nmcli con add type bridge con-name br0 ifname br0 \
ipv4.addresses 192.168.2.138/24 ipv4.gateway 192.168.2.1 \
ipv4.dns 192.168.2.1 ipv4.method manual
# 物理NIC（eth0）をブリッジのメンバーポートとして登録
$ sudo nmcli con add type ethernet con-name br0-port1 ifname eth0 master br0
# ブリッジの状態確認（bridge コマンド）
$ bridge link show4. ルーティングテーブルの管理と名前解決の仕組み
パケットが正しい宛先へ到達するためには、カーネルのルーティングテーブルが正確に維持されている必要があります。また、ホスト名からIPアドレスを引く名前解決（DNSリゾルバ）の設定もネットワーク運用の要です。
4.1 静的ルーティングの追加とポリシーベースルーティング
標準のデフォルトゲートウェイとは異なるサブネット（拠点間VPNや管理セグメントなど）へパケットを転送する場合、静的ルート（Static Route）を追加します。一時的な設定はip route、恒久的な設定はnmcliで行います。
# 現在のルーティングテーブルの確認
$ ip route show
default via 192.168.2.1 dev eth0 proto static metric 100
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.138 metric 100
# ip コマンドによる一時的な静的ルート追加（10.10.0.0/16 を 192.168.2.254 経由）
$ sudo ip route add 10.10.0.0/16 via 192.168.2.254 dev eth0
# nmcli による恒久的な静的ルート追加
$ sudo nmcli con mod eth0 +ipv4.routes "10.10.0.0/16 192.168.2.254"
$ sudo nmcli con up eth0metric（メトリック）値は、宛先への優先度を示します。複数のルートが存在する場合、メトリック値が最も小さいルートが最優先で採用されます。
4.2 /etc/resolv.conf と systemd-resolved による名前解決管理
名前解決の設定は、伝統的には設定ファイル/etc/resolv.confにDNSサーバーのアドレス（nameserver 192.168.2.1）を直接記述していました。現代のsystemd採用ディストリビューションでは、systemd-resolvedデーモンがローカルスタブリゾルバ（127.0.0.53）として動作し、キャッシュやDNSSEC検証を担う環境も増えています。
# /etc/resolv.conf の内容確認
$ cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.2.1
search localdomain
# systemd-resolved 稼働環境でのリゾルバ確認
$ resolvectl status5. ネットワーク障害切り分けツールとパケット解析
通信不能やパケット遅延が発生した際、闇雲に設定変更を試みるのではなく、OSI参照モデルの各レイヤー（物理 ➔ ネットワーク ➔ トランスポート ➔ アプリケーション）に沿って論理的に切り分けを行うことがトラブルシューティングの鉄則です。
5.1 ソケット統計の把握（netstat vs ssコマンドのオプション対比）
「ポートが開いているか」「どのプロセスがリッスンしているか」を調査する際、従来はnetstatが使われていましたが、現在はカーネル空間のソケット情報を高速・軽量に取得できるss（Socket Statistics）コマンドが標準です。主要なオプションはnetstatと共通しています。
$ sudo ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
udp UNCONN 0 0 127.0.0.1:323 0.0.0.0:* users:(("chronyd",pid=681,fd=5))
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=712,fd=3))
tcp LISTEN 0 128 [::]:22 [::]:* users:(("sshd",pid=712,fd=4)) | オプション | 対象・機能 | 実務・試験での要点 |
|---|---|---|
-t |
TCPソケット | TCPプロトコルに限定して表示 |
-u |
UDPソケット | UDPプロトコルに限定して表示 |
-l |
リッスン状態（LISTEN） | 接続待ち受け中のポートのみを表示 |
-p |
プロセス情報 | リッスンしているプロセス名とPIDを表示（root権限が必要） |
-n |
名前解決の無効化 | ポート番号やIPを名前解決せず数値（22、80等）で高速表示 |
-a |
全ソケット | 接続中（ESTABLISHED）を含む全ソケットを表示 |
5.2 疎通・経路調査（ping, traceroute, tracepath, mtr）
通信相手までの疎通確認と中継ルータの調査には、以下のツール群を用います。
- ping: ICMP ECHO要求を送信し、相手ノードが応答するか確認する基本ツール（
ping -c 4 192.168.2.1）。 - traceroute: IPヘッダのTTL（Time to Live）を1から順に増やしながら送信し、各ルータから返るICMP Time Exceeded（TTL超過）通知によって中継経路のIPをリスト化する（デフォルトはUDPパケット、
-IでICMP、-TでTCP SYNプローブ）。 - tracepath: root権限不要で実行可能。経路追跡と同時に**Path MTU（経路上でフラグメント化せずに送信できる最大パケット長）**を検出する。
- mtr:
pingの連続実行とtracerouteの経路追跡をリアルタイムに統合した動的ネットワーク診断ツール。パケットロス率の発生箇所特定に極めて有用。
5.3 tcpdumpによるパケットキャプチャとフィルタリング構文
プロトコルのハンドシェイク異常や不正な再送、ファイアウォールによるパケット破棄を物理レベルで突き止めるためのツールがtcpdumpです。
# eth0 を対象に、DNS（ポート53）のパケットをIP・ポート番号数値表示で5件キャプチャ
$ sudo tcpdump -i eth0 -nn port 53 -c 5
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
00:15:20.104212 IP 192.168.2.138.45210 > 192.168.2.1.53: 12345+ A? personalnote.tokyo. (36)
00:15:20.105189 IP 192.168.2.1.53 > 192.168.2.138.45210: 12345 1/0/0 A 160.251.150.11 (52)試験で問われる主要なtcpdumpオプションおよびフィルタ構文は以下のとおりです。
| 構文 / オプション | 機能・効果 | 記述例 |
|---|---|---|
-i <interface> |
キャプチャ対象のインターフェース指定 | tcpdump -i eth0（anyで全IF対象） |
-n / -nn |
IPアドレス / ポート番号の名前解決を抑止（高速化） | tcpdump -nn |
-c <count> |
指定パケット数をキャプチャしたら自動終了 | tcpdump -c 10 |
-w <file> |
パケットをpcap形式ファイルに保存 | tcpdump -w /tmp/dump.pcap |
-r <file> |
保存されたpcapファイルを読み込んで表示 | tcpdump -r /tmp/dump.pcap |
host <ip> |
特定IP宛てまたは発のパケットに限定 | tcpdump host 192.168.2.1 |
port <port> |
特定ポート番号に限定 | tcpdump port 80 or port 443 |
tcp[tcpflags] |
TCPフラグによる精密フィルタ | tcpdump "tcp[tcpflags] & tcp-syn != 0" |
6. LinuC 201試験（主題2.03）重要ポイント総整理
試験本番で問われる主要コマンドと構文上の盲点を整理します。
6.1 記述式（コマ問）頻出コマンド・オプション一覧
| コマンド | 主要構文・設定項目 | 役割・出題ポイント |
|---|---|---|
nmcli connection |
show, add, modify, up, down, delete |
接続プロファイルのライフサイクル管理 |
nmcli device |
status, show, connect, disconnect |
物理・仮想デバイスの状態確認と制御 |
ip link |
show, set <dev> up/down |
L2リンク層の状態確認と活性化・非活性化 |
ip addr |
show, add <ip/mask> dev <dev>, del |
L3 IPアドレスの付与・削除（一時設定） |
ip route |
show, add <net> via <gw> dev <dev> |
ルーティングテーブルの確認と静的ルート追加 |
ss |
-tulpn, -s |
ソケット統計・待ち受けポートの高速一覧表示 |
tcpdump |
-i <dev> -nn -c <cnt> [filter] |
パケットキャプチャとヘッダ解析 |
tracepath |
<host> |
中継経路追跡およびPath MTU検出（一般ユーザ可） |
6.2 混同しやすいコマンド構文と設定パス
- nmcli の接続名とデバイス名の混同:
- 設定を変更する際は、デバイス名ではなく接続名に対して操作する（例:
nmcli con mod eth0 ipv4.addresses ...）。
- 設定を変更する際は、デバイス名ではなく接続名に対して操作する（例:
- ボンディング状態の確認パス:
- カーネル仮想パスは
/proc/net/bonding/bond0（/sys/class/net/ではない点に注意）。
- カーネル仮想パスは
- 経路追跡ツールの実行権限:
traceroute➔ RAWソケットを用いるため通常はroot権限またはCAP_NET_RAWが必要。tracepath➔ 通常のUDPポートを使用するため一般ユーザーでも実行可能。
7. まとめ：ネットワークはレイヤーごとの切り分け思考が鍵となる
Linuxにおけるネットワーク運用の本質は、物理ケーブルやNICから、ボンディング・VLANによる論理束ね、IPルーティング、そしてソケット通信までの一連のパケットの流れを、OSI参照モデルの階層に沿って把握することにあります。
障害発生時は、ip linkで物理層・リンク層を確認し、ip addr / ping / ip routeでネットワーク層を検証し、ss -tulpnやtcpdumpでトランスポート層を追うという体系的なアプローチを取ることで、迅速かつ的確な原因特定が可能になります。
次回（第5回）は、運用現場で直面する「ソースコードビルド・パッケージ管理とシステムリソース監視」（make、patch、共有ライブラリldd/ldconfig、バックアップtar/rsync、およびsar/vmstat/iostatによる性能分析）を取り上げます。
