Linux ネットワークトラブルシューティング：サーバーの診断とセキュリティ保護

はじめに

ネットワーク・ナビゲーターの世界へようこそ！あなたは急成長中のテック系スタートアップに、ジュニア・システム管理者として採用されました。今朝、重要なウェブサーバーがオフラインになり、ユーザーから社内ポータルにアクセスできないという報告が届いています。

シニア管理者は会議で手が離せないため、あなたに初期診断が任されました。あなたの腕の見せ所です！ミッションは、サーバーのネットワーク状態を体系的に調査し、根本原因を特定して、接続を復旧させることです。サーバーをオンラインに戻しましょう！

重要なお知らせ

このチャレンジの内容は、Quick Start with Linux コースの範囲を超えている場合があります。

チャレンジ中に行き詰まった場合：

一時的にこのチャレンジをスキップし、Linux 学習パスの後続のガイド付き実験（Guided Labs）を進めてください。
Labby に相談するか、解決策（Solution）を確認してください。

ネットワークインターフェースの状態確認

ネットワーク・ナビゲーターとしての最初のステップは、基本情報の収集です。そもそもネットワークハードウェアは認識され、アクティブになっているでしょうか？サーバー上のすべてのネットワークインターフェースの状態を確認する必要があります。この作業には、現代的なツールである ip コマンドを使用します。

タスク

ip コマンドを使用して、すべてのネットワークインターフェースの状態と設定を表示してください。

要件

この確認には ip addr コマンドを使用する必要があります。

例

コマンドを実行すると、lo（ループバック）や eth0（または類似の名前）などのネットワークインターフェースを示す出力が表示されます。メインインターフェースの状態を確認してください。アクティブであれば UP と表示されているはずです。

## 期待される出力形式（インターフェース名は異なる場合があります）
1: lo: 65536 qdisc noqueue state UNKNOWN group default qlen 1000 < LOOPBACK,UP,LOWER_UP > mtu
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
2: eth0: 1500 qdisc mq state UP group default qlen 1000 < BROADCAST,MULTICAST,UP,LOWER_UP > mtu
link/ether 00:16:3e:04:b0:40 brd ff:ff:ff:ff:ff:ff
inet 172.16.50.108/24 metric 100 brd 172.16.50.255 scope global dynamic eth0
valid_lft 1892159216sec preferred_lft 1892159216sec

ヒント

ip コマンドは多くのサブコマンドを持つ強力なツールです。アドレスを管理するためのサブコマンドは addr です。
ip addr show またはその短縮形である ip addr を使用できます。

IP アドレス設定の検証

インターフェースが UP であることが確認できました。幸先の良いスタートです。しかし、IP アドレスは割り当てられているでしょうか？IP アドレスのないインターフェースはネットワーク上で通信できません。ip addr でも確認できますが、ここでは別の定番コマンド ifconfig を使ってダブルチェックしてみましょう。同じ目的のために複数のツールを知っておくことは有益です。

タスク

ifconfig コマンドを使用して、IP アドレスの設定を検証してください。

要件

ifconfig コマンドを使用する必要があります。

例

出力には、ネットワークインターフェースとそれぞれの IP アドレスが表示されます。メインのネットワークインターフェース（eth0 など）の下にある inet フィールドを探して、IP 設定を確認してください。

## IP 設定を示す期待される出力
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.16.50.108  netmask 255.255.255.0  broadcast 172.16.50.255
        ether 00:16:3e:04:b0:40  txqueuelen 1000  (Ethernet)

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0

ヒント

ifconfig コマンドは net-tools パッケージに含まれており、この実験環境にはあらかじめインストールされています。
引数なしで ifconfig を実行すると、すべてのアクティブなインターフェースが表示されます。

リモートホストへの接続テスト

サーバーにはアクティブなインターフェースと IP アドレスがあることがわかりました。次の論理的なステップは、外部の世界と通信できるかを確認することです。ここで失敗する場合、ゲートウェイや DNS 設定に問題がある可能性があります。ping コマンドはこのテストに最適なツールです。

タスク

Google のパブリック DNS サーバー（8.8.8.8）に対して ICMP パケットをちょうど 3 回 送信し、サーバーのインターネット接続をテストしてください。

要件

ping コマンドを使用する必要があります。
送信するパケット数を 3 に制限する必要があります。
ターゲット IP アドレスは 8.8.8.8 である必要があります。

例

接続が機能していれば、ターゲット IP アドレスからの応答とタイミング情報が表示されます。最後の統計情報で、3 個のパケットが送信（transmitted）され、3 個受信（received）され、パケットロスが 0% であることを確認してください。

## 成功時の期待される出力パターン
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=4.33 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=4.30 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=4.30 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.298/4.309/4.329/0.014 ms

ヒント

ping コマンドは、停止を指示しない限り無期限に実行され続けます。
送信するパケットの回数（count）を指定するには -c オプションを使用します。

オープンなネットワークポートの調査

接続は良好です！では、なぜ社内ポータルにアクセスできないのでしょうか？問題はアプリケーション自体にあるかもしれません。ウェブサーバーのプロセスは実際に動作し、正しいポートで接続を待ち受けて（リスニングして）いるでしょうか？ss（socket statistics）コマンドは、これを調査するための現代的で高速なツールです。

タスク

社内ポータルはポート 8000 で動作しているはずです。ss コマンドを使用して、ポート 8000 で TCP 接続を待ち受けているプロセスがあるか確認してください。

要件

ss コマンドを使用する必要があります。
リスニング状態の TCP ソケットを表示するようにコマンドを構成してください。

例

プロセスがポート 8000 でリスニングしている場合、リスニングソケットに関する情報を含む出力が表示されます。「Local Address」カラムにポート 8000 が表示されている行を探してください。

## ポート 8000 でリスニング中のプロセスを示す期待される出力
LISTEN 0      5            0.0.0.0:8000       0.0.0.0:*    users:(("python3",pid=3765,fd=3))

ヒント

ss コマンドには便利なフラグがいくつかあります：
- -t: TCP ソケットを表示。
- -l: リスニング（listening）ソケットを表示。
- -n: サービス名ではなく数値（numeric）のポート番号を表示。
- -p: ソケットを使用しているプロセス（process）を表示。
これらのフラグを組み合わせて ss -tlnp のように使用できます。
特定のポートを見つけるには、ss の出力を grep コマンドにパイプします。例：ss -tlnp | grep 8000。

基本的なファイアウォールルールの設定

すべての確認が終わりました。インターフェースは稼働し、IP は設定され、インターネット接続も機能しており、アプリケーションは正しいポートで待ち受けています。残る大きな容疑者はファイアウォールだけです。ポータルへの着信トラフィックをブロックしている可能性があります。最後のタスクは、ファイアウォールを設定してポータルへのアクセスを拒否することです。ここでは、ファイアウォールルールを管理するためのユーザーフレンドリーなフロントエンドである ufw（Uncomplicated Firewall）を使用します。

タスク

ポート 8000 への着信トラフィックを拒否（deny）するファイアウォールルールを追加してください。
SSH トラフィック（ポート 22）を許可（allow）するファイアウォールルールを追加してください。
ファイアウォールを有効（enable）にして、新しいルールを適用してください。

要件

すべての操作に ufw コマンドを使用する必要があります。
ファイアウォールルールの変更には管理者権限が必要なため、sudo を使用する必要があります。

例

ファイアウォールルールを設定した後、sudo ufw status を実行すると、ファイアウォールがアクティブで、ポート 8000 が拒否、SSH（ポート 22）が許可されていることが表示されるはずです。

## ポート 8000 を拒否、SSH を許可してファイアウォールを有効にした後の期待される出力
Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
8000                       DENY        Anywhere
22 (v6)                    ALLOW       Anywhere (v6)
8000 (v6)                  DENY        Anywhere (v6)

ルールを追加すると、以下のように表示されます：

Rules updated
Rules updated (v6)

ファイアウォールを有効にすると、以下のように表示されます：

Firewall is active and enabled on system startup

ヒント

ufw の構文は非常にシンプルです。特定のポートのトラフィックを拒否するには、ufw deny <port> を使用します。
ポート 8000 のトラフィックを拒否するには ufw deny 8000 を使用します。
SSH トラフィックを許可するには ufw allow ssh または ufw allow 22 を使用します。
重要な警告： SSH ポート（22）を適切に開放しないと、検証システムが SSH 接続できなくなるため、チャレンジの検証に失敗します。
重要な警告： 他のポートのファイアウォールルールを勝手に変更しないでください。オンラインの仮想マシンが故障する原因になります。
ルールを追加した後は、ufw enable でファイアウォールを有効にする必要があります。

まとめ

素晴らしい仕事です、ナビゲーター！ネットワークインターフェースの確認、IP 設定の検証、接続テスト、オープンポートの調査、そして最後にファイアウォールの設定という体系的な手順を踏むことで、問題の診断と解決に成功しました。社内ポータルは再びオンラインになり、チームからの信頼も勝ち取りました。

あなたは ip、ifconfig、ping、ss、ufw といった Linux ネットワークの基本ツールの確かな知識を証明しました。このような論理的で段階的なトラブルシューティングプロセスは、システム管理者にとって不可欠なスキルであり、今後のキャリアにおいて非常に価値のあるものとなるでしょう。これからもスキルを磨き続けてください！

DAY 07: ネットワーク・ナビゲーター