こんにちは！いつもブログを読んでいただき、ありがとうございます。
今回は、主題2.03「ネットワークの問題解決」について、試験に出るポイントを丁寧に解説していきます！
「繋がらない！でもどこから調べればいいかわからない……」というのは、Linuxを学び始めた頃によくある悩みですよね。この記事では、コマンドを1つずつ覚えるだけでなく、「どんなときに何を使うか」という判断の流れごと頭に入れることを目指します。実務でもそのまま使える考え方なので、一緒に押さえていきましょう！
LinuC 201全体の学習ロードマップはこちらにまとめています♪
主題2.03の前の2記事をまだ読んでいない方は、先にそちらも確認しておくと、この記事がよりスムーズに読めますよ。
まずは、この主題で絶対に外せない「キーワード」を確認しましょう。
| 項目 | 内容 |
|---|---|
| 主題番号 | 2.03.3 ネットワークの問題解決 |
| 重要度 | 3（5段階中） |
| 頻出キーワード | ping、traceroute、mtr、ss、netstat、ip route、dig、nc（netcat）、nmap、journalctl、ログファイルのパス |
重要度3は「試験全体のなかで出題比率が高め」という意味です。コマンドの種類は多いですが、「どんな問題に対してどのコマンドを使うか」のセットで覚えてしまうのが合格への近道です！
「下の層から上の層へ」の順番で確認する
ネットワーク障害の原因は、OSI参照モデルの下の層（物理・ネットワーク層）から上の層（アプリケーション層）へと順番に確認するのが鉄則です。
【確認する順番】
1️⃣ NICの状態を確認 ← まずここから！
コマンド: ip link show, ip addr show
▶ NICがUPになっているか？IPアドレスは設定されているか？
2️⃣ 同じネットワーク内の疎通を確認
コマンド: ping <ゲートウェイのIP>
▶ 隣のルーターに届くか？
3️⃣ 外部への疎通を確認
コマンド: ping 8.8.8.8（インターネット上のIP）
▶ IPアドレスで外に出られるか？
4️⃣ 名前解決を確認
コマンド: ping google.com, dig google.com
▶ ドメイン名でも繋がるか？（DNS が機能しているか？）
5️⃣ ポート・サービスの確認
コマンド: ss -tlnp, nc -zv <IP> <ポート>
▶ 必要なポートが開いているか？外部からも到達できるか？
★ここがポイント！ この順番を頭に入れておくと、「3️⃣はOKなのに4️⃣がNG → DNS の問題」のように原因を素早く絞り込めます。試験でもトラブルの状況を読んで「次に使うコマンドはどれか」を答えさせる問題が出るので、この流れごと覚えてしまいましょう。
ping — 最初に使う基本コマンド
ping は相手のホストにICMPエコーリクエストを送り、応答が返ってくるかを確認するコマンドです。
# 基本的な疎通確認
ping 192.168.1.1
# 指定した回数だけ送信して終了する（Linuxのデフォルトは無限送信）
ping -c 4 192.168.1.1
# 送信間隔を指定する（デフォルトは1秒）
ping -i 0.5 192.168.1.1
📝 確認の順番のコツ
ping 127.0.0.1（自分自身）→ping <ゲートウェイIP>（同一セグメント）→ping 8.8.8.8（外部IP）→ping google.com（ドメイン名）の順で試すと問題の切り分けがしやすいです。
traceroute — どこで止まっているかを調べるコマンド
ping で繋がらないとき、どのルーターで止まっているかを調べるのが traceroute です。
# 通信経路を確認する
traceroute 8.8.8.8
# ホスト名解決をせずに数値で表示する（速い・よく使う）
traceroute -n 8.8.8.8
# ICMPを使う（デフォルトはUDP。ファイアウォールで止められにくい）
traceroute -I 8.8.8.8
⚠️
* * *は必ずしも障害ではない！ 出力結果の* * *は、そのルーターが応答を返さない設定になっているだけの場合も多く、その先のホップが表示されていれば通信自体は問題ありません。「* * *が出たから障害だ」と判断するのは試験での引っかけパターンです。
📝
tracepathという選択肢も覚えておこうtracepathはtracerouteと似た機能を持ちますが、root権限なしで実行できるのが特徴です。tracerouteとの違いとして試験に出ることがあります。
mtr — ping + traceroute の合体版
mtr は経路上の各ホップの遅延やパケットロスをリアルタイムで継続表示します。一時的なネットワークの不安定さを調査するのに適しています。
# 対話モードで起動する
mtr 8.8.8.8
# レポートモード（一定回数後に終了して結果を表示）
mtr --report -n -c 10 8.8.8.8
📝 試験ポイント：
tracerouteとの違いは「継続してリアルタイムに監視できる点」です。
「ゲートウェイの設定が正しいか」「目的地への経路があるか」を確認するコマンドです。
# ルーティングテーブルを確認する（新コマンド）
ip route show
# 特定の宛先へのルートを確認する（どのNICを使うか1行で確認できる）
ip route get 8.8.8.8
# ルーティングテーブルを確認する（旧コマンド）
route -n
★ここがポイント！
ip route get <IP>は「特定宛先へのルートを1行でピンポイントに確認できる」コマンドとして試験に出やすいです。ip route showとの使い分けを覚えておきましょう。
ss — サーバー自身の待ち受け状態を確認する（netstat の後継）
# LISTENしているTCPポートをプロセス名付きで数値表示する（最もよく使う）
ss -tlnp
# すべての接続を表示する
ss -a
# TCPの接続のみ表示する
ss -t
# リスニング状態のみ表示する
ss -l
# プロセス名・PIDも表示する
ss -p
# 数値で表示する（名前解決なし）
ss -n
★ここがポイント！
ss -tlnpの各文字は「t=TCP、l=Listen、n=数値（Numeric）、p=プロセス（Process）」に対応しています。英語の頭文字とセットで覚えると忘れにくいですよ。
⚠️
ssにはルーティングテーブルを表示するオプション（-r）はありません。ip route showかnetstat -rnを使いましょう。ひっかけの選択肢に注意してください。
nc（netcat）と nmap — 外部からポートの疎通を確認する（試験頻出！）
ss はサーバー自身の状態を確認するコマンドですが、「クライアント側から本当にそのポートに繋がるか」を確認するのが nc と nmap です。どちらもLinuC公式シラバスに明記されている試験頻出ツールです。
# nc（netcat）で特定ポートの疎通を確認する
# -z：データ送信なしでポートの開閉だけ確認する（ゼロI/Oモード）
# -v：詳細を表示する（接続成功/失敗がわかる）
nc -zv 192.168.1.100 80
# 成功時の出力例
Connection to 192.168.1.100 80 port [tcp/http] succeeded!
# 失敗時の出力例
nc: connectx to 192.168.1.100 port 80 (tcp) failed: Connection refused
# nmap で対象ホストの開いているポートをスキャンする
nmap 192.168.1.100
# よく使う出力例
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp closed https
| コマンド | 用途 | 特徴 |
|---|---|---|
ss -tlnp | サーバー側で自分のポートを確認する | サービス名・PIDもわかる |
nc -zv <IP> <ポート> | クライアント側から特定ポートへの疎通を確認する | 1ポートずつ手軽に確認 |
nmap <IP> | クライアント側から複数ポートをまとめてスキャンする | 開いているポートの一覧が取れる |
📝 試験ポイント：「ポートスキャンツールはどれか（答え：
nmap）」「ポートが開いているか手軽に確認するコマンドはどれか（答え：nc）」という形で問われます。それぞれの使い分けと-z・-vオプションの意味をセットで覚えておきましょう。
netstat — 旧コマンド（試験にも出る）
# LISTENしているポートをプロセス名付きで数値表示する
netstat -tlnp
# ルーティングテーブルを数値表示する
netstat -rn
📝
ssとnetstatのオプションはほぼ同じです。ただしルーティングテーブルの表示はnetstat -rnのみで、ssには対応オプションがありません。
「IPアドレスで繋がるのにドメイン名で繋がらない」場合は、名前解決（DNS）に問題があります。
ホスト名の確認・変更
# ホスト名を確認する
hostname
hostnamectl
# ホスト名を永続的に変更する
hostnamectl set-hostname server01.example.com
DNSの確認コマンド
# ドメイン名をIPアドレスに解決する
dig google.com
# 特定のDNSサーバーに問い合わせる（@ で指定）
dig @8.8.8.8 google.com
# シンプルに確認したい場合
nslookup google.com
# 逆引き（IPアドレスからホスト名を調べる）
dig -x 8.8.8.8
📝 試験ポイント：
dig @8.8.8.8 google.comの@は「問い合わせ先のDNSサーバーを指定する」記号です。「特定のDNSサーバーで解決できるか確認したい」という場面で使います。
名前解決に関わるファイル
| ファイル | 役割 |
|---|---|
/etc/hosts | IPアドレスとホスト名の手動マッピング（ローカルの電話帳） |
/etc/resolv.conf | 使用するDNSサーバーの設定（nameserver 行） |
/etc/nsswitch.conf | 名前解決の優先順位（hosts: files dns など） |
コマンドで原因が特定できない場合は、ログを確認するのが重要です。
# NetworkManager のログを確認する
journalctl -u NetworkManager
# リアルタイムでログを表示する（-f = follow）
journalctl -u NetworkManager -f
# 今回の起動以降のログを確認する
journalctl -b
# カーネルのネットワーク関連メッセージを確認する
dmesg | grep -i "eth\|enp\|network\|link"
ログファイルのパス（試験頻出！）
| ファイル | 対象OS | 内容 |
|---|---|---|
/var/log/messages | RHEL系 | システム全般のログ |
/var/log/syslog | Debian/Ubuntu系 | システム全般のログ |
/var/log/secure | RHEL系 | SSH等の認証ログ |
/var/log/auth.log | Debian/Ubuntu系 | SSH等の認証ログ |
★ここがポイント！ RHEL系とDebian/Ubuntu系でログファイルのパスが違う点は非常によく問われます。どちらの環境でも統合的に使えるのが
journalctlです。この3つの対応関係をセットで覚えておきましょう。
最後に、「ここ、引っかかりそう！」と感じたパターンをまとめました。試験直前に見直してみてくださいね。
| # | 間違いパターン | 正しい理解 |
|---|---|---|
| 1 | traceroute の * * * ＝ 必ず障害 | ❌ ファイアウォールがICMPをブロックしているだけの場合も多い。その先が表示されているなら問題なし |
| 2 | ss コマンドでルーティングテーブルを確認する | ❌ ss にルーティング表示機能はない。ip route show か netstat -rn を使う |
| 3 | ドメイン名で繋がらない ＝ ネットワーク障害 | ❌ ping 8.8.8.8 が通るなら DNS の問題。/etc/resolv.conf と dig で確認する |
| 4 | tracepath は root 権限が必要 | ❌ tracepath は root 権限なしで実行できる。root が必要なのは traceroute |
| 5 | nc -zv の -z はゼロ（数字）のオプション | ❌ -z は「zero-I/O mode（データ送信なしでポートの開閉だけ確認する）」の意味 |
主題2.03の3記事分をまとめて復習できる一覧です。試験直前の確認にどうぞ！
| カテゴリ | コマンド | 説明 |
|---|---|---|
| インターフェース | ip addr show | IPアドレスの確認 |
ip link set enp1s0 up/down | NICのON/OFF | |
ifconfig | IPアドレスの確認（旧） | |
| ルーティング | ip route show | ルーティングテーブルの確認 |
ip route get <IP> | 特定宛先へのルートを確認 | |
route -n | ルーティングテーブルの確認（旧） | |
| NetworkManager | nmcli con show | 接続一覧の確認 |
nmcli con modify "接続名" ... | 接続設定の変更 | |
nmcli con up "接続名" | 接続の有効化・設定の反映 | |
| ボンディング | cat /proc/net/bonding/bond0 | ボンドの状態確認 |
| チーミング | teamctl team0 state | チームの状態確認 |
| 疎通確認 | ping -c 4 <ホスト> | 疎通確認（4回送信） |
traceroute -n <ホスト> | 経路確認（数値表示） | |
tracepath <ホスト> | 経路確認（root不要） | |
mtr <ホスト> | 経路＋遅延のリアルタイム確認 | |
| 接続状態 | ss -tlnp | LISTENポートとプロセスの確認（サーバー側） |
nc -zv <ホスト> <ポート> | 外部からポートの疎通確認 | |
nmap <ホスト> | ポートスキャン | |
netstat -rn | ルーティングの確認（旧） | |
| パケット解析 | tcpdump -i enp1s0 -w file | パケットキャプチャ |
iptraf-ng -i enp1s0 | トラフィック監視 | |
| 名前解決 | dig google.com | DNS確認 |
dig @8.8.8.8 google.com | 特定DNSサーバーで確認 | |
hostnamectl | ホスト名の確認・変更 | |
| ログ | journalctl -u NetworkManager | ネットワーク関連ログの確認 |
dmesg | grep enp | カーネルのNIC関連メッセージ確認 |
私がメインで使っている参考書と問題集です。よければ一緒に勉強していきましょう（笑）
【PR】▶ あずき本（Linux教科書 LinuCレベル2 Version 10.0対応）
リンク
【PR】▶ スピードマスター LinuCレベル2問題集（白本）
リンク
お疲れ様でした！今回のポイントをおさらいしましょう。
- トラブルシューティングの順番：NICの状態 → 同一セグメント → 外部IP → DNS → ポート
traceroute/tracepath：経路確認。* * *は必ずしも障害ではない。tracepathはroot不要- ポートの確認：サーバー側からは
ss -tlnp、外部からはnc -zvやnmap nc -zv：-zはゼロI/Oモード（データ送信なしで開閉確認）、-vは詳細表示- ログファイル：RHEL系は
/var/log/messages、Debian系は/var/log/syslog。どちらでもjournalctlが使える
主題2.03はこれで3記事すべて完走です！ネットワーク構成のコマンドは数が多いですが、まとめ表を使って繰り返し確認していきましょう。
皆さんにとって、今日も素敵な1日になりますように！
参考：LPI-Japan 公式試験範囲 https://linuc.org/linuc2/range/201.html
※本記事はLinuC レベル2 Version 10.0 の出題範囲をもとに作成しています。