はじめに
ネットワークのトラブルシューティングでは、層を 1 つずつ確認すると原因を特定しやすくなります。まずホストの識別情報を確認し、次にインターフェースとアドレス、ルートの選択、基本的な到達性、名前解決、待ち受けソケット、アプリケーションの応答、最後にローカルのファイアウォールポリシーを確認します。
この実験では、Ubuntu ホスト上でこの順序に沿って操作します。準備済みの HTTP サービスがループバックのポート 8088 だけで待ち受けているため、ss、curl、UFW のルール設定を安全に練習できます。ホストのインターフェース設定、デフォルトルート、DNS 設定、SSH サービスは変更しません。UFW を有効にする前に、SSH 接続を明示的に許可します。
ホストを識別する
このステップでは、ホスト名と、このマシンをプログラムが識別するために使用するローカルの名前レコードを確認します。
実験用ワークスペースに移動します。
cd /home/labex/project/network-lab
現在のホスト名を表示します。
hostname
systemd が認識している静的ホスト名、一時ホスト名、オペレーティングシステムの識別情報を表示します。
hostnamectl
Static hostname は設定済みのホスト名です。クラウドのトレーニングマシンでは、起動時に一時ホスト名が割り当てられることがあります。
ローカルのホスト名マッピングを確認します。
cat /etc/hosts
ループバック名の localhost、127.0.0.1、::1 は、外部ネットワークを使わずに同じホストを識別します。ホストに割り当てられている IP アドレスを簡潔に表示します。
hostname -I
ホスト名とアドレス一覧を保存します。
printf 'hostname=%s\naddresses=%s\n' "$(hostname)" "$(hostname -I | xargs)" > host-identity.txt
cat host-identity.txt
インターフェースと IP アドレスを確認する
このステップでは、ネットワークインターフェース、リンクの状態、IPv4 アドレス、プレフィックス、アドレスのスコープを確認します。
リンクの概要を表示します。
ip -brief link
lo はループバックインターフェースです。通常は eth0 や ens... という名前の別のインターフェースが、VM をネットワークに接続します。UP は、インターフェースが管理上有効になっていることを示します。
アドレスを簡潔に表示します。
ip -brief address
192.0.2.10/24 のようなアドレスは、IPv4 アドレスとプレフィックス長を組み合わせたものです。プレフィックスは、ローカルネットワークを識別する先頭ビットの範囲を示します。
ループバックの詳細を確認します。
ip address show dev lo
IPv4 アドレス 127.0.0.1/8 の scope host は、このアドレスがこのホスト内部でのみ有効であることを示します。デフォルトルートで使用されるインターフェースを確認します。
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Primary interface: $primary_if"
ip address show dev "$primary_if"
ifconfig は古いインターフェース管理ツールですが、既存の運用手順書やトラブルシューティング手順では現在も使われています。先ほど確認した最新の ip の出力と比較します。
ifconfig
従来形式の表示も保存します。
ifconfig > ifconfig-addresses.txt
インターフェースの概要を保存します。
ip -brief address > interface-addresses.txt
cat interface-addresses.txt
ルーティングテーブルを読む
このステップでは、デフォルトゲートウェイを確認し、指定した宛先に対して Linux がどのルートを使用するかを調べます。
メインのルーティングテーブルを表示します。
ip route
接続済みルートは、直接接続されているネットワークを示します。default via で始まる行は、より具体的なルートが一致しない場合に使用されます。
パブリックな宛先へ到達する場合にカーネルがどのようにルートを選択するかを確認します。このコマンドはパケットを送信せずに、選択されたゲートウェイ、インターフェース、送信元アドレスを表示します。
ip route get 1.1.1.1
デフォルトゲートウェイとインターフェースを取り出します。
gateway=$(ip route show default | awk 'NR==1 {print $3}')
primary_if=$(ip route show default | awk 'NR==1 {print $5}')
echo "Default gateway: $gateway via $primary_if"
ルートの概要を保存します。
printf 'gateway=%s\ninterface=%s\n' "$gateway" "$primary_if" > route-summary.txt
cat route-summary.txt
ネットワークの到達性をテストする
このステップでは、ping を使って、より遠い境界へ順番に到達性を確認します。ただし、一部のネットワークでは診断用パケットがブロックされることに注意してください。
まずループバックをテストします。オプション -c 2 は 2 回リクエストを送信し、-W 2 は各応答を最大 2 秒間待機します。
ping -c 2 -W 2 127.0.0.1
ループバックテストが成功すると、ローカルの IP スタックが応答していることを確認できます。次に、デフォルトゲートウェイを取得してテストします。
gateway=$(ip route show default | awk 'NR==1 {print $3}')
ping -c 2 -W 2 "$gateway" || echo "The gateway does not answer ICMP echo requests"
フォールバックメッセージが表示される可能性があるのは、ルーターがトラフィックを転送しながら ping を拒否することがあるためです。DNS に依存せず、パブリック IP アドレスをテストします。
ping -c 2 -W 2 1.1.1.1 || echo "Public ICMP is blocked or unavailable"
外部ネットワークのポリシーに依存せず、ローカル接続の安定した結果を保存します。
ping -c 1 -W 2 127.0.0.1 > loopback-ping.txt
tail -n 2 loopback-ping.txt
ホスト名の名前解決をテストする
このステップでは、リゾルバーの設定を確認し、ホスト名をアドレスに変換します。
標準的な Linux アプリケーションが使用するリゾルバー設定ファイルを表示します。
cat /etc/resolv.conf
通常、このファイルには 1 行以上の nameserver 行が含まれています。systemd-resolved を使用するホストでは、そのアドレスが外部 DNS サーバーそのものではなく、ローカルのスタブリゾルバーを示している場合があります。
システム全体の名前サービス設定を通して、ローカル名を解決します。
getent hosts localhost
getent は /etc/nsswitch.conf に従うため、/etc/hosts、DNS、その他の設定済みのソースを組み合わせて検索できます。外部名を解決し、IPv4 のソケットアドレスを取得します。
getent ahostsv4 example.com
IP アドレスへの ping は成功するのにこの名前解決が失敗する場合は、リゾルバー設定または DNS の到達性を確認します。解決された最初の IPv4 レコードを保存します。
getent ahostsv4 example.com | head -n 1 > dns-result.txt
cat dns-result.txt
待ち受けポートと HTTP 応答を確認する
このステップでは、待ち受け中の TCP ソケットを所有プロセスに関連付け、アプリケーションプロトコルをテストします。
準備済みのデモサービスは、ループバックのポート 8088 で待ち受けています。ss を使って、待ち受け中の TCP ソケットを確認します。オプション -l、-t、-n、-p は、それぞれ待ち受け、TCP、数値形式のアドレス、プロセス情報を意味します。
sudo ss -ltnp | grep ':8088'
127.0.0.1:8088 を探します。ループバックにバインドされているため、このサービスにはこのホストからのみアクセスできます。
ソケットの背後で動作しているサービスプロセスを確認します。
systemctl status labex-network-demo.service --no-pager
curl -i を使って、HTTP 応答のヘッダーと本文を表示します。
curl -i http://127.0.0.1:8088/
HTTP の 200 OK ステータスは、ポートが開いているだけでなく、アプリケーションが HTTP リクエストを受け付けてコンテンツを返したことを示します。サイレントモード -s を使い、応答本文だけを保存します。
cd /home/labex/project/network-lab
curl -s http://127.0.0.1:8088/ > http-response.html
grep 'network demo ready' http-response.html
アクセスを保持して UFW を有効にする
このステップでは、UFW の状態を確認し、リモート管理用のアクセスを保持し、練習用サービスのポートを許可してから、ファイアウォールを有効にします。
UFW は、Linux のパケットフィルタリングルールを操作するフロントエンドです。現在の状態を確認します。
sudo ufw status verbose
セットアップでは、UFW は無効で、ルールも設定されていません。リモートからホストのファイアウォールを有効にする前に、使用する管理経路を許可します。この VM では SSH に TCP ポート 22 を使用します。
sudo ufw allow 22/tcp
次に、練習用サービスのポートへの受信 TCP トラフィックを許可します。
sudo ufw allow 8088/tcp
有効化する前に、準備した変更を確認します。
sudo ufw show added
対話形式の確認プロンプトを表示せずに UFW を有効にします。
sudo ufw --force enable
ファイアウォールが有効で、2 つの許可ルールが存在することを確認します。
sudo ufw status verbose
サービスはループバックにバインドされているため、ファイアウォールを変更した後にローカルからテストします。
curl -fsS http://127.0.0.1:8088/
有効な状態を確認できる結果として保存します。
cd /home/labex/project/network-lab
sudo ufw status verbose > firewall-status.txt
cat firewall-status.txt
順序が重要です。管理経路を保持し、必要なサービスルールを追加し、ファイアウォールを有効にしてから、ポリシーとアプリケーションの到達性をすぐに確認します。実運用のホストでは SSH に別のポートを使う場合があるため、ポート 22 と決めつけず、実際の管理経路を確認してください。
まとめ
Linux ネットワークの診断手順を体系的に実行しました。確認した内容は、ホストの識別情報、インターフェースと IP アドレス、ルートの選択、到達性、名前解決、待ち受けソケット、HTTP 応答です。それぞれの層が異なる問いに答えること、また、ある境界で失敗すると次に調査すべき範囲を絞り込めることを学びました。
さらに、SSH アクセスを保持し、練習用サービスのポートを許可して UFW を有効にし、アクティブなポリシーとアプリケーションの応答の両方を確認しました。これらの習慣を身につけると、広範囲で破壊的な変更を加えずに、ネットワークサービスを診断して保護できるようになります。
