第20章 ネットワークの基礎とトラブルシューティング
LPIC-1 109.1〜109.4 相当
サーバーはネットワークにつながって初めて価値を発揮します。ここではネットワークの基礎用語と、接続確認・調査に使うコマンドを扱います。
TCP/IPの基礎用語
| 用語 | 意味 |
|---|---|
| IPアドレス | ネットワーク上の機器を識別する番号（例： 192.168.1.10） |
| サブネットマスク | IPアドレスのうち、どこまでがネットワーク部かを示す（例： /24） |
| ポート番号 | 同じIPアドレス内で、どのサービス宛かを識別する番号（例： HTTPは80、SSHは22） |
| デフォルトゲートウェイ | 異なるネットワーク宛の通信を中継するルーター |
| プライベートIPアドレス | インターネットには直接ルーティングされない、組織内などで自由に使えるアドレス範囲（例： 10.0.0.0/8、192.168.0.0/16） |
サブネットマスク/24は「先頭24ビットがネットワーク部」という意味で、10進数表記では255.255.255.0に相当します。同じネットワーク部を持つ機器同士は、ルーターを経由せず直接通信できます。逆にネットワーク部が異なる相手と通信する場合は、必ずデフォルトゲートウェイを経由することになります。
ネットワーク設定の確認・変更
近年のディストリビューションでは、古い ifconfig / route の代わりに ip コマンドを使うのが標準です。これらの旧コマンドはnet-toolsパッケージに含まれており、多くのディストリビューションでは既定でインストールされなくなっています。
ifconfig/netstat/routeの基本的な使い方が今も出題されることがあります。実務では現行標準のip/ssを使いつつ、試験対策としては両方の対応関係（ifconfig→ip addr、route→ip route、netstat→ss）を押さえておくとよいでしょう。
$ ip addr show # IPアドレスの確認（旧: ifconfig）
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:15:5d:01:ca:01 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth0
valid_lft forever preferred_lft forever
$ ip a # ip addr show の省略形（出力は同じ）
$ ip route show # ルーティングテーブルの確認（旧: route）
default via 192.168.1.1 dev eth0 proto dhcp metric 100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.10 metric 100
$ ip link set eth0 up # インターフェースを有効化（正常時は無出力）
$ sudo ip addr add 192.168.1.20/24 dev eth0 # IPアドレスを一時的に追加（正常時は無出力。再起動で消える一時設定）
$ ip neigh show # ARPテーブル（IPとMACアドレスの対応）を確認（旧: arp -a）
192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
192.168.1.30 dev eth0 lladdr aa:bb:cc:dd:ee:ff STALEこの行のこの値に注目： ip addr showのinet行にあるIPアドレスとプレフィックス（/24）が実際に割り当てられている設定です。ip route showのdefault via行がデフォルトゲートウェイで、これが無い・誤っている場合は外部ネットワークに到達できません。ip neigh showのREACHABLEは直近で応答があったことを示し、STALEは一定時間応答確認をしていない状態を示します。
接続確認・トラブルシューティング
| コマンド | 用途 |
|---|---|
ping ホスト名 | 相手に到達できるかを確認（ICMP） |
traceroute ホスト名 | 相手までの経路（経由するルーター）を確認 |
mtr ホスト名 | tracerouteとpingを組み合わせ、経路上の各ルーターの応答状況を継続的に表示 |
ss -tulnp | 待ち受け中のポートとプロセスを確認（旧： netstat） |
curl URL | Webサーバーなどに実際にリクエストを送って応答を確認 |
wget URL | URLからファイルをダウンロード |
ss -tulnpのオプションはそれぞれ意味を持ちます。-t（TCP）、-u（UDP）、-l（待ち受け中=LISTENのソケットのみ）、-n（名前解決をせず数値のまま表示。応答が速くなる）、-p（プロセス名とPIDも表示。多くはroot権限が必要）という組み合わせです。「特定のポートが誰にどう使われているか」を調べる際の定番コマンドなので、オプションの意味ごと覚えておくと実務でも役立ちます。
$ ss -tulnp | grep :80
LISTEN 0 128 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=1200,fd=6))クライアント側のDNS設定
DNSは、example.com のような名前をIPアドレスに変換する仕組みです。クライアント側でどのDNSサーバーに問い合わせるかは /etc/resolv.conf で設定されます。
$ cat /etc/resolv.conf
nameserver 8.8.8.8
$ dig example.com # 詳細な名前解決情報を確認
; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> example.com
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
;; Query time: 24 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
$ nslookup example.com # 簡易的な名前解決確認
Server: 192.168.1.1
Address: 192.168.1.1#53
Name: example.com
Address: 93.184.216.34この行のこの値に注目： digのANSWER SECTIONにあるレコードが実際の名前解決結果で、86400はこのレコードのTTL（秒）です。SERVER:行でどの名前解決サーバーに問い合わせたかを確認できます。nslookupも同じ結果を簡潔な形式で表示しますが、近年はdigの使用が推奨されています。
主要なポート番号
| ポート番号 | プロトコル・サービス |
|---|---|
| 22 | SSH |
| 25 | SMTP（メール送信） |
| 53 | DNS |
| 80 | HTTP |
| 443 | HTTPS |
| 3306 | MySQL/MariaDB |
これらの対応関係は/etc/servicesファイルにも記載されています。1〜1023番は「well-knownポート」と呼ばれ、割り当てには特別な意味があります。
永続的なネットワーク設定
ip addr addで設定したIPアドレスは、mountと同様に再起動すると消えてしまう一時的な設定です。恒久的に設定するための方法はディストリビューションによって異なります。
| 方式 | 特徴 |
|---|---|
NetworkManager（nmcli） | 多くのデスクトップ系・近年のディストリで標準。nmcli con showで接続一覧を確認 |
| netplan（Ubuntu） | YAML形式（/etc/netplan/*.yaml）で設定を記述し、netplan applyで反映 |
| /etc/network/interfaces（Debian系旧方式） | 設定ファイルに直接IPアドレスなどを記述する伝統的な方式 |
$ nmcli con show # NetworkManagerが管理する接続の一覧
NAME UUID TYPE DEVICE
Wired connection 1 8f2b1a3e-6c4d-4a2f-9e1b-0c5d3f7a2b91 ethernet eth0
$ nmcli device status # 各インターフェースの状態
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected Wired connection 1
lo loopback unmanaged --この行のこの値に注目： nmcli device statusのSTATE列がconnectedになっていればNetworkManager側では正常に接続を認識しています。connectingやunavailableのままの場合は、ケーブル未接続やドライバの問題を疑います。
IPv4とIPv6
近年のシステムではIPv6にも対応していることが一般的です。IPv4のアドレスが「192.168.1.10」のような10進数4組（32ビット）であるのに対し、IPv6は「2001:db8::1」のように16進数8組（128ビット）で表現されます。IPv4の枯渇問題を解決するために設計されただけあってアドレス空間は桁違いに広く、理論上はほぼ無尽蔵にアドレスを割り当てられます。
$ ping -6 example.com # IPv6でpingを送信
PING example.com(2606:2800:21f:cb07:6820:80da:af6b:8b2c (2606:2800:...)) 56 data bytes
64 bytes from 2606:2800:21f:cb07:6820:80da:af6b:8b2c: icmp_seq=1 ttl=52 time=112 ms
--- example.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
$ ip -6 addr show # IPv6アドレスの確認
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet6 2001:db8:1::10/64 scope global dynamic
valid_lft 2591994sec preferred_lft 604794sec
inet6 fe80::215:5dff:fe01:ca01/64 scope linkこの行のこの値に注目： ping -6で応答が返れば、IPv6での疎通性がある証拠です。ip -6 addr showでは、scope globalのアドレスが外部と通信可能なグローバルアドレス、scope linkのfe80::で始まるアドレスは同一リンク内でのみ有効なリンクローカルアドレスです。
IPv6アドレス表記では、連続する0000のブロックを::で1回だけ省略できます。例えば2001:0db8:0000:0000:0000:0000:0000:0001は2001:db8::1と省略でき、各ブロックの先頭の0も省略可能です（0db8→db8）。
よくあるネットワークトラブルの切り分け
「Webサイトに繋がらない」といったトラブルが起きたとき、どこに問題があるかを順序立てて切り分けることが重要です。代表的な手順の例を示します。
| 手順 | 確認内容 | 使うコマンド |
|---|---|---|
| 1. 自分のネットワーク設定を確認 | IPアドレス・ゲートウェイが正しく設定されているか | ip addr show、ip route show |
| 2. 同一ネットワーク内への疎通確認 | デフォルトゲートウェイまで届くか | ping ゲートウェイのIP |
| 3. 名前解決の確認 | ホスト名がIPアドレスに変換できるか | dig、nslookup |
| 4. 外部への疎通確認 | インターネット上の既知のIP（DNSサーバーなど）に届くか | ping 8.8.8.8 |
| 5. サービスの応答確認 | 目的のポートで実際に応答が返るか | curl、ss -tulnp（サーバー側で確認） |
この手順のように「近い範囲」から「遠い範囲」へと順番に確認していくことで、問題が自分のマシン側にあるのか、途中の経路にあるのか、それとも相手のサーバー側にあるのかを効率よく絞り込めます。特にping 8.8.8.8のようにIPアドレス直打ちで疎通が確認できるのに、ホスト名を指定すると失敗する場合は、DNS（名前解決）まわりに問題があると強く推測できます。
traceroute — 経路上のどこで詰まっているかを調べる
pingが「最終的に相手に届くかどうか」だけを教えてくれるのに対し、traceroute（Windowsのtracertに相当）は、目的地まで経由するルーター1台1台の応答時間を順番に表示してくれます。
$ traceroute example.com
1 192.168.1.1 (192.168.1.1) 1.2 ms
2 10.0.0.1 (10.0.0.1) 5.4 ms
3 * * *
4 203.0.113.1 (203.0.113.1) 40.1 ms途中の行が* * *（応答なし）になっている場合、必ずしもそこで通信が完全に途切れているとは限らず、単にそのルーターがtracerouteの問い合わせに応答しない設定になっているだけのこともあります。それでも「どのあたりから急に応答時間が悪化しているか」を見ることで、社内ネットワークの問題か、ISP（プロバイダ）側の問題か、相手サーバー側の問題かをおおまかに切り分ける手がかりになります。
MTUとパケットサイズにまつわるトラブル
ネットワーク機器には、一度に送信できるパケットの最大サイズを表すMTU（Maximum Transmission Unit）という設定値があります。経路上のどこかの機器のMTUが小さいと、大きなパケットが分割（フラグメンテーション）されたり、設定によっては黙って破棄されたりすることがあります。「小さなデータのやり取りは正常なのに、大きなファイルの転送だけが途中で止まる」という一見不可解な症状は、MTUの不一致が原因であることが少なくありません。実機ではping -M do -s サイズ 宛先のように、フラグメンテーションを禁止した状態で送信サイズを変えながら確認することで、経路上の実効MTUを調べられます。