nmcliでIP設定ネットワーク疎通確認入門

Linuxエンジニア養成講座第17回｜全36回・フェーズ3「ネットワークとインフラ基盤」の2回目（2/12回目）です。
前回まで: 第16回でTCP/IPの4層モデル、IPアドレスとサブネット、ポート番号、DNS名前解決の仕組みを学び、ip addr / ping / ss / traceroute で疎通確認を体験しました。
今回学ぶこと: nmcli で IP アドレスを設定・変更し、2台目の VM（alma-sub）と疎通確認。「疎通できない」場面での切り分け手順を実践します。

この記事を読み終えると、以下のことができるようになります。

nmcli を使って IP アドレス / ゲートウェイ / DNS を設定・変更できる
ネットワーク設定の変更を反映するための操作（nmcli connection up / down）を正しく実行できる
alma-sub（2台目の VM）の存在と役割を理解し、SSH 接続できる
2台間の ping 疎通確認を実施できる
「疎通できない」場面で「どこが切れているか」を近い側から遠い側へと切り分けられる
/etc/hosts にエントリを追加してホスト名で通信できる

コンテンツ

alma-sub へようこそ — 2台目VMの登場
nmcli とは何か — NetworkManager の操作ツール
2台間の疎通確認 — ping で確かめる
- alma-main から alma-sub へ
- alma-sub から alma-main へ
IP アドレスを変更してみる — nmcli の実践
/etc/hosts — ホスト名で通信する
- エントリの追加
- ホスト名で ping
traceroute で経路を確認する
「疎通できない」ときの切り分け — 2台で体験する
- 切り分けの原則（復習）
- 意図的に疎通を切って復旧する演習
ヒヤリハット — 「設定変更したのに反映されない」
やってみよう — 2台間のネットワーク設定と疎通確認
理解度チェック
まとめと次回予告
シリーズ一覧

alma-sub へようこそ — 2台目VMの登場

フェーズ2までは alma-main 1台だけで学習を進めてきました。今回から alma-sub（2台目のVM）を使い始めます。サーバーエンジニアの仕事では「自分が設定したサーバーに、別のサーバーから通信できるか」を確認する場面が日常的にあります。2台の VM を使うことで、その感覚を体験できます。

今回の検証構成

今回使う2台の VM とネットワーク構成です。

ホストPC（Windows）
  |
  +--- External Switch（外部スイッチ）
  |       |               |
  |    alma-main         alma-sub
  |    eth0:192.168.1.121  eth0:192.168.1.122
  |
  +--- Internal Switch（内部スイッチ）
          |               |
       alma-main         alma-sub
       eth1:10.0.1.1      eth1:10.0.1.3

alma-main と alma-sub はそれぞれ2つのネットワークインターフェース（eth0 と eth1）を持っています。eth0 は External Switch 経由でインターネットに接続し、eth1 は Internal Switch 経由で VM 同士が直接通信するためのインターフェースです。今回は主に eth1 側（10.0.1.0/24 ネットワーク）を使って演習を行います。

alma-sub に SSH 接続する

alma-sub への SSH 接続は、第5回で学んだ手順と同じです。ホスト PC の TeraTermやWindows Terminal から、alma-sub の External IP（192.168.1.122）に接続します。

ホストPCで実行

実行コマンド：

PS> ssh developer@192.168.1.122

接続できたら、ホスト名を確認して正しい VM にログインしていることを確かめます。

alma-sub の初期状態を確認する

まずは alma-sub のネットワーク構成を確認します。前回学んだコマンドがここでも活きます。

alma-subで実行

実行コマンド：

$ hostname

実行結果：

alma-sub

実行コマンド：

$ ip addr show

実行結果：

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.122/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:39 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.3/24 brd 10.0.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::dfa9:fb75:e6b4:ec07/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

alma-main と同じように、eth0（192.168.1.122）と eth1（10.0.1.3）の2つのインターフェースが確認できます。

ルーティングテーブルも確認します。

alma-subで実行

実行コマンド：

$ ip route show

実行結果：

default via 192.168.1.1 dev eth0 proto static metric 100
10.0.1.0/24 dev eth1 proto kernel scope link src 10.0.1.3 metric 101
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.122 metric 100

2行目の 10.0.1.0/24 dev eth1 は、「10.0.1.0/24 宛ての通信は eth1 から出す」という意味です。alma-main の eth1（10.0.1.1）も同じネットワークにいるため、この経路を通って通信できます。

リッスンしているポートも確認しておきます。

alma-subで実行

実行コマンド：

$ sudo ss -tlnp

実行結果：

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=752,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=752,fd=4))

alma-sub では SSH（ポート22）だけがリッスンしています。Minimal Install の初期状態ではこれが通常です。

nmcli とは何か — NetworkManager の操作ツール

前回は ip addr や ip route でネットワーク設定を「確認」しました。では設定を「変更」するにはどうすればよいでしょうか。AlmaLinux 9 では、ネットワーク設定の管理に NetworkManager というサービスを使います。その操作コマンドが nmcli（NetworkManager Command Line Interface）です。

過去の Linux では /etc/sysconfig/network-scripts/ifcfg-eth0 のような設定ファイルを直接編集する方法が主流でした。しかし AlmaLinux 9 では ifcfg 形式は非推奨（将来のバージョンで廃止予定）であり、nmcli を使うのが標準的な方法です。

connection と device の2つの概念

nmcli を理解するうえで重要なのが「connection（接続プロファイル）」と「device（物理デバイス）」の区別です。

device: 物理的な（または仮想的な）ネットワークインターフェース。eth0、eth1 など。ハードウェアに対応する
connection: そのデバイスに適用する設定の集合。IP アドレス、ゲートウェイ、DNS などの情報を持つ。1つの device に対して複数の connection を定義でき、切り替えて使うこともできる

たとえるなら、device は「SIM カードスロット」、connection は「SIM カード」です。スロットは1つでも、複数の SIM カードを差し替えて使えます。

nmcli の基本コマンド

alma-main で nmcli の基本コマンドを確認します。

alma-mainで実行

まず NetworkManager の全体的な状態を確認します。

実行コマンド：

$ nmcli general status

実行結果：

STATE     CONNECTIVITY  WIFI-HW  WIFI  WWAN-HW  WWAN  METERED
接続済み  完全          missing  有効  missing  有効  いいえ (推測)

STATE が「接続済み」、CONNECTIVITY が「完全」であれば、ネットワークは正常に機能しています。

次に、接続プロファイルの一覧を確認します。

実行コマンド：

$ nmcli connection show

実行結果：

NAME         UUID                                  TYPE      DEVICE
eth0         e83ac41c-9aa7-36ed-8125-43cbb43ab33e  ethernet  eth0
internal1    05e00f04-ccab-4c08-814e-f3ad2f9b4338  ethernet  eth1
internal2    d2ec4710-bda7-4f01-a994-7e02f5394629  ethernet  eth2
intersystem  79194ae0-4736-4e72-993e-f2f682c476fb  ethernet  eth3
lo           d8877e57-6090-4541-bf25-38d7708562b4  loopback  lo
eth1         94ce9502-db04-3b23-b701-9fbe510608c0  ethernet  --
eth2         738b16d4-0020-3f16-a1b0-e95af7badc4c  ethernet  --
eth3         a594a6c6-edcd-4eda-b248-eb8a3787b987  ethernet  --

各列の意味は次の通りです。

NAME: 接続プロファイルの名前
UUID: プロファイルの一意な識別子
TYPE: 接続の種類（ethernet = 有線LAN）
DEVICE: 現在このプロファイルが適用されているデバイス。-- は未使用

DEVICE 列が -- になっている eth1、eth2、eth3 は、古い無効なプロファイルです。実際には internal1、internal2、intersystem というプロファイルがそれぞれ eth1、eth2、eth3 デバイスに適用されています。

続いて、デバイスの状態を確認します。

実行コマンド：

$ nmcli device status

実行結果：

DEVICE  TYPE      STATE            CONNECTION
eth0    ethernet  接続済み         eth0
eth1    ethernet  接続済み         internal1
eth2    ethernet  接続済み         internal2
eth3    ethernet  接続済み         intersystem
lo      loopback  接続済み (外部)  lo

nmcli connection show と nmcli device status の違いは、前者が「設定の一覧」、後者が「デバイスの一覧」です。device status を見ると、各デバイスにどの connection が適用されているかが一目でわかります。

接続プロファイルの詳細を確認する

特定のプロファイルの詳細設定を確認するには、nmcli connection show プロファイル名 を使います。eth1 に適用されている internal1 プロファイルの IPv4 設定を見てみます。

alma-mainで実行

実行コマンド：

$ nmcli connection show internal1 | grep ipv4

実行結果（主要な項目のみ抜粋）：

ipv4.method:                            manual
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         10.0.1.1/24
ipv4.gateway:                           --

読み取れる情報は次の通りです。

ipv4.method: manual — IP アドレスを手動で設定している（DHCPではない）
ipv4.addresses: 10.0.1.1/24 — 設定されている IP アドレスとサブネットマスク
ipv4.gateway: -- — この接続プロファイルにはゲートウェイが未設定（Internal Switch は外部に出ないため）
ipv4.dns: -- — DNS サーバーも未設定

出力項目は非常に多いため、grep で絞り込んでいます。全項目を見たい場合は nmcli connection show internal1 をそのまま実行してみてください。man nmcli で各項目の詳細を確認することもできます。

alma-sub 側でも同様に確認しておきます。

alma-subで実行

実行コマンド：

$ nmcli connection show

実行結果：

NAME      UUID                                  TYPE      DEVICE
eth0      8576940a-7be8-3321-889e-44b3a21daaf0  ethernet  eth0
internal  6b2e2319-76c7-49d3-9a90-7211f9be483f  ethernet  eth1
lo        a7c4ba03-f865-4218-b9c4-212e32f56ff4  loopback  lo

alma-sub のプロファイル構成は alma-main よりシンプルです。eth0 と internal の2つだけで、未使用プロファイルもありません。eth1 に適用されている internal プロファイルの詳細も確認します。

実行コマンド：

$ nmcli connection show internal | grep ipv4

実行結果（主要な項目のみ抜粋）：

ipv4.method:                            manual
ipv4.dns:                               --
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0
ipv4.addresses:                         10.0.1.3/24
ipv4.gateway:                           --

alma-sub の eth1 は 10.0.1.3/24 が設定されています。alma-main の eth1（10.0.1.1/24）と同じ 10.0.1.0/24 ネットワークに属しているため、直接通信できます。

2台間の疎通確認 — ping で確かめる

alma-main と alma-sub の設定を確認できたので、実際に通信できるか ping で確かめます。

alma-main から alma-sub へ

alma-mainで実行

まず Internal Switch 経由（eth1 同士）の疎通を確認します。

実行コマンド：

$ ping -c 4 10.0.1.3

実行結果：

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.3: icmp_seq=1 ttl=64 時間=0.395ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=2 ttl=64 時間=0.756ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=3 ttl=64 時間=0.536ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=4 ttl=64 時間=2.03ミリ秒

--- 10.0.1.3 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3100ms
rtt min/avg/max/mdev = 0.395/0.929/2.029/0.647 ms

4パケットすべて応答があり、0% packet loss です。Internal Switch 経由での疎通は問題ありません。

External Switch 経由（eth0 同士）でも確認します。

実行コマンド：

$ ping -c 4 192.168.1.122

実行結果：

PING 192.168.1.122 (192.168.1.122) 56(84) bytes of data.
64 バイト応答 送信元 192.168.1.122: icmp_seq=1 ttl=64 時間=0.476ミリ秒
64 バイト応答 送信元 192.168.1.122: icmp_seq=2 ttl=64 時間=0.653ミリ秒
64 バイト応答 送信元 192.168.1.122: icmp_seq=3 ttl=64 時間=0.411ミリ秒
64 バイト応答 送信元 192.168.1.122: icmp_seq=4 ttl=64 時間=0.378ミリ秒

--- 192.168.1.122 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3068ms
rtt min/avg/max/mdev = 0.378/0.479/0.653/0.106 ms

こちらも問題ありません。

alma-sub から alma-main へ

逆方向の疎通も確認しておきます。通信は双方向です。「行きは通るが帰りは通らない」というケースも現場ではあるため、両方向の確認が大切です。

alma-subで実行

実行コマンド：

$ ping -c 4 10.0.1.1

実行結果：

PING 10.0.1.1 (10.0.1.1) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.1: icmp_seq=1 ttl=64 時間=0.497ミリ秒
64 バイト応答 送信元 10.0.1.1: icmp_seq=2 ttl=64 時間=0.456ミリ秒
64 バイト応答 送信元 10.0.1.1: icmp_seq=3 ttl=64 時間=0.470ミリ秒
64 バイト応答 送信元 10.0.1.1: icmp_seq=4 ttl=64 時間=0.496ミリ秒

--- 10.0.1.1 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3062ms
rtt min/avg/max/mdev = 0.456/0.479/0.497/0.017 ms

双方向の疎通が確認できました。

IP アドレスを変更してみる — nmcli の実践

ここからが今回のメインテーマです。nmcli を使って IP アドレスを変更し、変更が反映されることを確認し、元に戻すまでの一連の操作を体験します。

nmcli での IP アドレス変更は3ステップです。この手順をセットで覚えてください。

nmcli connection modify — 設定ファイルを変更する（まだ反映されない）
nmcli connection up — 変更した設定を反映する
ip addr show — 反映されたことを確認する

alma-sub の eth1 IP アドレスを変更する

alma-sub の eth1 の IP アドレスを 10.0.1.3 から 10.0.1.10 に変更します。この操作は alma-sub の SSH セッション（192.168.1.122 経由で接続中）で行います。eth1 の IP を変えても、SSH 接続は eth0（192.168.1.122）経由なので切れません。

alma-subで実行

ステップ1: 設定を変更します。

実行コマンド：

$ sudo nmcli connection modify internal ipv4.addresses 10.0.1.10/24

このコマンドは何も出力しません。成功した場合は無言で終わります。

ここが重要です。modify だけでは設定は反映されていません。ip addr show eth1 を実行しても、まだ 10.0.1.3 のままです。

ステップ2: 設定を反映します。

実行コマンド：

$ sudo nmcli connection up internal

実行結果：

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/4)

ステップ3: 反映を確認します。

実行コマンド：

$ ip addr show eth1

実行結果：

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:39 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.10/24 brd 10.0.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::dfa9:fb75:e6b4:ec07/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

inet 10.0.1.10/24 に変わっています。

変更後の疎通確認

alma-main から新しい IP アドレス（10.0.1.10）に ping を打ちます。

alma-mainで実行

実行コマンド：

$ ping -c 4 10.0.1.10

実行結果：

PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.10: icmp_seq=1 ttl=64 時間=0.529ミリ秒
64 バイト応答 送信元 10.0.1.10: icmp_seq=2 ttl=64 時間=0.469ミリ秒
64 バイト応答 送信元 10.0.1.10: icmp_seq=3 ttl=64 時間=0.295ミリ秒
64 バイト応答 送信元 10.0.1.10: icmp_seq=4 ttl=64 時間=0.859ミリ秒

--- 10.0.1.10 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3080ms
rtt min/avg/max/mdev = 0.295/0.538/0.859/0.204 ms

新しい IP アドレスで応答が返ってきました。次に、旧アドレス（10.0.1.3）に ping を打ちます。

実行コマンド：

$ ping -c 4 10.0.1.3

実行結果：

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.

--- 10.0.1.3 ping 統計 ---
送信パケット数 4, 受信パケット数 0, 100% packet loss, time 3069ms

100% packet loss です。IP アドレスが変わったので、旧アドレスにはもう応答しません。これは正常な動作です。IP アドレスの変更が正しく反映されていることを確認できました。

元に戻す

演習後は必ず元の設定に戻します。本番環境では「変更前の値をメモしてから変更する」が鉄則です。今回は 10.0.1.3/24 に戻します。

alma-subで実行

実行コマンド：

$ sudo nmcli connection modify internal ipv4.addresses 10.0.1.3/24

実行コマンド：

$ sudo nmcli connection up internal

実行結果：

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/5)

実行コマンド：

$ ip addr show eth1

実行結果：

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:39 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.3/24 brd 10.0.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::dfa9:fb75:e6b4:ec07/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

10.0.1.3/24 に戻りました。

DNS の設定変更と /etc/resolv.conf の関係

前回、DNS サーバーの設定は /etc/resolv.conf に書かれていることを学びました。まず alma-sub の現在の設定を確認します。

alma-subで実行

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 192.168.1.1

1行目のコメントに注目してください。# Generated by NetworkManager とあります。このファイルは NetworkManager が自動生成しています。つまり /etc/resolv.conf を直接編集しても、NetworkManager がプロファイルの設定で上書きしてしまいます。DNS の設定を永続的に変更するには、nmcli で接続プロファイルの ipv4.dns を変更する必要があります。

DNS サーバーを 8.8.8.8（Google Public DNS）に変更してみます。

実行コマンド：

$ sudo nmcli connection modify eth0 ipv4.dns "8.8.8.8"

実行コマンド：

$ sudo nmcli connection up eth0

実行結果：

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/8)

反映されたか確認します。

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 8.8.8.8

nameserver が 8.8.8.8 に変わりました。nmcli で DNS を変更すると、NetworkManager が /etc/resolv.conf を自動的に書き換えてくれます。

確認できたので、元に戻します。

実行コマンド：

$ sudo nmcli connection modify eth0 ipv4.dns "192.168.1.1"

実行コマンド：

$ sudo nmcli connection up eth0

反映を確認します。

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 192.168.1.1

元の DNS 設定に戻りました。

/etc/hosts — ホスト名で通信する

ここまで、相手サーバーへの通信にはすべて IP アドレスを使ってきました。しかし毎回 10.0.1.3 と入力するのは手間ですし、覚えにくいです。/etc/hosts にエントリを追加すると、ホスト名（例: alma-sub）で通信できるようになります。

/etc/hosts は前回学んだ DNS の仕組みより前に参照されるローカルの名前解決ファイルです。DNS サーバーに問い合わせる前に、このファイルに該当するエントリがないか確認します。

エントリの追加

alma-main の /etc/hosts に alma-sub のエントリを追加します。第9回で学んだ vi を使って編集します。

alma-mainで実行

実行コマンド：

$ sudo vi /etc/hosts

ファイルの末尾に次の1行を追加してください。

10.0.1.3 alma-sub

書式は「IP アドレス（スペースまたはタブ）ホスト名」です。保存して vi を終了します（Esc → :wq）。

追加後の内容を確認します。

実行コマンド：

$ cat /etc/hosts

実行結果：

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.0.1.3 alma-sub

ホスト名で ping

alma-mainで実行

実行コマンド：

$ ping -c 4 alma-sub

実行結果：

PING alma-sub (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 alma-sub (10.0.1.3): icmp_seq=1 ttl=64 時間=0.370ミリ秒
64 バイト応答 送信元 alma-sub (10.0.1.3): icmp_seq=2 ttl=64 時間=0.354ミリ秒
64 バイト応答 送信元 alma-sub (10.0.1.3): icmp_seq=3 ttl=64 時間=0.939ミリ秒
64 バイト応答 送信元 alma-sub (10.0.1.3): icmp_seq=4 ttl=64 時間=0.405ミリ秒

--- alma-sub ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3116ms
rtt min/avg/max/mdev = 0.354/0.517/0.939/0.244 ms

1行目の PING alma-sub (10.0.1.3) に注目してください。「alma-sub」というホスト名が「10.0.1.3」に解決されてから ping が実行されています。/etc/hosts の設定が機能していることがわかります。

現場では、検証環境の VM 同士や社内サーバー間で /etc/hosts を使うことが多くあります。DNS サーバーに登録するほどではない一時的な名前解決に便利です。ただし、台数が増えると各サーバーの /etc/hosts を個別に管理する手間が発生するため、規模が大きい環境では DNS サーバーの利用が一般的です。

traceroute で経路を確認する

前回、traceroute でインターネット上のサーバーへの経路を確認しました。今回は同一ネットワーク内の alma-sub への経路を見てみます。

alma-mainで実行

実行コマンド：

$ traceroute -n 10.0.1.3

実行結果：

traceroute to 10.0.1.3 (10.0.1.3), 30 hops max, 60 byte packets
 1  10.0.1.3  0.300 ms !X  0.271 ms !X  0.259 ms !X

1ホップで到達しています。同じネットワーク（10.0.1.0/24）内なので、ルーターを経由せず直接通信しているためです。前回の traceroute to 8.8.8.8 では9ホップかかっていたのと比較してみてください。

応答時間の後ろに表示されている !X は「Administratively Prohibited（管理上の通信禁止）」を意味する ICMP コードです。パケット自体は宛先（10.0.1.3）に到達しています。alma-sub の firewalld のデフォルト設定が、traceroute で使用される一部の ICMP メッセージを制限しているために表示されます。第20回で firewalld を学ぶ際に、この仕組みを詳しく理解できます。

External Switch 経由でも確認してみます。

実行コマンド：

$ traceroute -n 192.168.1.122

実行結果：

traceroute to 192.168.1.122 (192.168.1.122), 30 hops max, 60 byte packets
 1  192.168.1.122  0.338 ms !X  0.256 ms !X  0.190 ms !X

こちらも1ホップです。同じスイッチに接続された VM 同士なので、直接通信できています。

「疎通できない」ときの切り分け — 2台で体験する

前回、ping の応答がないときの切り分け手順として「近い側から遠い側へ」の順番を学びました。今回は実際に2台の VM 間で疎通を失敗させ、切り分けと復旧を体験します。

切り分けの原則（復習）

自分自身に ping（127.0.0.1） — ネットワークスタック自体に問題がないか
自分の IP アドレスに ping（自分の eth1 の IP） — インターフェースが正常か
相手の IP アドレスに ping（相手の eth1 の IP） — 相手までの疎通があるか

この順番で確認することで、「どこまでは正常で、どこから異常か」を特定できます。

意図的に疎通を切って復旧する演習

alma-sub の internal 接続プロファイルを意図的に無効化（down）して、alma-main から疎通できなくなることを確認し、再度有効化（up）して復旧します。

alma-subで実行

実行コマンド：

$ sudo nmcli connection down internal

実行結果：

接続 'internal' が正常に非アクティブ化されました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/5)

デバイスの状態を確認します。

実行コマンド：

$ nmcli device status

実行結果：

DEVICE  TYPE      STATE            CONNECTION
eth0    ethernet  接続済み         eth0
lo      loopback  接続済み (外部)  lo
eth1    ethernet  切断済み         --

eth1 が「切断済み」になり、CONNECTION 列も --（プロファイル未適用）です。

この状態で alma-main から ping を打ちます。

alma-mainで実行

実行コマンド：

$ ping -c 4 10.0.1.3

実行結果：

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.

--- 10.0.1.3 ping 統計 ---
送信パケット数 4, 受信パケット数 0, 100% packet loss, time 3060ms

100% packet loss です。alma-sub の eth1 が切断されているため、応答がありません。

ここで切り分けの手順に沿って確認してみます。

alma-mainで実行

実行コマンド：

$ ping -c 1 127.0.0.1

自分自身（127.0.0.1）への ping は成功するはずです。alma-main 側のネットワークスタックは正常です。

実行コマンド：

$ ping -c 1 10.0.1.1

自分の eth1 IP への ping も成功します。alma-main 側のインターフェースは正常です。

つまり「alma-main 側は正常だが、alma-sub の eth1 側に問題がある」と切り分けられます。実際に alma-sub の eth1 を切断したので、この結論は正しいです。

では復旧します。

alma-subで実行

実行コマンド：

$ sudo nmcli connection up internal

実行結果：

接続が正常にアクティベートされました (D-Bus アクティブパス: /org/freedesktop/NetworkManager/ActiveConnection/6)

復旧後に alma-main から再度 ping を確認します。

alma-mainで実行

実行コマンド：

$ ping -c 4 10.0.1.3

実行結果：

PING 10.0.1.3 (10.0.1.3) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.3: icmp_seq=1 ttl=64 時間=0.512ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=2 ttl=64 時間=0.524ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=3 ttl=64 時間=0.402ミリ秒
64 バイト応答 送信元 10.0.1.3: icmp_seq=4 ttl=64 時間=0.966ミリ秒

--- 10.0.1.3 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3090ms
rtt min/avg/max/mdev = 0.402/0.601/0.966/0.216 ms

疎通が復旧しました。「切る → 確認 → 切り分け → 復旧 → 確認」の一連の流れを体験できました。

ヒヤリハット — 「設定変更したのに反映されない」

現場のヒヤリハット

ある新人エンジニアが、夜間メンテナンスでサーバーの IP アドレスを変更する作業を担当しました。手順書通りに nmcli connection modify でIP アドレスを変更し、「変更完了」と報告。しかし翌朝、「IP アドレスが変わっていない」と連絡が入りました。

原因は nmcli connection up を実行し忘れたことです。modify は設定ファイルを書き換えるだけで、実際のネットワーク設定には反映されません。up で接続プロファイルを再適用して、初めて反映されます。

さらに厄介なのは、この状態でサーバーを再起動すると、modify で書き換えた設定が反映されてしまうことです。メンテナンス当日は旧 IP で動いていたのに、後日の再起動で突然新 IP に切り替わり、別の障害を引き起こすこともあります。

防ぎ方: IP アドレス変更の手順は「modify → up → ip addr show で確認」の3ステップをセットにする。変更後の確認（ip addr show）を省略しない。また、古い Linux の手順書にある「ifcfg ファイルを直接編集して systemctl restart NetworkManager」という方法は、AlmaLinux 9 では非推奨です。nmcli を使う手順に統一してください。

やってみよう — 2台間のネットワーク設定と疎通確認

今回学んだ内容を組み合わせた演習です。alma-main と alma-sub の2つの SSH セッションを開いた状態で進めてください。

ステップ1: alma-sub の現在の状態を確認する

alma-subで実行

以下のコマンドで alma-sub の状態を確認し、eth1 の IP アドレスが 10.0.1.3/24 であることを確認してください。

実行コマンド：

$ nmcli connection show internal | grep ipv4.addresses
$ ip addr show eth1

ステップ2: IP アドレスを変更し、疎通確認し、元に戻す

alma-sub の eth1 を 10.0.1.20/24 に変更し、alma-main から ping で疎通を確認し、元の 10.0.1.3/24 に戻してください。

操作の流れは次の通りです。

alma-sub: sudo nmcli connection modify internal ipv4.addresses 10.0.1.20/24
alma-sub: sudo nmcli connection up internal
alma-sub: ip addr show eth1 で 10.0.1.20 になっていることを確認
alma-main: ping -c 4 10.0.1.20 で疎通を確認
alma-main: ping -c 4 10.0.1.3 で旧アドレスが応答しないことを確認
alma-sub: sudo nmcli connection modify internal ipv4.addresses 10.0.1.3/24
alma-sub: sudo nmcli connection up internal
alma-sub: ip addr show eth1 で 10.0.1.3 に戻っていることを確認
alma-main: ping -c 4 10.0.1.3 で復旧を確認

ステップ3: /etc/hosts にエントリを追加し、ホスト名で ping する

この演習は、記事中で既に alma-sub のエントリを追加済みの場合はスキップしてください。まだの場合は、alma-main の /etc/hosts に 10.0.1.3 alma-sub を追加し、ping -c 4 alma-sub で応答が返ることを確認してください。

ステップ4: 疎通失敗 → 切り分け → 復旧

alma-sub: sudo nmcli connection down internal で eth1 を切断
alma-main: ping -c 4 10.0.1.3 で疎通失敗を確認
alma-main: 切り分け手順を実行（127.0.0.1 → 10.0.1.1 → 10.0.1.3 の順に ping）
alma-sub: nmcli device status で eth1 が切断済みであることを確認
alma-sub: sudo nmcli connection up internal で復旧
alma-main: ping -c 4 10.0.1.3 で復旧を確認

クリーンアップ

演習が終わったら、/etc/hosts を元に戻しておきます。

alma-mainで実行

実行コマンド：

$ sudo vi /etc/hosts

追加した 10.0.1.3 alma-sub の行を削除して保存してください（vi で該当行にカーソルを合わせて dd → :wq）。

復元後の内容を確認します。

実行コマンド：

$ cat /etc/hosts

実行結果：

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

追加した行が削除されていれば完了です。

理解度チェック

今回の内容を確認します。○か×で答えてください。

Q1. nmcli connection modify を実行すると、IPアドレスの変更は即座にネットワークインターフェースに反映される。

Q2. nmcli device status で表示される STATE が「切断済み」のデバイスは、接続プロファイルが適用されていない状態である。

Q3. nmcli connection show の出力で DEVICE 列が -- のプロファイルは、現在どのデバイスにも適用されていない。

Q4. /etc/resolv.conf を直接編集して DNS サーバーを変更すると、NetworkManager が管理する環境では再起動後も設定が維持される。

Q5. /etc/hosts による名前解決は、DNS サーバーへの問い合わせより先に参照される。

Q6. ping -c 1 127.0.0.1 が成功し、ping -c 1 10.0.1.1（自分の IP）も成功するが、ping -c 1 10.0.1.3（相手の IP）が失敗する場合、問題は自分側ではなく相手側にある可能性が高い。

Q7. traceroute の出力で同一ネットワーク内の宛先は、通常1ホップで到達する。

答え合わせ

Q1. × — modify は設定ファイルを書き換えるだけです。実際に反映するには nmcli connection up プロファイル名 の実行が必要です。

Q2. ○ — 「切断済み」は接続プロファイルが適用されていない状態を表します。nmcli connection up プロファイル名 で再度適用できます。

Q3. ○ — DEVICE 列が -- のプロファイルは、定義は存在するがどのデバイスにも適用されていない未使用のプロファイルです。

Q4. × — /etc/resolv.conf は NetworkManager が自動生成するファイルです。直接編集しても、接続プロファイルの再適用やサービス再起動時に上書きされます。永続的に変更するには nmcli connection modify で ipv4.dns を設定してください。

Q5. ○ — Linux のデフォルト設定（/etc/nsswitch.conf の hosts: files dns）では、/etc/hosts（files）が DNS より先に参照されます。

Q6. ○ — 近い側から遠い側への切り分けで、自分自身と自分のインターフェースが正常であれば、問題は相手側のインターフェースやネットワーク経路にある可能性が高いといえます。ただし、途中のファイアウォールが原因の場合もあるため、断定はできません。

Q7. ○ — 同一ネットワーク内ではルーターを経由せず直接通信するため、1ホップで到達します。

まとめと次回予告

今回は alma-sub（2台目の VM）を初めて使い、nmcli による IP アドレスの変更、2台間の ping 疎通確認、/etc/hosts によるホスト名での通信、そして疎通失敗時の切り分けと復旧を体験しました。

特に覚えておいてほしいのは次の2点です。

nmcli connection modify → up → ip addr show の3ステップセット
疎通できないときは「近い側から遠い側へ」の順番で切り分ける

nmcli のオプションを詳しく知りたい場合は man nmcli や nmcli --help で確認できます。サブコマンドごとのヘルプ（nmcli connection --help）も活用してください。

次回の第18回「企業ネットワークの仕組み」では、3台目の VM（alma-proxy）が登場します。企業ネットワークで使われるプロキシ・DNS・NTP の仕組みを学び、クライアント側の設定を実践します。第7回で「おまじない」として追加したプロキシ設定の意味も、ここで回収します。

シリーズ一覧

フェーズ1: エンジニアのいろは（第1回〜第3回）

フェーズ2: Linux基礎（第4回〜第15回）

フェーズ3: ネットワークとインフラ基盤（第16回〜第27回）

フェーズ4: サーバー構築と運用（第28回〜第36回）