第10章　高度なネットワーク設定とトラブルシューティング

LPIC-2 205.1〜205.3 相当

中級の第15章ではネットワークの基礎を扱いました。ここでは、サーバー環境でよく使われる、より高度なネットワーク構成技術を扱います。これらは単一のNICやネットワークセグメントに依存しない、可用性・拡張性の高いサーバーインフラを構築するための土台となる知識です。

ネットワークボンディング（チーミング）

複数の物理NIC（ネットワークインターフェースカード）を束ねて1つの論理インターフェースとして扱う技術です。冗長性の確保や帯域の増強が目的です。

$ cat /proc/net/bonding/bond0    # ボンディングインターフェースの状態と、各スレーブNICの状態を確認
Bonding Mode: fault-tolerance (active-backup)
Currently Active Slave: eth0
MII Status: up
Slave Interface: eth0
MII Status: up
Slave Interface: eth1
MII Status: up

この出力のCurrently Active Slaveから、active-backupモードで現在どのNICが実際に通信に使われているかが分かります。eth0が故障してリンクダウンすると、この値は自動的にeth1へ切り替わります。特別な設定なしに手早く冗長性だけを確保したい場合はactive-backup（mode 1）、スイッチ側の設定も含めて本格的に帯域増強したい場合はLACP（mode 4）を選ぶ、というのが実務でのおおまかな使い分けの目安です。

VLAN（仮想LAN）

物理的には同じネットワークでも、タグ（802.1Q）によって論理的に複数のネットワークに分割する技術です。1本のケーブルで複数の独立したネットワークを扱えます。スイッチのポートには、単一のVLANにしか属さない「アクセスポート」と、複数のVLANのタグ付きフレームをまとめて通す「トランクポート」があり、サーバーのNICを複数VLANに参加させる場合は、通常はスイッチ側のポートをトランクポートとして設定した上で、Linux側でVLANインターフェースを作成します。

$ sudo ip link add link eth0 name eth0.100 type vlan id 100   # 正常時は無出力
# eth0上にVLAN ID 100のインターフェース eth0.100 を作成
$ sudo ip addr add 192.168.100.10/24 dev eth0.100   # 正常時は無出力
$ sudo ip link set eth0.100 up   # 正常時は無出力
$ ip -d link show eth0.100      # -d（detail）でVLAN IDなどの詳細情報を確認できる
5: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:15:5d:01:ca:01 brd ff:ff:ff:ff:ff:ff
    vlan protocol 802.1Q id 100 <REORDER_HDR>

この行のこの値に注目： eth0.100@eth0の@eth0部分が、このVLANインターフェースがどの物理インターフェースの上に乗っているかを示します。vlan protocol 802.1Q id 100行で、実際にタグ付けされているVLAN IDが100であることを確認できます。

VLANのIDは1〜4094の範囲で指定でき、同一の物理NIC上に複数のVLANインターフェース（eth0.100、eth0.200など）を同時に作成することも可能です。それぞれ独立したIPアドレス・ルーティング設定を持てるため、1台のサーバーを複数のセグメントに同時に参加させる構成（たとえば管理用ネットワークと業務用ネットワークの分離）でよく使われます。

無線LANインターフェースの設定

サーバー用途では有線接続が基本ですが、LPIC-2の出題範囲には無線LANインターフェースの基礎的な設定・確認コマンドも含まれます。現在の標準的なツールはiwで、やや古いiwconfig/iwlist（wireless-toolsパッケージ）もまだ広く使われています。

$ iw dev                       # 無線インターフェース一覧を確認
phy#0
        Interface wlan0
                ifindex 3
                type managed
$ sudo iw dev wlan0 connect MyOffice-WiFi   # 暗号化なしAPへの接続例（正常時は無出力）
$ iw dev wlan0 link            # 接続状態を確認
Connected to 6e:5f:4d:3c:2b:1a (on wlan0)
	SSID: MyOffice-WiFi
	freq: 5180
	signal: -45 dBm
	tx bitrate: 866.7 MBit/s VHT-MCS 9

この行のこの値に注目： signalはdBm単位の電波強度で、0に近いほど強く、目安として-70dBmより悪化すると接続が不安定になりやすいとされています。freq: 5180は5GHz帯を使っていることを示し、2.4GHz帯（freq: 2412など）より高速だが障害物に弱い特性があります。

WPA/WPA2のような認証・暗号化が必要な無線LANへの接続には、iw単体では対応できず、wpa_supplicantと組み合わせるのが一般的です。wpa_supplicant.confにSSIDとパスフレーズ（wpa_passphraseコマンドで暗号化済みの値を生成できます）を記述し、wpa_supplicantデーモンが認証・鍵交換を担当したうえで、iwやdhclientでIPアドレスを取得する、という役割分担になります。

/etc/wpa_supplicant/wpa_supplicant.conf の例
network={
    ssid="MyOffice-WiFi"
    psk="（wpa_passphraseで生成した暗号化済みの値）"
}

静的ルートの追加

特定のネットワーク宛の通信を、既定のゲートウェイとは別の経路に流したい場合、静的ルートを追加します。ルーティングテーブルの検索は「最長プレフィックス一致（longest prefix match）」で行われるため、デフォルトルート（0.0.0.0/0）よりも具体的な（プレフィックス長の長い）静的ルートが存在すれば、そちらが優先されます。

$ sudo ip route add 10.0.0.0/24 via 192.168.1.254   # 正常時は無出力
# 10.0.0.0/24宛の通信は192.168.1.254経由にする
$ ip route show                # 現在のルーティングテーブルを確認
default via 192.168.1.1 dev eth0 proto dhcp metric 100
10.0.0.0/24 via 192.168.1.254 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100
$ sudo ip route add default via 192.168.1.1 metric 100
RTNETLINK answers: File exists
# metricで優先度を指定。複数のデフォルトゲートウェイ候補がある場合、値が小さいほど優先される
$ sudo ip route del 10.0.0.0/24 via 192.168.1.254   # 静的ルートの削除（正常時は無出力）

この行のこの値に注目： ip route showに追加した10.0.0.0/24 via 192.168.1.254の行が表示されていれば、静的ルートが正しく登録されています。RTNETLINK answers: File existsは、すでに同じデフォルトルートが存在する場合に出るエラーで、この例ではDHCPで既に付与されたデフォルトルートと重複したために発生しています。

NetworkManager（nmcli）

多くのデスクトップ・一部のサーバー用ディストリビューションでは、NetworkManager がネットワーク設定を管理しています。CUIからは nmcli で操作できます。

$ nmcli device status               # デバイス一覧と状態
DEVICE  TYPE      STATE      CONNECTION
eth0    ethernet  connected  Wired connection 1
$ nmcli connection show             # 接続プロファイル一覧
NAME                UUID                                  TYPE      DEVICE
Wired connection 1  8f2b1a3e-6c4d-4a2f-9e1b-0c5d3f7a2b91  ethernet  eth0
$ sudo nmcli connection up eth0     # 接続を有効化
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
$ sudo nmcli connection add type ethernet ifname eth0 con-name eth0-static ip4 192.168.1.10/24 gw4 192.168.1.1
Connection 'eth0-static' (a1b2c3d4-...) successfully added.
# 静的IPアドレスを持つ新しい接続プロファイルを作成し、それ自体を設定として永続化する

この行のこの値に注目： connection add実行時のsuccessfully addedという応答とともに、新しい接続プロファイルのUUIDが発行されます。作成しただけでは有効化されないため、nmcli connection up eth0-staticで明示的に有効化する必要があります。

nmcliで作成した接続プロファイルは/etc/NetworkManager/system-connections/以下にファイルとして保存されるため、ipコマンドでの一時的な変更と違い、追加の設定ファイル操作なしにそのまま再起動後も有効になります。

設定の永続化に関する注意

ip コマンドで行った変更（アドレス付与、ルート追加、VLAN作成など）は、原則として再起動やネットワークサービスの再起動で失われる一時的な変更です。恒久的に反映させるには、ディストリビューションごとの設定の仕組み（Debian系の /etc/network/interfaces、Ubuntu ServerのNetplan、RHEL系の /etc/sysconfig/network-scripts/ やNetworkManagerのキーファイル）に書き込む必要があります。

Netplanの設定例（/etc/netplan/01-netcfg.yaml）
network:
  version: 2
  ethernets:
    eth0:
      addresses: [192.168.1.10/24]
      routes:
        - to: 10.0.0.0/24
          via: 192.168.1.254

$ sudo netplan try     # 適用して問題があれば自動的にロールバック
Do you want to keep these settings?


Press ENTER before the timeout to accept the new configuration


Changes will revert in 110 seconds
$ sudo netplan apply   # 正常時は無出力

この行のこの値に注目： netplan tryは設定を一時的に適用し、Changes will revert in N secondsのカウントダウン中にEnterキーで確定しなければ自動的に元の設定へロールバックします。誤った設定でSSH接続そのものが切れてしまうリスクを避けられるため、リモートサーバーでの変更ではapplyよりtryを使うのが安全です。

近年の多くのディストリビューションではNetworkManagerが標準となっており、nmcli connection addやnmcli connection modifyで接続プロファイルを作成・編集すると、その内容が自動的に永続化されます。サーバー用途でNetworkManagerを使わない構成では、systemd-networkd用の.networkファイルを/etc/systemd/network/に配置する方法もよく使われます。どの仕組みを使っているかはnmcli general statusやsystemctl status systemd-networkdで確認できるため、設定変更の前にまず現在の管理方式を把握することが重要です。

ネットワークのトラブルシューティングコマンド