TCP/IPからpingまでネットワーク基礎入門

Linuxエンジニア養成講座第16回｜全36回・フェーズ3「ネットワークとインフラ基盤」の1回目（1/12回目）です。
前回まで: フェーズ2「Linux基礎」全12回を完了。ファイル操作、テキスト処理、vi、ユーザー管理、パーミッション、プロセス管理、systemd、シェルスクリプトを学び、第15回のまとめ演習で横断課題と初動コマンド集を体験しました。
今回学ぶこと: TCP/IP、サブネット、ポート番号、DNS名前解決の仕組みと、ip addr / ping / ss / traceroute による疎通確認。

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

TCP/IPの4層モデルを言葉で説明できる
IPアドレス、サブネットマスク、デフォルトゲートウェイの役割を理解し、ip addr / ip route で確認できる
ポート番号の概念を理解し、ss -tlnp でどのサービスがどのポートをリッスンしているか確認できる
DNS名前解決の流れを説明でき、nslookup で確認できる
ping で疎通確認ができ、応答がない場合の切り分け観点を挙げられる
traceroute でパケットの経路を確認できる

alma-mainにSSH接続した状態で進めます。以降のコマンドはすべてalma-main上で実行します。

コンテンツ

フェーズ3へようこそ — 「操作できる」から「つながる」へ
なぜネットワークを学ぶのか
TCP/IPとは何か — 通信の「共通ルール」
IPアドレスとサブネット — 「住所」の仕組み
ポート番号 — 「どのサービス宛てか」を決める番号
DNS — 名前をIPアドレスに変換する仕組み
疎通確認の基本 — ping
- ping の使い方
- ping が応答しない場合の切り分け
経路をたどる — traceroute
- traceroute のインストール
- traceroute の実行と出力の読み方
ヒヤリハット — 「同じIPアドレスを2台に設定してしまった」
やってみよう — alma-main のネットワーク構成を丸ごと確認する
理解度チェック
まとめと次回予告
シリーズ一覧

フェーズ3へようこそ — 「操作できる」から「つながる」へ

フェーズ2では alma-main 1台の中でコマンドを打ち、ファイルを操作し、プロセスを管理してきました。前回の初動コマンド集でも触れましたが、障害対応で確認すべきリソースは「CPU・メモリ・ディスク・ネットワーク」の4つです。フェーズ2ではこのうち前3つを扱いましたが、ネットワークは「第16回以降で」と先送りにしていました。今回からその領域に入ります。

サーバーは1台で動いているわけではありません。Webサーバーはデータベースサーバーと通信し、監視サーバーが各サーバーの状態を収集し、バックアップサーバーにデータを転送する。サーバーエンジニアの仕事の大部分は「サーバー同士のつながり」に関わっています。フェーズ3では、このつながりの仕組みを基礎から学びます。

フェーズ3の全体像を確認しておきます。

回	テーマ	ポイント
16（今回）	ネットワーク基礎	TCP/IP、サブネット、ポート、DNS、ping
17	ネットワーク設定と疎通確認	nmcliでIP設定、alma-sub初登場
18	企業ネットワークの仕組み	プロキシ・DNS・NTP、alma-proxy初登場
19	パッケージ管理	dnf、EPEL、リポジトリ管理
20	ファイアウォール	firewalld、zone、rich-rule
21-22	ボンディング / VLAN	発展トピック（スキップ可）
23	ログ管理	journalctl、rsyslog、logrotate
24	cron / systemd timer	定期実行の基本
25	ストレージ管理（LVM）	fdisk、LVM、xfs
26	シェルスクリプト実践	フェーズ3まとめ演習
27	SSH応用	多段SSH、sshd設定

なぜネットワークを学ぶのか

現場でサーバーエンジニアが受ける問い合わせの多くは、ネットワークに関わるものです。「Webサイトが表示されない」「SSHで接続できない」「バックアップの転送が失敗している」。こうしたトラブルに対応するには、通信の仕組みを理解しておく必要があります。

ネットワークの知識がないと、問題がどこにあるのか見当がつきません。「サーバー自体は動いているのにアクセスできない」のか、「そもそもサーバーまで通信が届いていない」のか。この切り分けができるかどうかで、対応速度は大きく変わります。

TCP/IPとは何か — 通信の「共通ルール」

プロトコルという概念

異なるメーカーのサーバーやPC、異なるOSが混在するネットワークで、全員が同じ方法で通信するための約束事を「プロトコル」といいます。日本語で「通信規約」と訳されることもあります。手紙を送るときに「封筒に宛名と差出人を書く」「切手を貼る」「ポストに入れる」という共通ルールがあるのと同じです。

インターネットで使われている通信プロトコルの体系が「TCP/IP」です。TCP（Transmission Control Protocol）とIP（Internet Protocol）の2つを組み合わせた名前ですが、実際にはこの2つだけでなく、複数のプロトコルをまとめた総称です。

4層モデル

TCP/IPでは、通信の処理を4つの層（レイヤー）に分けて考えます。

層	名前	役割	代表的なプロトコル
4	アプリケーション層	アプリケーションが通信する方法を定める	HTTP, SSH, DNS, SMTP
3	トランスポート層	データの届け方（信頼性・速度）を制御する	TCP, UDP
2	インターネット層	宛先までの経路を決める	IP, ICMP
1	ネットワークインターフェース層	物理的な通信（ケーブル、電気信号）を扱う	Ethernet, Wi-Fi

データを送信するとき、アプリケーション層から順に下の層へ渡され、各層でヘッダー（宛先情報など）が付加されます。受信側では逆に下の層から順にヘッダーを取り除き、最終的にアプリケーションにデータが届きます。

なぜ層に分けるのかというと、各層が独立して動作するためです。たとえばアプリケーション（SSH）を変えても、下の層の仕組み（IPアドレスやケーブル）はそのまま使えます。逆に、物理的なケーブルを光ファイバーに交換しても、上の層のアプリケーションには影響がありません。

TCP と UDP の違いも押さえておきます。TCP はデータが確実に届いたか確認しながら通信します（Webページの表示やSSH接続など、データ欠損が許されない通信向き）。UDP は確認せずに送りっぱなしです（DNS問い合わせやNTP時刻同期など、速度を優先する通信向き）。

IPアドレスとMACアドレスの違い

ネットワーク上で機器を識別するアドレスには、IPアドレスとMACアドレスの2種類があります。

項目	IPアドレス	MACアドレス
層	インターネット層（第2層）	ネットワークインターフェース層（第1層）
形式	192.168.1.121（IPv4の場合）	00:15:5d:01:63:34
変更	設定で変更可能	NICに固定（原則変更しない）
範囲	ネットワークをまたいで通信	同一ネットワーク内の通信
たとえ	住所（引っ越したら変わる）	マイナンバー（一生変わらない）

手紙のたとえで言うと、IPアドレスは「住所」で、MACアドレスは「本人確認番号」です。手紙は住所を頼りに届きますが、同じ建物内で手渡しするときは相手の顔（=MACアドレス）で識別します。ネットワーク通信でも同様に、異なるネットワーク間はIPアドレスで経路を決め、同一ネットワーク内ではMACアドレスで相手を特定しています。

IPアドレスとサブネット — 「住所」の仕組み

IPアドレスの構造（ネットワーク部とホスト部）

IPv4アドレスは 0〜255 の数字4つをドットで区切った形式です（例: 192.168.1.121）。内部的には32ビットの2進数で、前半が「ネットワーク部」、後半が「ホスト部」に分かれます。

ネットワーク部 — そのネットワーク（グループ）の識別子。郵便番号に相当
ホスト部 — そのネットワーク内の個々の機器の識別子。番地に相当

ネットワーク部が同じIPアドレスを持つ機器同士は「同じネットワークにいる」と判断し、直接通信できます。ネットワーク部が異なる場合は、ルーター（ゲートウェイ）を経由する必要があります。

サブネットマスクとCIDR表記

IPアドレスのどこまでがネットワーク部で、どこからがホスト部かを示すのが「サブネットマスク」です。

たとえば、サブネットマスクが 255.255.255.0 の場合、先頭の24ビットがネットワーク部、残り8ビットがホスト部です。CIDR（サイダー）表記では /24 と書きます。alma-main の eth0 は 192.168.1.121/24 なので、192.168.1 の部分がネットワーク部、121 がホスト部です。

表記	サブネットマスク	ネットワーク部	ホスト数（使用可能）
/24	255.255.255.0	先頭24ビット	254台
/16	255.255.0.0	先頭16ビット	65,534台
/8	255.0.0.0	先頭8ビット	約1,677万台

ホスト数が「256」ではなく「254」なのは、ネットワークアドレス（ホスト部が全て0、例: 192.168.1.0）とブロードキャストアドレス（ホスト部が全て1、例: 192.168.1.255）の2つが予約されているためです。

デフォルトゲートウェイの役割

同じネットワーク内の通信は直接届きますが、異なるネットワークへの通信はルーターに転送する必要があります。このとき「どのルーターに転送するか」のデフォルト設定が「デフォルトゲートウェイ」です。

alma-main の場合、デフォルトゲートウェイは 192.168.1.1（家庭用ルーター）です。8.8.8.8（GoogleのDNSサーバー）にpingを送るとき、alma-main は「192.168.1.0/24 の範囲外だから、デフォルトゲートウェイ（192.168.1.1）に転送しよう」と判断します。

alma-main のアドレスを確認する

座学が続いたので、ここからは実際のコマンドで確認していきます。まずは ip addr show で alma-main のIPアドレスを見てみます。第4回で ip a（ip addr の省略形）を使いましたが、今回は出力の意味を一つずつ読み解きます。

alma-mainで実行

実行コマンド：

$ ip addr show eth0

実行結果：

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.121/24 brd 192.168.1.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever

出力の読み方を整理します。

eth0 — インターフェース名。External Switch（外部ネットワーク）に接続されたNIC
state UP — リンクが有効（ケーブルが繋がっている状態）
link/ether 00:15:5d:01:63:34 — MACアドレス
inet 192.168.1.121/24 — IPv4アドレスとサブネットマスク（/24 = 255.255.255.0）
brd 192.168.1.255 — ブロードキャストアドレス

全インターフェースの一覧を見ると、alma-main には複数のNICがあることがわかります。

実行コマンド：

$ 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:34 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.121/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:35 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.1/24 brd 10.0.1.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::4e48:b804:2646:376f/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:36 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.2/24 brd 10.0.1.255 scope global noprefixroute eth2
       valid_lft forever preferred_lft forever
    inet6 fe80::89bf:9cf5:3d34:f528/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
5: eth3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:15:5d:01:63:3d brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.1/24 brd 10.0.2.255 scope global noprefixroute eth3
       valid_lft forever preferred_lft forever
    inet6 fe80::77cc:73f5:6d05:1ec5/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

alma-main には5つのインターフェースがあります。

lo — ループバック。自分自身への通信用（127.0.0.1）。全てのLinuxマシンに存在する
eth0（192.168.1.121/24） — 外部ネットワーク（External Switch）。インターネット接続やSSH接続に使用
eth1（10.0.1.1/24）、eth2（10.0.1.2/24） — 内部ネットワーク（Internal Switch）。検証用に複数NICが同じネットワーク（10.0.1.0/24）に接続されている
eth3（10.0.2.1/24） — 内部ネットワーク（Internal Switch）。別セグメント。後半の演習回で使用する

次にルーティングテーブル（経路情報）を確認します。

実行コマンド：

$ 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.1 metric 101
10.0.1.0/24 dev eth2 proto kernel scope link src 10.0.1.2 metric 104
10.0.2.0/24 dev eth3 proto kernel scope link src 10.0.2.1 metric 103
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.121 metric 100

読み方のポイントは3つです。

default via 192.168.1.1 dev eth0 — デフォルトゲートウェイ。行き先がどのルートにも該当しない通信は、192.168.1.1（ルーター）に転送する
192.168.1.0/24 dev eth0 — 192.168.1.0/24 宛ての通信は eth0 から直接送る（同じネットワーク内なのでルーター不要）
10.0.1.0/24 が2行ある — eth1（10.0.1.1）と eth2（10.0.1.2）が同じネットワークに接続されているため。metric の値が小さい方が優先される（metric の値はNICの認識順序や起動タイミングで変わることがある）

ip addr と ip route はネットワークトラブル時に最初に確認するコマンドです。「IPアドレスが設定されているか」「デフォルトゲートウェイが正しいか」を確認することで、多くの問題の原因を絞り込めます。コマンドのオプションを詳しく知りたいときは man ip-address や man ip-route で確認できます。

ポート番号 — 「どのサービス宛てか」を決める番号

ポートの概念

IPアドレスは「どのサーバーか」を特定しますが、1台のサーバーでは複数のサービスが動いています（SSHサーバー、Webサーバー、データベースなど）。届いた通信が「どのサービス宛てか」を区別するのがポート番号です。

たとえるなら、IPアドレスが「マンションの住所」、ポート番号が「部屋番号」です。住所だけでは建物までしか届きません。部屋番号があって初めて、正しい相手に届きます。

ポート番号は 0〜65535 の範囲で、用途によって大きく3つに分かれます。

0〜1023（ウェルノウンポート） — 代表的なサービスに予約されている。root権限が必要
1024〜49151（登録ポート） — アプリケーションが使用
49152〜65535（動的ポート） — OSが一時的に割り当て（クライアント側の送信元ポートなど）

よく使うポート番号

サーバーエンジニアが覚えておくべき主なポート番号です。

ポート	プロトコル	サービス
22	TCP	SSH
25	TCP	SMTP（メール送信）
53	TCP/UDP	DNS
80	TCP	HTTP
443	TCP	HTTPS
3306	TCP	MySQL / MariaDB
3128	TCP	Squid（プロキシ）

全ポート番号を暗記する必要はありません。上の表の SSH(22)、HTTP(80)、HTTPS(443) の3つだけ覚えておけば、あとは必要なときに調べれば大丈夫です。

今動いているサービスのポートを確認する

第12回のプロセス管理で ss -tlnp を使いました。ここで改めてネットワークの視点から見てみます。

alma-mainで実行

実行コマンド：

$ 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=807,fd=3))
LISTEN 0      128             [::]:22           [::]:*    users:(("sshd",pid=807,fd=4))

オプションの意味を確認します。

-t — TCPのみ表示
-l — LISTEN状態（接続待ち）のみ表示
-n — ポート番号を数字で表示（サービス名に変換しない）
-p — どのプロセスがポートを使っているか表示

出力を読むと、sshd（PID 807）がポート22で接続を待ち受けていることがわかります。0.0.0.0:22 は「全てのIPv4アドレスのポート22」、[::]:22 は「全てのIPv6アドレスのポート22」を意味します。今あなたがSSHで接続できているのは、このsshd がポート22で待ち受けているからです。

UDP のリッスン状態も見てみます。

実行コマンド：

$ sudo ss -ulnp

実行結果：

State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
UNCONN 0      0          127.0.0.1:323       0.0.0.0:*    users:(("chronyd",pid=772,fd=5))
UNCONN 0      0              [::1]:323          [::]:*    users:(("chronyd",pid=772,fd=6))

chronyd（時刻同期サービス）がUDPポート323でリッスンしています。127.0.0.1:323 はローカルホストのみなので、外部からはアクセスできません。chronyd については第18回でNTPクライアント設定として詳しく扱います。

接続全体のサマリーも確認できます。

実行コマンド：

$ ss -s

実行結果：

Total: 115
TCP:   3 (estab 1, closed 0, orphaned 0, timewait 0)

Transport Total     IP        IPv6
RAW	  3         0         3
UDP	  2         1         1
TCP	  3         2         1
INET	  8         3         5
FRAG	  0         0         0

estab 1 は確立済みのTCP接続が1本あることを示しています。これは今あなたが使っているSSH接続です。

DNS — 名前をIPアドレスに変換する仕組み

名前解決の流れ

Webブラウザで google.com にアクセスするとき、実際の通信先はIPアドレス（例: 172.217.211.138）です。人間が覚えやすい名前（ドメイン名）をIPアドレスに変換する仕組みが DNS（Domain Name System）です。

名前解決の流れはこうなっています。

アプリケーションが「google.com のIPアドレスを教えて」とOSに問い合わせる
OSはまず /etc/hosts を確認する（ローカルの名前解決テーブル）
/etc/hosts に該当がなければ、/etc/resolv.conf に書かれたDNSサーバーに問い合わせる
DNSサーバーがIPアドレスを返す
アプリケーションがそのIPアドレスに通信する

/etc/resolv.conf と /etc/hosts

alma-main の DNS設定を確認してみます。

alma-mainで実行

実行コマンド：

$ cat /etc/resolv.conf

実行結果：

# Generated by NetworkManager
nameserver 192.168.1.1

nameserver 192.168.1.1 は「DNSの問い合わせ先が 192.168.1.1」という意味です。家庭用ルーターがDNSの中継役（フォワーダー）を担っています。このファイルは NetworkManager が自動生成しています。手で編集しても、ネットワーク再起動で上書きされるため、DNS設定を変更したい場合は nmcli を使います（第17回で扱います）。

次に /etc/hosts を確認します。

実行コマンド：

$ cat /etc/hosts

実行結果：

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

/etc/hosts はローカルの名前解決テーブルです。ここに書かれたホスト名は、DNSサーバーに問い合わせることなく直接IPアドレスに変換されます。デフォルトでは localhost（127.0.0.1）の定義だけが入っています。検証環境で「alma-sub」のような名前でアクセスしたい場合に、ここにエントリを追加することがあります。

名前解決を確認する（nslookup）

nslookup コマンドで、DNSの名前解決が正常に動作しているか確認できます。この検証環境には導入済みですが、Minimal Install には含まれていないため、未導入の場合は sudo dnf install bind-utils でインストールしてください。

alma-mainで実行

実行コマンド：

$ nslookup google.com

実行結果：

Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	google.com
Address: 172.217.211.138
Name:	google.com
Address: 172.217.211.102
Name:	google.com
Address: 172.217.211.100
（以下略）

出力の読み方です。

Server: 192.168.1.1 — 問い合わせ先のDNSサーバー（/etc/resolv.conf の nameserver）
Address: 192.168.1.1#53 — DNSサーバーのIPとポート番号（DNSはポート53）
Non-authoritative answer — キャッシュから返された回答（権威サーバーからの直接回答ではない）
Name: google.com / Address: 172.217.211.138 — google.com のIPアドレス

IPアドレスが複数返ってくるのは、google.com が負荷分散のために複数のサーバーを用意しているためです。返ってくるIPアドレスは実行するたびに変わることがあります。IPv6アドレス（2404:6800:… のような長いアドレス）が表示されることもありますが、ここでは気にしなくて大丈夫です。

nslookup が使えない環境では、ping google.com でもDNS解決の成否を確認できます。ping の出力に PING google.com (142.251.118.102) のようにIPアドレスが表示されれば、名前解決は成功しています。

疎通確認の基本 — ping

ping の使い方

ping は ICMP（Internet Control Message Protocol）を使って、相手のサーバーに「生きていますか」と問い合わせるコマンドです。ネットワークトラブルの第一歩として、まず ping で疎通を確認するのが定石です。

Linux の ping はオプションなしだと止まるまで送り続けるので、-c オプションで回数を指定します。

alma-mainで実行

まずはデフォルトゲートウェイへの疎通を確認します。

実行コマンド：

$ ping -c 4 192.168.1.1

実行結果：

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 バイト応答 送信元 192.168.1.1: icmp_seq=1 ttl=64 時間=0.489ミリ秒
64 バイト応答 送信元 192.168.1.1: icmp_seq=2 ttl=64 時間=0.835ミリ秒
64 バイト応答 送信元 192.168.1.1: icmp_seq=3 ttl=64 時間=0.933ミリ秒
64 バイト応答 送信元 192.168.1.1: icmp_seq=4 ttl=64 時間=0.762ミリ秒

--- 192.168.1.1 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3107ms
rtt min/avg/max/mdev = 0.489/0.754/0.933/0.164 ms

出力のポイントです。

64 バイト応答 — 相手から応答があった（疎通OK）
ttl=64 — Time To Live。パケットが通過できるルーターの残り回数。64は直接接続されたネットワーク内を意味する
時間=0.489ミリ秒 — 往復の応答時間（RTT）。1ミリ秒未満は非常に近い距離
0% packet loss — パケットロスなし。100%なら完全に届いていない

次に、内部ネットワーク上の別のホストと、インターネット上の Google DNS（8.8.8.8）への疎通を確認します。ここでは筆者の検証環境にある alma-proxy（10.0.1.254）を例にしますが、お使いの環境にある別のVMやホストのIPアドレスに読み替えてください。

実行コマンド：

$ ping -c 4 10.0.1.254

実行結果：

PING 10.0.1.254 (10.0.1.254) 56(84) bytes of data.
64 バイト応答 送信元 10.0.1.254: icmp_seq=1 ttl=64 時間=0.665ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=2 ttl=64 時間=0.750ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=3 ttl=64 時間=1.27ミリ秒
64 バイト応答 送信元 10.0.1.254: icmp_seq=4 ttl=64 時間=0.438ミリ秒

--- 10.0.1.254 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3042ms
rtt min/avg/max/mdev = 0.438/0.780/1.268/0.303 ms

実行コマンド：

$ ping -c 4 8.8.8.8

実行結果：

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 バイト応答 送信元 8.8.8.8: icmp_seq=1 ttl=117 時間=16.3ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=2 ttl=117 時間=16.5ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=3 ttl=117 時間=16.8ミリ秒
64 バイト応答 送信元 8.8.8.8: icmp_seq=4 ttl=117 時間=16.7ミリ秒

--- 8.8.8.8 ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 16.341/16.569/16.801/0.182 ms

応答時間の違いに注目してください。デフォルトゲートウェイ（192.168.1.1）は約0.7ミリ秒、alma-proxy（10.0.1.254）も約0.8ミリ秒ですが、Google DNS（8.8.8.8）は約16ミリ秒かかっています。ネットワーク内は一瞬ですが、インターネット越しの通信は物理的な距離があるため時間がかかります。ttl の値も、ゲートウェイは 64（直接接続）ですが、8.8.8.8 は 117（途中のルーターで減少している）です。

ドメイン名で ping を実行すると、DNS解決も同時に確認できます。

実行コマンド：

$ ping -c 4 google.com

実行結果：

PING google.com (142.251.118.102) 56(84) bytes of data.
64 バイト応答 送信元 tu-in-f102.1e100.net (142.251.118.102): icmp_seq=1 ttl=114 時間=19.0ミリ秒
64 バイト応答 送信元 tu-in-f102.1e100.net (142.251.118.102): icmp_seq=2 ttl=114 時間=18.9ミリ秒
64 バイト応答 送信元 tu-in-f102.1e100.net (142.251.118.102): icmp_seq=3 ttl=114 時間=18.9ミリ秒
64 バイト応答 送信元 tu-in-f102.1e100.net (142.251.118.102): icmp_seq=4 ttl=114 時間=19.6ミリ秒

--- google.com ping 統計 ---
送信パケット数 4, 受信パケット数 4, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 18.883/19.098/19.629/0.307 ms

1行目の PING google.com (142.251.118.102) で、google.com が 142.251.118.102 に解決されたことがわかります。この1行が表示される = DNS解決に成功しています。もしDNS解決に失敗すると ping: google.com: Name or service not known というエラーになります。

ping が応答しない場合の切り分け

ping の応答がないとき、原因は1つではありません。以下の順番で切り分けると効率的です。

自分自身に ping（ping -c 1 127.0.0.1） — 失敗するならネットワークスタック自体の問題
デフォルトゲートウェイに ping（ping -c 1 192.168.1.1） — 失敗するならIPアドレス設定かケーブルの問題
インターネット上のIPアドレスに ping（ping -c 1 8.8.8.8） — 失敗するならルーティングかファイアウォールの問題
ドメイン名で ping（ping -c 1 google.com） — IPアドレスでは成功するのにドメイン名で失敗するならDNSの問題

この順番は「近い側から遠い側へ」です。自分自身 → ゲートウェイ → インターネット → DNS の順に確認することで、どの段階で通信が途切れているかを特定できます。この考え方は第17回の疎通確認でも使います。

注意点として、ping に応答しないからといって相手が停止しているとは限りません。第20回で学ぶファイアウォールで、ICMP（ping）を意図的にブロックしているサーバーもあります。

経路をたどる — traceroute

traceroute のインストール

traceroute は Minimal Install には含まれていないため、dnf でインストールします。

alma-mainで実行

実行コマンド：

$ sudo dnf install -y traceroute

実行結果：

AlmaLinux 9 - AppStream                         5.5 kB/s | 4.2 kB     00:00
AlmaLinux 9 - BaseOS                            5.9 kB/s | 3.8 kB     00:00
AlmaLinux 9 - Extras                            5.4 kB/s | 3.3 kB     00:00
依存関係が解決しました。
================================================================================
 パッケージ         Arch           バージョン              リポジトリー   サイズ
================================================================================
インストール:
 traceroute         x86_64         3:2.1.1-1.el9           baseos          56 k

トランザクションの概要
================================================================================
インストール  1 パッケージ

ダウンロードサイズの合計: 56 k
インストール後のサイズ: 107 k
パッケージのダウンロード:
traceroute-2.1.1-1.el9.x86_64.rpm               4.7 MB/s |  56 kB     00:00
--------------------------------------------------------------------------------
合計                                             89 kB/s |  56 kB     00:00
トランザクションを確認しています
トランザクションの確認に成功しました。
トランザクションをテストしています
トランザクションのテストに成功しました。
トランザクションを実行しています
  準備中           :                                                        1/1
  インストール中   : traceroute-3:2.1.1-1.el9.x86_64                        1/1
  scriptletの実行中: traceroute-3:2.1.1-1.el9.x86_64                        1/1
  検証中           : traceroute-3:2.1.1-1.el9.x86_64                        1/1

インストール済み:
  traceroute-3:2.1.1-1.el9.x86_64

完了しました！

すでにインストール済みの場合は「パッケージ traceroute は既にインストールされています」と表示されます。

traceroute の実行と出力の読み方

traceroute は、宛先までパケットがどのルーターを経由しているかを表示するコマンドです。ping が「届くかどうか」を確認するのに対し、traceroute は「どの経路で届くか」を確認します。

-n オプションを付けると、ルーターのホスト名解決をスキップして高速に表示されます。

alma-mainで実行

実行コマンド：

$ traceroute -n 8.8.8.8

実行結果（実行例 — 経路はネットワーク環境や実行タイミングによって異なります）：

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1  1.090 ms  1.062 ms  1.049 ms
 2  218.40.227.156  2.494 ms  2.562 ms  2.965 ms
 3  218.40.226.81  2.458 ms  3.167 ms 218.40.226.85  4.071 ms
 4  61.203.192.245  3.446 ms 61.203.192.237  2.604 ms *
 5  61.203.193.122  17.221 ms  17.209 ms  17.198 ms
 6  61.203.192.177  17.725 ms  16.614 ms  16.990 ms
 7  108.170.248.185  17.819 ms 142.251.233.119  16.790 ms 108.170.231.103  16.977 ms
 8  142.250.214.149  16.705 ms 108.170.236.127  17.046 ms 142.250.61.143  16.813 ms
 9  8.8.8.8  15.977 ms  15.904 ms  16.304 ms

出力の読み方です。

各行が1ホップ（1つのルーター通過）を表す
左の数字がホップ数。1はデフォルトゲートウェイ（192.168.1.1）、最後が宛先（8.8.8.8）
3つの時間はそれぞれ3回送った応答時間。* は応答なし（タイムアウト）
同じホップで異なるIPが表示される場合（3行目や7行目）は、負荷分散で経路が分かれている

この例では9ホップで 8.8.8.8 に到達しています。ホップ4〜5で応答時間が急に増えている箇所があり、ここがプロバイダーからインターネットのバックボーンへの接続点と推測できます。

traceroute は「ping は通るが遅い」「特定のサーバーだけ通信できない」といった問題の切り分けに役立ちます。途中のホップで * * *（全てタイムアウト）が続く場合、そのルーターが ICMP を返さない設定になっているか、そこで通信が遮断されている可能性があります。

traceroute のオプションを詳しく知りたいときは man traceroute で確認できます。

ヒヤリハット — 「同じIPアドレスを2台に設定してしまった」

現場のヒヤリハット

ある日、サーバー増設の作業をしていた新人エンジニアが、新しいサーバーにIPアドレスを設定しました。ところが、設定したIPアドレスは既に別のサーバーが使用中でした。結果、既存サーバーへの通信が断続的に途切れ、利用者から「サーバーにつながったり、つながらなかったりする」という問い合わせが多数入りました。

IPアドレスの重複は、ネットワーク上で同じ住所が2つ存在する状態です。通信が2台のサーバーに分散してしまうため、問題の原因がわかりにくいのが厄介なところです。

防ぎ方: IPアドレスを設定する前に、ping -c 1 設定予定のIPアドレス を実行して、応答がないことを確認します。応答があれば、そのIPアドレスは既に使われています。また、IPアドレスの管理台帳（Excelやスプレッドシート）を必ず確認・更新する習慣をつけることが重要です。

やってみよう — alma-main のネットワーク構成を丸ごと確認する

今回学んだコマンドを組み合わせて、alma-main のネットワーク構成を一通り確認し、結果をファイルに保存する演習です。

alma-mainで実行

以下のコマンドを順番に実行して、結果を /home/developer/network_info.txt に保存してください。リダイレクト（> と >>）の使い分けは第8回で学んだ通りです。

実行コマンド：

$ echo "=== IPアドレス ===" > /home/developer/network_info.txt
$ ip addr show >> /home/developer/network_info.txt
$ echo "" >> /home/developer/network_info.txt
$ echo "=== ルーティングテーブル ===" >> /home/developer/network_info.txt
$ ip route show >> /home/developer/network_info.txt
$ echo "" >> /home/developer/network_info.txt
$ echo "=== DNS設定 ===" >> /home/developer/network_info.txt
$ cat /etc/resolv.conf >> /home/developer/network_info.txt
$ echo "" >> /home/developer/network_info.txt
$ echo "=== ゲートウェイ疎通 ===" >> /home/developer/network_info.txt
$ ping -c 2 192.168.1.1 >> /home/developer/network_info.txt 2>&1
$ echo "" >> /home/developer/network_info.txt
$ echo "=== DNS解決 ===" >> /home/developer/network_info.txt
$ nslookup google.com >> /home/developer/network_info.txt 2>&1
$ echo "" >> /home/developer/network_info.txt
$ echo "=== リッスンポート（TCP） ===" >> /home/developer/network_info.txt
$ sudo ss -tlnp >> /home/developer/network_info.txt
$ echo "" >> /home/developer/network_info.txt
$ echo "=== traceroute ===" >> /home/developer/network_info.txt
$ traceroute -n 8.8.8.8 >> /home/developer/network_info.txt 2>&1

保存できたら、内容を確認します。

実行コマンド：

$ cat /home/developer/network_info.txt

各セクションに今回学んだ情報がまとまっているか確認してください。このように調査結果をファイルに残す習慣は、現場でも重要です。第2回で学んだ「作業記録」の考え方がここでも活きます。

演習が終わったら、作成したファイルを削除しておきます。

実行コマンド：

$ rm /home/developer/network_info.txt

理解度チェック

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

Q1. TCP/IPの4層モデルで、IPアドレスによる経路制御を担当するのはトランスポート層である。

Q2. サブネットマスクが /24 のネットワークでは、同じネットワークに最大254台のホストを接続できる。

Q3. ip route show の出力に default via 192.168.1.1 dev eth0 と表示されている場合、デフォルトゲートウェイは 192.168.1.1 である。

Q4. SSHが使用するウェルノウンポート番号は 80 である。

Q5. ping -c 4 google.com を実行して「Name or service not known」というエラーが出た場合、DNS名前解決に問題がある。

Q6. ss -tlnp で表示される 0.0.0.0:22 は、特定のIPアドレスからのみSSH接続を受け付ける設定を意味する。

Q7. traceroute の出力で * * * と表示された場合、そのホップ以降の全ての通信が遮断されているとは限らない。

答え合わせ

Q1. × — IPアドレスによる経路制御はインターネット層の役割です。トランスポート層は TCP/UDP によるデータの届け方の制御を担当します。

Q2. ○ — /24 では256個のアドレスのうち、ネットワークアドレスとブロードキャストアドレスを除いた254台が接続可能です。

Q3. ○ — default via の後のIPアドレスがデフォルトゲートウェイです。

Q4. × — SSHのウェルノウンポートは22です。80はHTTPのポート番号です。

Q5. ○ — 「Name or service not known」はドメイン名をIPアドレスに変換できなかったことを意味します。/etc/resolv.conf のDNSサーバー設定やDNSサーバーへの疎通を確認してください。

Q6. × — 0.0.0.0:22 は「全てのIPv4アドレスのポート22」で接続を待ち受けていることを意味します。全てのネットワークインターフェースからのSSH接続を受け付けます。

Q7. ○ — * * * はそのルーターが応答を返さなかっただけで、パケットは先に転送されている場合があります。最終的な宛先に到達できるかどうかは、最後のホップの結果で判断します。

まとめと次回予告

今回はフェーズ3の最初のステップとして、ネットワークの基礎を学びました。TCP/IPの4層モデル、IPアドレスとサブネット、ポート番号、DNSの仕組みを理解し、ip addr、ip route、ss、ping、nslookup、traceroute で実際の疎通を確認しました。

特に重要なのは、ping による疎通確認の「近い側から遠い側へ」の切り分け手順です。この考え方はネットワークトラブル対応の基本中の基本で、現場で何度も使うことになります。

次回の第17回「ネットワーク設定と疎通確認」では、alma-sub（2台目のVM）が初登場します。nmcli を使って自分でIPアドレスを設定し、alma-main と alma-sub の間でネットワーク越しの疎通確認を行います。今回学んだ知識が、そのまま次回の操作の土台になります。

シリーズ一覧

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

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

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

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